Shibboleth Authenticator for Confluence

Overview

A seraph authenticator for Confluence for Shibboleth (tested with Shibboleth 1.3 and 2.0)

Installation

• Copy the jar file above into Confluence's WEB-INF/lib directory (and backup existing file).
• Copy the sample config file above into Confluence's WEB-INF/classes directory (and backup existing file).

Configuration

• See How to Shibbolize Confluence for more info.

Support

This plugin is supported by those that use it (the best kind of support!). It is not supported by Atlassian yet. If you need assistance with functionality of the plugin itself please go to http://developer.atlassian.com/jira/browse/SHBL and search for your issue. If you find it, vote for it, watch it, and add a comment to let us know about it. If you can't find an existing ticket, please create one. If you do create a ticket, it helps us to have debug logging (see "How to Turn on Debug Logging" section below).

If you're having any trouble configuring Shibboleth or Apache/Tomcat with Shibboleth in-general, please first pose your question(s) on the shibboleth users list: shibboleth-users@internet2.edu. There are folks on that list using the authenticator as well. To subscribe to that list (which I'd suggest doing, if you haven't already) go to: https://mail.internet2.edu/wws/subrequest/shibboleth-users

How to Turn on Debug Logging

It helps to have debug logging of the plugin itself if something is wrong, so you can do the following to turn on debug logging, and then you can send the part of the log with the issue in the ticket (or attach the log as a file if the section is more than several lines long). To turn on debug logging, you can edit your .../confluence/WEB-INF/classes/log4j.properties file, add the following line and restart Confluence. Then after a login copy the relevant part of the confluence log into the Jira ticket in our Jira project or just attach it as a file:

For Shibboleth Authenticator for Confluence v1.0, v1.1, and v1.2 use:

log4j.logger.edu.georgetown.middleware.confluence=DEBUG, confluencelog

For building Shibboleth Authenticator for Confluence from trunk and for Shibboleth Authenticator for Confluence v1.3+, use:

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

(Those are assuming that you have "log4j.appender.confluencelog=org.apache.log4j.ConsoleAppender" defined above it, otherwise basically do whatever you need to to enable debug logging for that package.)

Development

If you'd like to get involved in this plugin's development, please let us know. Either leave us a comment on this page or feel free to contact us directly.

Version History

Troubleshooting

• Logout may not work properly. A workaround is to alter the logout page to indicate that the user must completely close the browser application to logout. Editing the logout page messages can be done in the ConfluenceActionSupport.properties file (/confluence/WEB-INF/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties). ConfluenceActionSupport.properties has the following message properties for the logout page: title.logout, com.atlassian.confluence.user.actions.LogoutAction.action.name, successful.logout.message, and logout.login.again. A search on any of those should bring you to the right spot. While not recommended, you're also able to edit the logout.vm file (/confluence/logout.vm) directly. Additionally, you will likely need to update any language packs you've installed (and in Confluence 2.6.0+, ConfluenceActionSupport.properties is embedded within one of the jars in Confluence, so you may need to extract it to find the properties you need to update and then just create a ConfluenceActionSupport.properties that overrides those properties or create a new language pack where those properties are changed).

• There may be an issue in v1.0 using the current authenticator with Confluence massive running with more than one node (CONF-9040) in which there is a unique constraint exception being thrown from Hibernate/Oracle when the user gets autocreated. The reason may be that the authenticator is being called at the same time by both nodes in when userManager.getUser() for the thread on server1 returns null and the userManager.getUser() is called for the thread on server2 which also returns null. The way this could be coded around is to do a try catch around createUser() and ignore unique constraint errors, however it doesn't seem right that the authenticator is being called on both servers for a single login, so this was logged as a bug in confluence. Please click on the link above and vote on this issue if you are getting unique constraint exceptions from the authenticator when using massive.

• Migrating from os_user schema to atlassian-user schema (see How to Improve User Search Performance) will fail if you've used v1.0 of this authenticator to autocreate users, since it creates users with null passwords (even though the Confluence API supports creating users with null passwords, there was a bug in earlier versions of Confluence that cause Confluence to fail migration of these users - https://jira.atlassian.com/browse/CONF-9117). The two workarounds provided by Atlassian support are to arbitrarily set a password with those users that have null passwords prior to the migration (via SQL update) (this works, but it is a little scary since you are giving a password hash field an arbitrary value, and this value is migrated also to the users table in the schema) or upgrade to the latest version of Confluence that fixes this problem (2.5.8 and 2.6.x+).