• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • None
    • Confluence + tomcat + apache
    • 0
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      Hi,

      our company also want to use Confluence 2.1.x.

      But we have an issue:

      Intranet Integration

      All Users fĂĽr web based Applications have a single URL
      https://intranet.mycompany.com running apache 2.0.x and mod_auth_ldap.

      Currently, all intranet apllications are using the environment variable
      REMOTE_USER for user mapping which is passed from apache through
      the webserver module to the java/php/perl application.

      Once, the user is logged in, everything is fine.
      The java/php/perl application knows the
      user = REMOTE_USER and can make the necessary
      LDAP Requests for the user.

      Login screens for Apllcations are not necessary at all.
      For mediawiki, there's an example in the Extension "Auto_Login_via_REMOTE_USER".

      It would be great, to have a configuration variable like

      REMOTE_USER=true within the Confluence Web Admin

      to use this simple feature in Confluence and
      to make it simple to integrate in existing Intranet and Extranet Environments.

      Of course, it's necessary to configure confluence LDAP integration, that
      confluence uses the same user oids as the apache mod_auth_ldap.

      Regards, Thorleif Wiik

            [CONFSERVER-5875] SSO with apache REMOTE_USER

            I am currently setting up a confluence/jira environment in an existing env that had REMOTE_USER already set using an nginx that also delt with authentication.
            Thought it was a no-brainer, but still having issues with something that seams so simple. The RemoteUserJiraAuth looks like the thing to use, but I also had to get nginx to support AJP (had to compile in the module), then use another nginx module (also compiling in) to be able to send headers over AJP. And, still having problems because none of the headers I'm sending works for some reason.

            Anyone that have this proper setup?

            This issue is coming up for its 10th birthday soon.. Atlassian? Anything? This seams so trivial...

            Lars Solberg added a comment - I am currently setting up a confluence/jira environment in an existing env that had REMOTE_USER already set using an nginx that also delt with authentication. Thought it was a no-brainer, but still having issues with something that seams so simple. The RemoteUserJiraAuth looks like the thing to use, but I also had to get nginx to support AJP (had to compile in the module), then use another nginx module (also compiling in) to be able to send headers over AJP. And, still having problems because none of the headers I'm sending works for some reason. Anyone that have this proper setup? This issue is coming up for its 10th birthday soon.. Atlassian? Anything? This seams so trivial...

            I linked RemoteUserJiraAuth on the Marketplace. Its unsupported. You could write your own authenticator, but not everyone writes software.

            Orlando Caro added a comment - I linked RemoteUserJiraAuth on the Marketplace. Its unsupported. You could write your own authenticator, but not everyone writes software.

            @Daniel V. Santoalla: Hi Daniel, do you mind publishing your solution. We are also interested in it.

            Andreas Pelzer added a comment - @Daniel V. Santoalla: Hi Daniel, do you mind publishing your solution. We are also interested in it.

            This feature would be a fantastic solution to our organization's SSO problems with Atlassian products. We already have Shibboleth handling authentication for all of our other applications and setting a REMOTE_USER variable into the environment that goes to Confluence/Jira/Stash/Bamboo/whatever. To be able to use that to automatically log the user in (and perhaps automatically create users if they don't exist) would be a great boon toward simplifying our unnecessarily complex Atlassian integration.

            Paul Lockaby added a comment - This feature would be a fantastic solution to our organization's SSO problems with Atlassian products. We already have Shibboleth handling authentication for all of our other applications and setting a REMOTE_USER variable into the environment that goes to Confluence/Jira/Stash/Bamboo/whatever. To be able to use that to automatically log the user in (and perhaps automatically create users if they don't exist) would be a great boon toward simplifying our unnecessarily complex Atlassian integration.

            We ended up implementing this feature ourselves but it would be good to know Atlassian official position on this issue, as in

            • Interesting but we don't have time now for this
            • No we won't ever do this because a, b, or c. Use d

            Daniel Varela Santoalla added a comment - We ended up implementing this feature ourselves but it would be good to know Atlassian official position on this issue, as in Interesting but we don't have time now for this No we won't ever do this because a, b, or c. Use d

            d added a comment -

            This feature request seems like a real no-brainer for both JIRA and Confluence. It shouldn't be too hard to implement and it makes it possible to use these tools in environments with weird authentication restrictions.

            As it is, we are blocking on an integration project for a lack of this feature . . .

            d added a comment - This feature request seems like a real no-brainer for both JIRA and Confluence. It shouldn't be too hard to implement and it makes it possible to use these tools in environments with weird authentication restrictions. As it is, we are blocking on an integration project for a lack of this feature . . .

            I would really appreciate to hear Atlassian's view on this. Maybe they don't want to canibalize on their own Crowd product but for many organisations it is not a matter of choice. We might use Crowd as user directory but we MUST use our own SSO solution (which sets REMOTE_USER) which is deployed on tens of our websites already.

            Daniel Varela Santoalla added a comment - I would really appreciate to hear Atlassian's view on this. Maybe they don't want to canibalize on their own Crowd product but for many organisations it is not a matter of choice. We might use Crowd as user directory but we MUST use our own SSO solution (which sets REMOTE_USER) which is deployed on tens of our websites already.

            I also agree that this would be extremely useful. Fisheye already supports AJP authentication, which AFAIK uses the REMOTE_USER variable. Why not supporting AJP authentication for all the line of products?

            Daniel Varela Santoalla added a comment - I also agree that this would be extremely useful. Fisheye already supports AJP authentication, which AFAIK uses the REMOTE_USER variable. Why not supporting AJP authentication for all the line of products?

            Samuel Kim added a comment -

            We would also like REMOTE_USER supported natively on jira and confluence.

            Samuel Kim added a comment - We would also like REMOTE_USER supported natively on jira and confluence.

            This does not need to be complicated. For example, a simple boolean setting "Enable REMOTE_USER authentication" would work. This would simply allow REMOTE_USER to provide a pre-authenticated username; everything else can stay the same (e.g., how groups are determined, etc.).

            SSO via REMOTE_USER is used widely and it's silly that Atlassian makes you jump through so many hoops just to reinvent a wheel that already exists.

            Archie Cobbs added a comment - This does not need to be complicated. For example, a simple boolean setting "Enable REMOTE_USER authentication" would work. This would simply allow REMOTE_USER to provide a pre-authenticated username; everything else can stay the same (e.g., how groups are determined, etc.). SSO via REMOTE_USER is used widely and it's silly that Atlassian makes you jump through so many hoops just to reinvent a wheel that already exists.

              Unassigned Unassigned
              fa549b92b4a1 Thorleif Wiik
              Votes:
              33 Vote for this issue
              Watchers:
              23 Start watching this issue

                Created:
                Updated: