[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] AuthnContextDecl and AuthnContextDeclRef
Right, I think there are several points to be made here: 1) AuthnContextClassRefs MUST be absolute URIs 2) AuthnContextClassRefs MAY be defined by anyone (ie we provide some in the SAML2 specs, but you are free to define your own) 3) If an IDP receives a RequestedAuthnContext that it doesn't understand or can't satisfy, it MUST return failure. Note that the SP and IDP have to agree not only on which AuthnContexts are "known" but also on what their relative strengths are (if you want to use the comparison operators in RequestedAuthnContext) 4) If an SP receives an AuthnContext that it doesn't understand, it MAY reject the authentication statement (that totally depends on the policy at the SP) -Greg On 3/1/07 2:54 PM, "Eve L. Maler" <Eve.Maler@Sun.COM> wrote: > The Core spec (Section 1.3.2, lines 303-305) says: > > "Unless otherwise indicated in this specification, all URI reference > values used within SAML-defined elements or attributes MUST consist > of at least one non-whitespace character, and are REQUIRED to be > absolute [RFC 2396]." > > We did away with (implicitly) allowing relative URIs after running > into problems in V1.0, if I remember correctly. > > Eve > > Eric Tiffany wrote: >> Another issue from our recent SAML testing. >> >> A question arose whether an IdP can use an unspecified authentication >> context when the SP did not specify how it wished to be authenticated. One >> vendor was returning in its authentication statement >> >> <saml:AuthnContext> >> <saml:AuthnContextClassRef> >> urn:oasis:names:tc:SAML:2.0:ac:classes:Password >> </saml:AuthnContextClassRef> >> <saml:AuthnContextDeclRef> >> name/password/uri >> </saml:AuthnContextDeclRef> >> </saml:AuthnContext> >> >> Another vendor rejected this statement saying the URI is proprietary and >> does not recognize it. They quoted from SAML Core 2.7.2.2Š >> >> ²<AuthnContextDecl> or <AuthnContextDeclRef> [Optional] Either an >> authentication context declaration provided by value, or a URI reference >> that identifies such a declaration. The URI reference MAY directly resolve >> into an XML document containing the referenced declaration.² >> >> And from SAML Core 7.2.1 >> >> ³The following constructs in the assertion schema allow constructs from >> arbitrary namespaces within them: <AuthnContextDecl>: Uses xs:anyType, which >> allows any sub-elements and attributes.² >> >> >> So there are a couple of issues: >> >> - The <AuthnContextDeclRef> in the example above is a relative URI, so it >> is questionable whether it "identifies" a declaration, particularly in the >> absence of any base URI. >> >> - The text describing AuthnContextDecl and AuthnContextDeclRef is a bit >> confusing, since it says "either [...] a declaration provided by value, or a >> URI reference". Of course the schema is clear on which is which, but an >> implementer might be confused and think that either element may contain >> either a URI or a anyType >> >> - In this case, where the SP didn't specify the AuthnContext in the >> request, the IDP is free to do what it wants. However, perhaps there should >> be some guidance about how this should be handled in practice. >> >> Consulted on the matter, Greg Whitehead noted that this was more of a >> configuration issue where both parties needed to agree out-of-band rather >> than a failure to be conformant to the standard. It might be worth adding >> some language to this effect in the discussion of the >> <RequestedAuthnContext> element (sec 3.4.1, line 2034 of saml core). >> >> Also, it might be worth clarifying the language at 2.7.2.2 so that the type >> of the two elements is less ambiguous. >> >> ET >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]