RE: Is an authentication assertion mandatory in SAML?

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

1) I am generally in agreement with Hal's comments on this issue. We
need to ensure that certain "blinded" or "pseudonymous" forms of AuthN
assertions
be available within SAML. This has been proposed both by Hal (and Marlena?)
but we hasnt yet been integrated into SAML today.

2) The key issue here is that SAML does NOT specify a canonical
set of contents for a AuthN assertion issued by an authentication authority
(AA)
An AA may describe the same authentication act using a variety of different
AuthN assertions. The exact type of AuthN assertion generated may depend on
the
agreement between the authenticatee and the AA, as well as the relationship
between
the AA and the RP.

For example, I logon to example.com at 9:02AM using name/password over
server side SSL
and access content at localpaper.com.

example.com may generate and send any of the following AuthN assertions to
localpaper.com:

(a) Subject=Prateek Mishra from Netegrity, AuthenticationMethod=Name/pwd
over SSL,
    AuthenticationTime=9:02AM

 
(b) Subject=example.com id:12$XZ123, AuthenticationMethod=Name/pwd over SSL,
    AuthenticationTime=9:02AM

(c) Subject=example.com id:12$XZ123, AuthenticationMethod=unspecified,
    AuthenticationTime=unspecified


3) The bindings-0.5 SAML artifact profile works with a variety of different
AuthN assertion contents. It would be legitimate for an AP to generate and
transmit the 
following assertions using the SAML artifact profile (include two SAML
artifacts
as part of the query string):

	AuthNAssertio: 
     Subject=example.com id:12$XZ123, AuthenticationMethod=unspecified,
     AuthenticationTime=unspecified

     AttributeAssertion:
	Subject=example.com id:12$XZ123, category=faculty,
class=researchUniv

The RP has no access to the "true" identity of the user or any other
information
about the authentication act at the AA; only a tracking number
and the two user attributes included . Further, if the RP requires further
attributes and the AP exposes an attribute lookup service, then the RP can
"call back" for the required attributes.

4) IMHO, the current SAML artifact profile + the yet-to-be-developed
"pseudonymous"
or "blinded" AuthN architecture fully addresses the Shib requirements. I
realize we need
to do some work to concretize this claim and ground it in reality. I would
also
point out that the same solution would work with the proposed "Form POST"
profile.


- prateek



>>-----Original Message-----
>>From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
>>Sent: Tuesday, September 04, 2001 1:25 PM
>>To: 'Tim Moses'; 'marlena@us.ibm.com'
>>Cc: 'Oasis security services bindings'
>>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>
>>