[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] AI #88 - AuthnContext clarification
Suitably provoked :-), responses inline >-----Original Message----- >From: Scott Cantor [mailto:cantor.2@osu.edu] >Sent: Monday, January 12, 2004 1:14 PM >To: SAML >Cc: 'Paul Madsen' >Subject: [security-services] AI #88 - AuthnContext clarification > > >I took an action to post something hopefully in the way of >explanation on >how the AuthnContext work fits into the SSO messages and what >the different >elements are in the input proposal from ID-FF. > >I am *not* the authority on this stuff. I'm partly doing it to >provoke a >response from those in Liberty who are, to correct any errors >I make. So, >please correct me. > >Basically, I see three ways in ID-FF of expressing an authentication >context, which to repeat, is a particular extensible vocabulary for >describing metadata about the acts of identification and authentication >peformed by an IdP. It's metadata, in the sense that much of >is potentially >static information that applies across a range of principals and >transactions, but it's also potentially dynamic if the information can >change from transaction to transaction. The different representations >address these different cases. > >I don't think there's any reason you couldn't embed a static context in >actual metadata (as we've defined the term so far), and maybe >we want to >think about that. (Any Liberty folks willing to chime in, feel >free...) I >suspect it was timing and the way both specs evolved more than >any technical >reason, but I don't know. When embedded in metadata (and it could be done through any of the three mechanisms you identity below) the authentication context would be a logical boast by the IDP along the lines of 'I can do this'. When embedded within a particular assertion, its 'I did this'. > >Anyway, back to the three ways: > >A) Context Statement Reference (URI) > >This is a document reference to an actual XML document containing an >instance that conforms to the full AuthnContext schema. It >could have just >about anything in it. The actual URI might or might not be >resolvable to the >XML, but if it's not, there must be some OOB understanding >about what's in >it or it isn't very useful. > >B) Context Class Reference (URI) > >Context classes are kind of tricky. Basically it's an >extensible set of URIs >that represent a constrained schema (based on the full schema) >that limits >the kind of information in a particular context. It narrows >the field, so to >speak, so that you're only dealing with a subset of the potential >vocabulary. The purpose is to define commmonly-used subsets >for vertical >industries or based on common technology that simplfy implementation. In addition to the context class mechanism itself, Liberty took a stab at identifying those classes believed to be representative of current industry practices. So for instance, Liberty defined a 'PasswordProtectedTransport' class to capture the common scenario of a Principal authenticating using a password over SSL. Generally, the Liberty classes are labelled by the mechanism by which the Principal authenticates - notable exceptions are the mobile classes which distinguish between a Principal who has signed a contract with the IDP or not. It was hoped/expected that other groups would define their own classes to extend the set (12 members) that Liberty specified. > >Context class URIs do not refer to a specific context >document, but simply >to the schema for what the context might contain. That is, >they aren't an >actual context, but a range of possible contexts, with a fixed URI. Correct, by specifying a particular context class URI, the IDP is asserting that, if an actual context instance did exist (it may not) - it would satisfy the requirements with respect to identification, authentication etc, as expressed in the appropriate context class schema. > >IMHO, they most resemble the existing SAML >AuthenticationMethod because they >classify the method used without providing explicit detail >(for example, >they tell you a password is involved, but not the minimum >password length). Actually, some classes are more specific. For instance the Password class requires that the password be 3 characters or greater. Additionally, context classes, although lablelled by their authentication mechanisms, do specify information beyond that listed in SAML's AuthenticationMethod. > >C) Inline Context > >The last representation is the full context instance, as an >XML fragment, >embedded directly in an assertion or in a stand-alone document. > >Now, how do they get used in SSO in ID-FF? > >An AuthnRequest can contain either a set of possible statement >refs (A) or a >set of possible class refs (B), and optionally a quality >parameter that says >"match, at least meet, or do better than". So you don't >actually inline a >full context, though you could reference one as a statement >ref that has a >ton of detail in it. > >Using class refs is more likely, I would think, but I'd note >that if you >used the class approach, you couldn't specify things like >minimum password >length unless you defined your own class URI for that. Which >seems like a >mis-use of the feature, so basically if you care about a lot >of detailed >control, you'd use statement refs. I think. Agreed, the motivation for class refs was to simplify and protect SP's from this level of detail. > >In the assertion you get back, in place of or alongside >AuthenticationMethod, you get back either a statement ref (A) >or an inline >context (C), plus optionally a class ref (B). The purpose of >the class ref >seems to be almost like an XML namespace, to signal the >vocabulary of the >actual statement. I think that's something that you don't get >from a quick >read of the AuthnContext spec, but that's my sense of how it acts. I think of the class ref as a ahorthand for the actual context statement, if both are included the IDP is saying 'here are the details if you're interested, if not, here is the reader's digest version. Paul ' > >-- Scott > > >To unsubscribe from this mailing list (and be removed from the >roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave _workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]