> Marvin, can you please send me more information about your 2 factors auth > implementation for CAS ?
Sorry you had to ask again. I'll sketch out our implementation briefly and you can ask for elaboration on any points you're interested in. It may be interesting to review the UI, since that was a significant portion of the work, https://auth.vt.edu. - Defined two authentication handlers for user credentials, BindLdapAuthenticationHandler for user/password credentials and X509CredentialsAuthenticationHandler for eToken credentials. - Set up a special port on the servlet container, 9443 in our case, that wants SSL client authentication. The eToken login form posts to that port in order to deliver the certificate on the token to the CAS server. The point about "want" is very important in our case since "require" doesn't provide nearly as clean a user experience as optional SSL client auth. If you don't provide a certificate to the server in the "require" case, you have browser-specific behavior which is not very intuitive in some cases. - Customized the CAS login webflow to do a number of things: 1. Define two login forms, default user/pass and optional eToken, with limited support for switching between them. 2. Display a friendly server-side error message on eToken/SSL client auth failure. This is more work than it sounds. 3. Redirect all requests on port 9443 back to the standard SSL port. - Developed some CredentialsToPrincipalResolver components to inject a special LOA (Level of Assurance) value based on the original authentication credentials into the attribute payload delivered to SAML clients. We envision this will be used for demanding strong authentication by CAS client applications that need it. Unfortunately there is no infrastructure in CAS for upgrading a credential; this is clearly a usability shortcoming. In order for the eToken to send the client cert to CAS, which is really the heart of the 2-factor auth, the client computer must have the Aladdin eToken runtime software installed and the user must authenticate with the private key password. The runtime has an option to cache the password, which is enabled by default IIRC. Putting that configuration in the hands of the client is a liability in terms of security policy. In my opinion the requirement of client-side software installation and configuration is the greatest liability of our solution. The eToken runtime has proven to be problematic on the platforms I use daily (Ubuntu, OSX), but it is my understanding that Windows support is satisfactory. M -- You are currently subscribed to cas-user@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
