How do you install Confluence HTTP Authenticator/Shibboleth Authenticator?

[Mark Mackay]

I'm wanting to build a custom SSO for my confluence site, and am trying to get the Confluence HTTP authenticator plugin to work -- to no avail.

https://marketplace.atlassian.com/plugins/shibauth.confluence.authentication.shibboleth

As per the 'Installation' instructions at https://github.com/chauth/confluence_http_authenticator;I have:

1. Downloaded remoteUserAuth-2.5.0.jar
2. Moved it to: /usr/local/confluence/confluence/WEB-INF/lib
3. Downloaded remoteUserAuthenticator.properties
4. Made a few minor changes to suit my environment, and put it in: /usr/local/confluence/confluence/WEB-INF/classes
5. I then stopped and start Confluence

The plugin doesn't appear to in the 'Manage Plugins' listing; or ../admin/viewplugins.action; and there's nothing in the logs to indicate the plugin was detected.

I was running Confluence 5.2.5 on my test server, but also tried with 5.4.4 to test whether it was a confluence version issue. No apparent change.

I also tried putting the .jar file in confluence/WEB-INF/atlassian-bundled-plugins -- and under ../admin/viewplugins.action the file showed up in the list, but was disabled. I tried enabling it, but that didn't seem to work either.

Can anyone help?

Clarification of ways to test

Also -- just to clarify my understanding. For testing purposes, it looks like i should be able to access - localhost:8090/?REMOTE_USER=testuser -- and the plugin should try to log me in as user 'testuser'.

i.e. if this is the config setting:

# Each supports a strategy to get this value. All default to 0. Strategy codes mean the following:
# 0 - Try request.getAttribute then request.getHeader
# 1 - Use request.getAttribute
# 2 - Use request.getHeader
header.remote_user=REMOTE_USER
#header.remote_user.strategy=0

Have I understood that correctly?

Thanks in advance.

Mark.

[Mark Mackay · Accepted solution]

Finally had the euraka-moment, and managed to get the plugin enabled.

I thought I had perhaps not enabled logging correctly, and was looking around for exmples on how to do this. And I stumbled across this page:

http://shibboleth.net/pipermail/users/2012-June/004353.html

It made reference to confluence/WEB-INF/classes/seraph-config.xml which I hadn't seen in the module setup instructions. In particular, it replaced the default:

<authenticator class="com.atlassian.confluence.user.ConfluenceAuthenticator"/>

with:

<authenticator class="shibauth.confluence.authentication.shibboleth.RemoteUserAuthenticator"/>

And voila -- everything started working. Lots of debug log entries, etc.

If going through the full Shibboleth instructions set, or if you're familiar with confluence's innards -- this was possibly a fairly obvious thing that needed to be done. But to a novice, well, let's just say I missed it.

---

So with the plugin now loading, it fully recognises my hard-coded RequestHeader values and logs the user in as i wanted it to.

I'm now working on the next step of my project, which is to try to write some PHP code to do a user-lookup in the confluence DB by email address, rather than username. This seems to be working - and i'll try to remember to post it here when I'm finished, for anyone interested. But I need to do some work to make sure it's secure and suitable for public consumption first :)

Update - May 2014: I managed to get my full solution going, at least in prototype stage -- and so I'm sharing it on the wiki to get feedback to see if there's a security hole I've missed, etc.

https://github.com/chauth/confluence_http_authenticator/wiki/Basic-PHP-SSO-for-Confluence

[Gary Weaver]

It is not a plugin, it is an authenticator, so it will not show up like a normal plugin.

REMOTE_USER is a blocked header by most servlet containers like Tomcat, etc. by default, because the intent is that servlet container could do the authentication; letting someone say who they are is completely insecure and defeats the purpose of authentication. There is a setting though if you read through the configuration that will allow that header to be passed through, so that it can be used by an external wrapping authentication solution, such as the Shibboleth SSO. However, it is suggested that you use "environment variables" (that is what some call the values which come into Java as request attributes) in Shibboleth instead of HTTP headers, in which case you would use strategy 1 in the new configuration options.

Setting up authentication is not trivial, unfortunately. You can spend weeks or longer if you have no experience in it just trying to setup the surrounding infrastructure, depending on what you are trying to setup. It is highly recommended that you do two things:

1. First ensure that even without the authenticator, you are able to send in the header(s) (request headers in Java) or "environment variable(s)" (request attributes in Java) successfully. If you don't have experience with Java development and Java container/webapp servers, you or your team should consider finding/hiring one to assist that is very familiar with the container/webapp server you are using. Preferably you will be able to test that however you have your authentication system setup, it is providing either the right header(s) or "environment variable(s)" to a test page/servlet similar to requestinfo-jsp. I've not updated that project to output Java request attributes, so you might want to fork it and make that change. The goal, however it is done, is to determine that the values being sent in are the values the authenticator gets.

2. Learn how to enable debug logging in the authenticator, and look at the output to see what is being sent it and how it is handled. This will ensure that after you do #1, you are still getting those same header values or request attributes you expect.

I wish it were easier, but that is how it works. We have very few people assisting with the authenticator project, it is free, and all work on it is volunteer, so you will need to focus on getting as much help as you can setting up your SSO and the Java container/webapp server without the authenticator and just have it be a last step in the process, hopefully one that will not take nearly as long to complete/configure.

[Mark Mackay]

I'm still struggling with this, so hoping someone can help.

I've set up a hard-coded test scenario to try to get header/attribute info through to confluence, and hopefully the Confluence HTTP Authenticator module.

In my development apache config I've added the following:

RequestHeader set CONF_USERNAME "testuser"

Then following the instructions on this page I have enabled header logging, and I see entries like:

Apr 9, 2014 10:48:06 AM org.apache.catalina.valves.RequestDumperValve invoke
INFO:             header=conf_username=testuser

So Confluence is definitely receiving the header.

My WEB-INF/classes/remoteUserAthenticator.properties file contains:

local.login.supported=true
create.users=false
update.info=false
update.last.login.date=true
reload.config=true
reload.config.check.interval=5000
default.roles=confluence-users

header.remote_user=CONF_USERNAME
header.remote_user.strategy=0
header.email=CONF_EMAIL
header.fullname=CONF_FULLNAME

username.convertcase=true
update.roles=true
convert.to.utf8=false
dynamicroles.auto_create_role=false
dynamicroles.output.tolowercase=true

I've tried with both upper and lowercase CONF_USERNAME in the properties file.

Now my (perhaps-wrong) expectation, is that when i pull up the Confluence site home page - it should show me as logged in as 'testuser'. But it's still showing nothing.

I'm still seeing absolutely nothing in the catalina.out or atlassian-confluence.log files, related to remoteAuth or shib*.

[Mark Mackay]

Thanks for the clarification and guidance Gary - I'll have a more detailed read into Shibboleth and see if I can figure it out.

Regarding the basic installation process though -- should there be any log entry generated when the authenticator is loaded by the confluence startup process/etc? I ran "start-confluence.sh -fg" and saw nothing referring to 'auth', 'remote' or 'shib' in the logs (that didn't seem like a default Atlassian plugin). And nothing in the atlassian-confluence.log file.

I had also tried adding the following into log4j.properties:

log4j.logger.shibauth.confluence.authentication.shibboleth=DEBUG, confluencelog

But still no entry on startup to indicate the code had loaded.

So is there an easy way to verify that at least the authenticator has been correctly installed?

Then I can work on the Shibboleth/custom SSO side of things and at least know it's my fault it's not working :o)