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] Authentication Method (long-ish)


So, I've investigated this a bit, and I think that it is possible to 
harmonize the SAML AuthenticationMethod and the Authentication Context 
classes in the following way:

1) We would need to mandate the AuthnContext element in the response, 
and constrain it such that the sender MUST send back an 
AuthnContextClassRef sub-element (but not necessarily a 
AuthnContextStatement or AuthnContextStatementRef).
2) Remove the AuthenticationMethod attribute - we would no longer have 
two places where such data were present. The authentication context 
information is a super-set of authentication method information.
3) Map the SAML authentication methods to authentication context class 
schemas. Some may just require that we add an additional URI reference 
(ie. just add the current SAML URI as one that identifies a particular 
class schema) to a schema that already exists. Others may require that 
we define new class schemas. This would ensure that the URIs that SSTC 
has defined for authentication methods could remain unchanged.

So, basically, at the instance level, and in the simple case, where you 
don't care about validating an AuthnContextStatement against the class 
schema (ie. the equivalent of today's SAML model):

<AuthnResponse>
   ...
   <AuthenticationStatement 
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:HardwareToken" 
AuthenticationInstant="...">
     ...
   </AuthenticationStatement>
   ...
</AuthnResponse>

would become:

<AuthnResponse>
   ...
   <AuthenticationStatement AuthenticationInstant="...">
     ...
     <AuthnContext>
       ...
       <AuthnContextClassRef>
      urn:oasis:names:tc:SAML:1.0:am:HardwareToken
       </AuthnContextClassRef>
     </AuthnContext>
   </AuthenticationStatement>
   ...
</AuthnResponse>

Advantages:

Better harmonizes authentication context with SAML Authentication 
Method. As authentication method is part of the authentication context 
anyway, this seems to provide a more consistent model.
Allows the requester to express their interest in the use of a 
particular SAML authentication method, via the RequestAuthnContext element.

Disadvantages:

A little more XML

I can pursue this, but would like the group's approval before making any 
schema changes, or attempting to map the SAML authentication methods to 
authentication context classes.

Cheers,

- JohnK

ext Scott Cantor wrote:
>>Not sure of the overlap, the URI (whatever the SSTC version 
>>is)  simply indicates that the authentication context for the assertion 
>>can somehow be described using the AuthnContext structure. 
> 
> 
> Yes, but I think the use of the URI as a call-out was a hack to deal with
> the mandatory AuthnMethod. It might be the right hack, but it still seems
> odd to me.
> 
> What I'm maybe suggesting is the ability to stick the context class
> reference in as the authentication method, and then we'd have to define
> context class "meaning" for the existing method URIs. Then the context class
> bit goes away as a schema bit.
> 
> Either way, we just need to harmonize the two approaches better.
> 
> -- 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]