[cas-dev] Pass on authentication method

[Philip Brusten]

I finally got a chance to look into this :-)

I now have a working proof-of-concept. I managed to put the
authentication method in de CAS2 protocol response, eg:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
        <cas:authenticationSuccess>
                <cas:user>netid</cas:user>
        </cas:authenticationSuccess>
        <cas:attributes>

<cas:samlAuthenticationStatement>urn:oasis:names:tc:SAML:1.0:am:password</cas:samlAuthenticationStatement>
        </cas:attributes>
</cas:serviceResponse>

I had to change following files at the cas-server (I will add these to
issues):
 - SamlAuthenticationMetaDataPopulator.java
 - casServiceValidationSuccess.jsp

For the java-cas-client I wrote a filter to map the authentication
method to another attribute in the request. The latter will be read by
the Shibboleth IdP v2 authentication handler.

If desired I can provide this code as well. 

Regards,

Philip


On Tue, 2008-05-27 at 08:51 -0400, Scott Battaglia wrote:
> Philip,
> 
> Take a look at the example MetaDataPopulator in the core source code
> for the SAML 1.1 stuff.  It should give a good idea on how that can be
> done with the SAML2 stuff.  The only difference is if you were
> returning a custom CAS2 response you would obviously need to modify
> the response ;-)
> 
> -Scott
> 
> On Mon, May 26, 2008 at 10:32 AM, Philip Brusten
> <philip.brusten at cc.kuleuven.be> wrote:
>         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
>         
>         _______________________________________________
>         cas-dev mailing list
>         cas-dev at tp.its.yale.edu
>         http://tp.its.yale.edu/mailman/listinfo/cas-dev
> 
> 
> 
> -- 
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia 
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev


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