Mike Youngstrom wrote:
Maybe I'm missing something but it appears that the only CAS and AuthenticationDao integration point is in the DaoCasAuthoritiesPopulator in "getAuthorities" method where it appears to only load the user in order to get the authorities().
Maybe I should ask my question this way. I am using CAS and a custom
UserDetails implementation. I'm returning my custom UserDetails
implementation in my custom AuthenticationDao and overridden
loadUserByUsername method. So, how can get at my custom UserDetails
implementation given the SecureContext? Or is this possible?
Hi Mike
Currently this is not possible. We could modify the returned CasAuthenticationToken to contain the UserDetails, but the problem is how to get the UserDetails in the first place given CasAuthoritiesPopulator only returns GrantedAuthority[].
The decision for CasAuthoritiesPopulator to work with GrantedAuthority[] rather than UserDetails was made so that there was no unnecessary dependency on the DAO authentication provider package. At the time UserDetails was actually User, and nobody was talking about extending User for custom properties.
Option 1. We can make CasAuthoritiesPopulator return UserDetails rather than GrantedAuthority[], which is unlikely to cause any real problems for people given most CAS/Acegi users would be using the included DaoCasAuthoritiesPopulator. However, that would force the CAS package to depend on the DAO authentication provider package (for the UserDetails interface).
Option 2. We could add an AdditionalDetailsPopulator interface to CasAuthenticationProvider, which could be null if people didn't want to use it. AdditionalDetailsPopulator would obtain an object and put it in the CasAuthenticationToken. We'd write a consolidated DaoAuthenticationPopulator which uses caching and implements both CasAuthoritiesPopulator and AdditionalDetailsPopulator against an AuthenticationDao.
Option 3. Do nothing. People requiring additional properties can look them up in whatever way best suits their application, or via their own filter (ie lookup ContextHolder, get Authentication, get principal, look it up from DAO, populate a suitable ThreadLocal or subclassed SecureContextImpl, continue filter chain).
Option one is preferable in the likely case most people would use the DAO authentication provider package. In fact I've not heard of anyone using Acegi Security with anything but the DAO authentication provider package. Furthermore, the linkage is not very significant anyway, being only a single interface which could be moved to net.sf.acegisecurity to reflect its more widespread use.
Comments?
Best regards Ben
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Acegisecurity-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
