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.

@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.

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

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.

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?

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.