[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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> >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC