Uploaded image for project: 'atlassian-seraph'
  1. atlassian-seraph
  2. SER-138

Support the use of multiple authenticators and tools/methods to identify different authentication requests



    • New Feature
    • Status: Open
    • Medium
    • Resolution: Unresolved
    • None
    • None
    • None
    • true


      Doe anyone know if it's possible to slam two authenticator classes into the seraph-config.xml file

      For example, some customers may need to use the NTML authenticator for Sharepoint connectivity but still being able to use the other connector that autojoins ldap users to confluence-users
      Note: Supported NTLM connector bundled with SPC

      The solution:
      Seraph supports one authenticator only. However, if different authenticators have to be used for different applications, a custom authenticator can be developed to receive the authentication requests. Depending on the request header (or other property that can identify what's the purpose of that authentication) it would redirect the request to the appropriate authenticator. Using only seraph configurations it would not be possible to distinguish the different incoming requests.

      i.e. you need to create an 'authentication broker' that acts as line1 authenticator and that parses requests to other authenticators according to the header information.

      Currently using of Crowd would not solve the problem because the authenticators are set in Confluence/JIRA and Crowd itself does not support integration with SPC and NTML.
      Even if a custom SPC and/or NTML connector is developed, it would still not solve the problem. This is due to the fact that authentication must be handled by Seraph before it reaches Crowd. If Seraph handles things right in the front-end, Crowd (with a custom App connector) would handle things correctly on the back-end. (i.e. All the tentatives must be handled by Seraph first.)

      One may write a custom authenticator that would be the 'front-end' of Crowd and then specific Crowd connectors that would be passing requests onto appropriate applications. i.e. combining the functionality effectively




            Unassigned Unassigned
            ivan@atlassian.com Ivan Benko [Atlassian]
            0 Vote for this issue
            1 Start watching this issue


              13 years, 5 weeks, 3 days ago