Announcement Announcement Module
No announcement yet.
Acegi User object vs. Application User object Page Title Module
Move Remove Collapse
This topic is closed
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Acegi User object vs. Application User object

    Many discussions on this forum seem to go like this:
    Q. My application has a hibernated User object already. How do I get it to play nice with Acegi?
    A. Easy! Just make your app's user object implement UserDetails, and then write a new Auth DAO that returns your UserDetails implementation.

    However, the webapp I'm developing is supposed to integrate with a customer's existing authentication system for authentication, username, and roles (could be Active Directory, Kerberos, DB, passw file, etc). Then our product needs to store additional information about the user (e.g. user contact information, preferences, etc.) in our database.

    With so many possible authentication providers it seems like it would be a nightmare to subclass each one to return my app's own UserDetails implementation. If you could just place a default UserDetailsFactory in the app context and have every Auth Provider find and use it, then perhaps this problem would be easier. But I haven't seen that anywhere... Am I just missing something?

    As it stands, it appears the only good approach is to have a totally separate application object to store our user info. Or does Acegi have some other trick up its sleeve that I don't know about?

    I want to provide this application user object automatically with each web request--similar to SecurityContextHolderAwareRequestWrapper/Filter. I would basically need to hook into Acegi after its authentication, read the principal name, retrieve our corresponding application user object, and provide that to the webapp code (as a servlet request or session attribute).

    I'd prefer to wire in a custom Filter rather than subclass one of Acegi's existing filters. I suppose any Filter that gets applied *after* httpSessionContextIntegrationFilter would work, right?

  • #2
    I haven't used it yet, but mabe a mixin approach might be helpful for avoiding explicit subclassing.

    Hope that helps,


    • #3
      I am not exactly sure of your precise requirements, but you could have each UserDetailsService return a vanilla UserDetails implementation except it also contains an extended property to contain your user information. The user information could be obtained from a services layer bean dependency injected into the UserDetailsService implementation.