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.
As per the 'Installation' instructions at https://github.com/chauth/confluence_http_authenticator;I have:
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.
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:
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:
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.
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.
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:
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)
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*.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
This September 6-7, hundreds of Atlassian App developers will flock to Barcelona Spain to build skills, discover product roadmaps, meet face-to-face with the Atlassian team, and learn how to extend t...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs