[cas-dev] Pass on authentication method

Philip Brusten philip.brusten at cc.kuleuven.be
Mon May 26 10:32:27 EDT 2008


Hello,

Like many other organizations, we have been using CAS in conjunction
with Shibboleth, a choice we have not regret yet :-)

We have configured our CAS server to use different authentication
schemes, like x509, digipas, user/password and spnego. Our goal is to
pass on the authentication method to our applications, hence the
application can decide whether the authentication method used provides
the required level of authentication, eg:

urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
urn:oasis:names:tc:SAML:2.0:ac:classes:Smartcard
urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken
...

Reference:
http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf

Technically this can be achieved if the CAS server provides the
authentication method to the CAS client. And the CAS client adds the
authentication method in the http request. The Shibboleth IdP will
consume the http header and will add it to the SAML assertion (needs
some small customization at the IdP).

Am I reinventing the wheel here or has anyone done this before?

Or is the feature I'm describing here the same as the one from the
roadmap:

CAS Server 4.x
Return User Attributes 
Return User Attributes (biodemographic data, authentication information,
etc.) to the service requesting it.  Can either be configured via a
server tool or negotiated between user and application. 

Regards,

Philip


ps: something is wrong with the mailing list configuration site: http://tp.its.yale.edu/mailman/listinfo/cas-dev




Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



More information about the cas-dev mailing list