OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]