RE: Is an authentication assertion mandatory in SAML?

[George Robert Blakley III <blakley@us.tivoli.com>]

Prateek

You're right; I just phased out.

In the request, you can pass an AttributeQuery with a saml:Subject
providing just the subject's name,
and using "bearer" (i.e. null) SubjectConfirmation (even if we don't move
SubjectConfirmation out of the
Subject element), and this has the effect of query by name.  The reply can
then provide an attribute
assertion with a "bearer" SubjectConfirmation (thus requiring no link
whatsoever to the user) -- and it
can fill in the subject field of that assertion with a null subject name,
hence an anonymous subject.

It works!  Sorry for the lapse.

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.


"Mishra, Prateek" <pmishra@netegrity.com> on 09/04/2001 02:04:05 PM

Please respond to "Mishra, Prateek" <pmishra@netegrity.com>

To:   George Robert Blakley III/Austin/IBM@IBMUS, Hal Lockhart
      <hal.lockhart@entegrity.com>
cc:   "'Tim Moses'" <tim.moses@entrust.com>, Marlena
      Erdos/Austin/Contr/IBM@IBMUS, "'Oasis security services bindings'"
      <security-bindings@lists.oasis-open.org>
Subject:  RE: Is an authentication assertion mandatory in SAML?



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>
>>

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>