Announcement Announcement Module
Collapse
No announcement yet.
Multiple authentication sources use case Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Multiple authentication sources use case

    I am going to be authenticating against multiple authentication sources for different contexts and had an idea about how to implement this but wanted to see if it was a fairly acegi-friendly way to do it.

    I have an InMemoryDaoImpl for the site administration stuff, a back end pass through authenticator for customers, and a different back end pass through authenticator for the HR intranet for employees.

    I am planning on having an AuthenticationProcessingFilter and a SecurityEnforcementFilter for each context, along with their constituent things like the dao, authentication manager, etc. specific to each context.

    Is this a standard way or is there a better way using acegi? I see that with just those, I have 6 filters in the FilterToProxy thing, not to mention the other definitions in there for each context.

    Thanks in advance.

    Jeremy

  • #2
    It looks like there isn't anyone out there trying to use multiple authentication sources for a single web app - which is why I initially wanted to use acegi. Maybe people are still coming off of their JavaOne high and haven't seen the post yet.

    In any case, I'm noticing that acegi isn't recognizing multiple definitions of ProviderManagers or ProcessingFilters or something. It seems to take the first instance of them that it finds.

    I extrapolate from this that if one wants to have multiple authentication sources, they'd have to use an extension point and then use the single filter processor to farm out the different calls based on what they are trying to access or something. So if I wanted to have an intranet login at http://url/intranet, and a customer portal at http://url/customer_portal, I would likely have the same processing filter and that would decide based on what it was trying to access.

    This seems like a lot of trouble and extending when it would seem like just having different bean ids and definitions should work just fine. I'm probably missing something. Does anyone do something similar in their app? Does anyone have different definitions for InvocationInterceptors or do people typically have just one InvocationInterceptor for all of their secure path patterns?

    I hope I'm making sense here.

    Jeremy
    Last edited by jeromatron; May 22nd, 2006, 11:43 PM.

    Comment


    • #3
      Hi Jemromatron,

      I am currently authenticating using multiple sources in a single web-app. I use the LDAP to authenticate internal users and use Database to authenticate all external customers.

      The trick to doing this is that you provide multiple Authentication providers to your authentication manager. The Authentication manager loops thru all providers trying to authenticate the user before finally throwing an exception if the user cannot be authenticated by atleast one of the providers.

      Hope this helps.

      Comment


      • #4
        Okay, thanks for the info! I see now that it's a list of providers in the authentication manager. So it looks like you have a single authentication manager and multiple providers.

        So does that mean that you have a single login page for all of the different secured resources?

        I'm just wondering because we were thinking of having a different login page for each type of resource.

        Comment

        Working...
        X