One of Cybera’s newest projects involves creating a pilot Identity Federation for Alberta K-12 School Authorities. This Identity Federation, known as MyUnifiED, will give participating school staff and students the ability to log into different web services using their school’s login account — they no longer need to have a separate set of credentials stored at each service.
Cybera is still in the early development phase of this pilot, but in order to provide some demos and proofs of concept, we wanted to deploy a few small services on MyUnifiED that support federated logins.
Cybera’s wiki, wiki.cybera.ca, is central to the MyUnifiED project. Both Cybera and the schools involved in this pilot use the wiki to share information and communicate with each other. Enabling the wiki to support federated logins from the federation we’re building was an obvious first step. Plus, since we use Confluence, one of the most popular wiki platforms, we assumed it would easily support SAML (the underlying technology that handles the federated login). This all seemed simple and obvious, right?
An initial search showed that Confluence did indeed have a few SAML plugins, but they appeared to only support a single IdP (Identity Provider) endpoint — useful if an organization wants to federate logins for themselves, but not if they want to offer the service as part of a Federation.
Then we came across this plugin, Confluence HTTP Authenticator, which has explicit instructions about authenticating via Shibboleth (a popular IdP server). Perfect!
After a few days of fumbling around, we were able to get the plugin working. That’s when we noticed something: because the plugin instructions had us override the Confluence “Login” button to point to Shibboleth, all logins would now be handled by Shibboleth. Our wiki would no longer be able to use non-federated accounts.
In effect, our wiki now looked like this:
When we wanted this:
We weren’t sure how to proceed, but then we saw that BCNet’s wiki login page had exactly what we were looking for:
It has a Shibboleth link for federated logins and the standard Username/Password boxes for local logins — perfect!
We reached out to BCNet / SFU and they were more than happy to share their solution. They use a plugin written by NORDUnet for Atlassian Crowd… Wait, what?
Crowd is a product by Atlassian, the same company who makes Confluence, that provides a single sign-on system for Atlassian-based products. NORDUnet took it a step further and wrote a Shibboleth plugin for Crowd, thus turning Crowd into a more general federated gateway for Atlassian-based products.
With Crowd in place, this is how we imagined what our federated wiki service would look like:
So off we went to install Crowd and the NORDUnet plugin. Installing Crowd wasn’t terribly hard. Atlassian products have the same installation instructions, and since we were already familiar with Confluence and Jira, Crowd only took an hour to install.
Once Crowd was running, we moved onto the plugin. We started reading the installation instruc… hmm. This plugin seemed to be very light on documentation. We checked the Issues page to see if anyone has reported any problems, and yes, there was one called Documentation — so, lack of documentation is definitely an issue here.
Fortunately, that page gave us enough information to get moving. Along the way, we had to make some minor Java fixes and even write an Installation Guide.
Once we had the plugin built and installed, we were stuck again. This time, we had no idea how to actually use it. SFU came to the rescue again and gave us some helpful pointers that allowed us to successfully log into the Crowd demo application.
With Crowd and Shibboleth confirmed as working, we moved onto configuring Crowd and Confluence. Fortunately, Atlassian has a very detailed document about how to do that.
As we worked our way through the instructions, we came across a curious statement:
… if you enable Crowd SSO integration, you will only be able to authenticate as users from the Crowd server defined in the crowd.properties file. To log in using a user from another directory, such as the Confluence Internal Directory, you will need to disable Crowd SSO by reverting back to the default Confluence authenticator.
So in order to enable Crowd Single Sign-On, we have to disable local logins!?
It turns out that’s indeed true. The workaround is to import all local Confluence users into Crowd so that a local logins appear to take place, when the login is actually happening on Crowd. Clever.
OK, so let’s update our system diagram. We now have:
And with this in place, we finally had our federated wiki service that also supported local accounts, right?
Unfortunately, no.
Our first question of the updated wiki service was, “Can it also be used for CAF?” CAF being the Canadian Access Federation — a federal Identity Federation run by CANARIE. It was a good question. Can it? And if so, how?
A quick Google search showed that services can easily be part of multiple federations by configuring their local Discovery Service. An identity discovery service, in short, enables a foreign user to locate their local home so they can type in their username and password. For more information, see this demo from SWITCH.
So we needed to implement a discovery service. A cursory look at available tools resulted in:
● Shibboleth EDS: Unfortunately, no packages available for Ubuntu Linux and we didn’t want to invest the time in compiling them.
● DiscoJuice: We ran into too many JavaScript errors and gave up.
● pyFF: A simple Python Metadata aggregator. SURFconext even has an example of how to use it. Sold!
With pyFF in place (acting as the multi-federation discovery service) our system diagram now looks like this:
And now it’s complete.
Epilogue: after getting Crowd and the NORDUnet plugin working, we discovered that the initial Confluence SAML plugin we tried using really did support local logins. We just didn’t understand how to enable it at the time. However, we still decided to keep Crowd since Cybera also uses Atlassian Jira, and has plans to investigate other Atlassian products.