Aaron Hamid wrote:
Hi there,
I work in central IT at Cornell University and we use a single-signon system that is roughly equivalent to CAS. I noticed your CasPasswordHandler/Proxy classes in the Acegi codebase and was wondering if you could explain it a bit. Traditionally we have to "frontend" various applications that expect traditional username/password style authentication. We use Kerberos at Cornell, so there is no "password" to ever pass to an application - the output of the authentication process is simply the username, which we store in the remote user CGI environment variable (typically exposed through getRemoteUser() or getPrincipal() in the servlet API). Since almost no applications are designed properly for authentication and single-signon, we typically we have to either coerce or hack the target application to circumvent its own password-based security, or otherwise we have to come up with a shared "dummy" password that we hardcode once we have an authentication user name, use for everybody, and then make sure that we lock down the system so there is no way in other than through our single-signon. It appears that Acegi is no exception, and still appears to want username/password as opposed to username alone. From scanning the CasPasswordHandler/Proxy class, my hunch is that you frontend an Acegi application, and then pass the Acegi handler a CAS-authenticated username, with some bogus (?) password. Is this correct? Or is it the other way around...somehow the Acegi handler itself redirects to CAS?
Thanks, Aaron Hamid CIT/ATA Cornell University
Hi Aaron
Acegi Security is used for building the applications which need a security aspect. Acegi Security itself has pluggable authentication providers which match up with different authentication strategies. CAS is one such strategy, but so is accessing authentication details from a JDBC database, in-memory list, LDAP directory, user custom strategy etc. Typically people use one AuthenticationProvider for each authentication strategy.
CasAuthenticationProvider accepts a CasAuthenticationToken OR a UsernamePasswordAuthenticationToken. The latter is used for an initial authentication request. It contains a "principal" which gives a clue to CasAuthenticationProvider if we want the resulting authentication token to be cached or not against the service/proxy ticket ID (this is used for stateless web services clients, but it really isn't important to your question). The principal generally has no use. The "credentials" inside UsernamePasswordAuthenticationToken are always the service/proxy ticket returned from the CAS server. CasAuthenticationProvider will go off and validate this against the CAS server, generating a CasAuthenticationToken if correct.
The "principal" of the CasAuthenticationToken is always the username from the CAS server, with the "credentials" being the service/proxy ticket ID (which can no longer be reused, as per the CAS design). It also stores the hash of a key inside the CasAuthenticationToken. On subsequent requests, CasAuthenticationProvider will be presented the CasAuthenticationToken and it will compare the hashed key with the expected value. If it's correct, CasAuthenticationProvider knows it generated the CasAuthenticationToken and it will thus accept it. The token is mostly immutable to prevent changes once initially created.
There is a thorough description of CAS authentication in the reference guide included in the download (docs/reference directory). It covers the remainder of the process.
I believe the approach we've taken is reasonable. All CAS concepts are respected - even down to proxy chain validation for people wanting to use it - and the resulting Authentication objects fully integrate with Acegi Security's deep authorization features. If you have any feedback about the design I would certainly welcome it.
If it's not too much trouble, would you please send future questions or comments to the Spring Forums at forum.springframework.org or the acegisecurity-developers list, as it helps with the historical archive. :-)
Best regards Ben
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
