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 > <[EMAIL PROTECTED]> 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@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@tp.its.yale.edu > http://tp.its.yale.edu/mailman/listinfo/cas-dev Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm _______________________________________________ cas-dev mailing list cas-dev@tp.its.yale.edu http://tp.its.yale.edu/mailman/listinfo/cas-dev
