Thank you very much for your information. This very useful for us
Thx. a lot Mike > Date: Mon, 3 May 2010 13:08:36 -0400 > From: [email protected] > Subject: Re: [cas-user] CAS and Two factor authentication > To: [email protected] > > > 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 [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user _________________________________________________________________ Got a phone? Get Hotmail & Messenger for mobile! http://go.microsoft.com/?linkid=9724464 -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
