RE: Is an authentication assertion mandatory in SAML?

[Hal Lockhart <hal.lockhart@entegrity.com>]

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 
>