RE: Is an authentication assertion mandatory in SAML?

["Mishra, Prateek" <pmishra@netegrity.com>]

Bob,

The existing AttributeQuery element requires at a minimum only
a <saml:Subject> element (there is also some fuss about a completeness
specifier which I will ignore). The <Response> includes one or more 
attributes assertions describing the subject. 

As I understand your message, this is precisely the flow you
are referring to. It is not a "new" flow, it is part of core-16.

- prateek

>>-----Original Message-----
>>From: George Robert Blakley III [mailto:blakley@us.tivoli.com]
>>Sent: Tuesday, September 04, 2001 2:50 PM
>>To: Hal Lockhart
>>Cc: 'Tim Moses'; 'marlena@us.ibm.com'; 'Oasis security services
>>bindings'
>>Subject: RE: Is an authentication assertion mandatory in SAML?
>>
>>
>>All,
>>
>>Maybe I could ask a simple question here.
>>
>>My belief is that a SAML attribute authority COULD consume a 
>>request which
>>contains nothing except (for example)
>>the name of a user -- no authentication assertion, no subject 
>>confirmation,
>>etc... -- and produce in return an attribute
>>assertion claiming that the subject named in the request has 
>>attributes X,
>>Y, and Z.  My belief is that nothing in the
>>SAML specs prohibits this behavior (but equally, nothing in 
>>the current
>>request structure allows you to pass just the
>>subject's name, so this scenario would be "in addition" to 
>>the specified
>>behaviors).
>>
>>Right or wrong?
>>
>>
>>--bob
>>
>>Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
>>Chief Scientist, Security and Privacy, Tivoli Systems, Inc.
>>
>>
>>Hal Lockhart <hal.lockhart@entegrity.com> on 09/04/2001 12:24:40 PM
>>
>>To:   "'Tim Moses'" <tim.moses@entrust.com>, "'marlena@us.ibm.com'"
>>      <marlena@us.ibm.com>
>>cc:   "'Oasis security services bindings'"
>>      <security-bindings@lists.oasis-open.org>
>>Subject:  RE: Is an authentication assertion mandatory in SAML?
>>
>>
>>
>>I disagree with both: that SAML cannot produce an Attibute Assertion
>>without
>>a Authentication Assertion and that Shiboleth requires that no
>>Authentication Assertion be generated.
>>
>>> 1. The Shibboleth business model requires that an attribute
>>> assertion be communicated by the authentication/attribute
>>> authority to the content site with no accompanying
>>> authentication assertion.
>>
>>Wrong. The business model requires that the authenticated 
>>attributes of a
>>user be presented to a relying party without revealing the real world
>>identity of the user and without making it possible to trace 
>>a series of
>>sessions to the same user. They have proposed a particular 
>>design which
>>does
>>not include an Authentication Assertion, but various people, 
>>including me
>>have proposed means by which it could be done using an Authentication
>>Assertion.
>>
>>> 2. The received wisdom is that the SAML architecture dictates
>>> that there be an authentication assertion associated with
>>> every attribute assertion ("no attribute assertion without
>>> authentication assertion").
>>
>>This is completely false. An authentication assertion can be 
>>generated when
>>an authentication act occurs, but cannot be generated when 
>>does not occur
>>and is not required in any case if the RP is not interested. 
>>For example,
>>one important usecase is sending a business transaction coded 
>>in XML with
>>an
>>attached Attribute Assertion describing the orginator.
>>
>>> 3. The received wisdom is that SAML authentication assertions
>>> are a record of an authentication event.
>>> This leads Marlena to conclude that SAML does not satisfy the
>>> Shibboleth requirement.
>>
>>By the end of the meeting, my understanding was that Marlena's main
>>sticking
>>points were:
>>
>>1. Shib wants signed artifacts, SAML is not willing to require this
>>2. The SAML Browser profile which uses artifacts currently 
>>proposes that
>>there be at least one that refers to an AuthN assertion.
>>
>>>  It also leads Simon to argue that an
>>> authentication assertion must be prepared immediately
>>> following authentication, and with no knowledge of the
>>> attributes required by the content site.
>>
>>I think it must be possible to create an AuthN Assrtion w/o 
>>knowing any
>>attributes other than those required to verify the 
>>credentials. It must be
>>possible for the AuthN authority and Attribute Authority to 
>>be distinct.
>>
>>However, whether an AuthN Authority generates the assertion 
>>immediatly or
>>records the data in some other form and creates an assertion 
>>later should
>>be
>>up to the implementation.
>>
>>
>>> However, if we challenge points 2 and 3 above, can we not
>>> accommodate the Shibboleth requirement for attribute
>>> assertions without authentication assertions?
>>> This only works with the artifact/pull model.  But, if the
>>> authentication/attribute authority issues an artifact that
>>> identifies the authenticated subject, and waits until it
>>> receives the assertion query before preparing the assertion,
>>> then the assertion can be an attribute assertion, not an
>>> authentication assertion.  It would say nothing about the
>>> authentication event, contain an "artifact" subject
>>> confirmation type code, and Marlena's concern would be addressed.
>>> I've probably totally misunderstood the issue, right?
>>> All the best.  Tim.
>>>
>>>
>>>
>>> --------------------------------------------------------------
>>> ----------
>>> ---------------
>>> Tim Moses
>>> Tel: 613.270.3183
>>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>
>>
>>
>>----------------------------------------------------------------
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.oasis-open.org/ob/adm.pl>
>>