april 20, 2017
When I first encountered the scenario of getting Shibboleth to work with Sitecore, I started hitting up the Google pretty hard. I had done a lot of Windows-based SSO before but Shibboleth wasn’t something I was used to. This is what I found with “Sitecore Shibboleth”:
This is what I found with “Sitecore Shibboleth”:
- http://jockstothecore.com/federated-authentication-with-shibboleth-2/
- http://shibboleth.1660669.n2.nabble.com/Sitecore-HttpModule-on-IIS-vs-Shib-td7616178.html
Nothing introductory. Nothing to walk you through “Hey, you don’t know Shibboleth or how to use it? Here is how you get Sitecore to play nice”. Just an indication that at some point in the process there may be a bug with headers. So I guess I was going to do it the hard way and actually learn this Shibboleth thing :)
Shibboleth SSO and Sitecore
If you are in the same scenario I was, you do not need to read all about the why and what, and need to get down to how, so let’s start with that.
When you install a Shibboleth service provider, it is going to act as a gatekeeper. Shibboleth will block requests for a secure application and send them to the identity provider. Users will be allowed to pass through to Sitecore only once the Shibboleth service provider is satisfied that the authentication has completed.
This flow hinges on Sitecore ignoring the Shibboleth requests. By default, the path “Shibboleth.sso” needs to be in your ignore URLs configuration. The links I found when searching before hinted that older versions of Sitecore didn’t do this well, but I found that Sitecore 8.2 update 2 seemed to be handling this just fine. If you find Sitecore isn’t ignoring, you might need the patch from Sitecore mentioned in the Brainjocks blog.
Enough general stuff, here’s how you get started:
- Head over to Sitecore MVP Jason St-Cyr's GitHub repo and follow the ReadMe for installing and configuring your Shibboleth Service Provider
- Download the solution, compile, and deploy to your instance.
- Configure the config file as needed for your header keys.
At this point, you will have:
- A Shibboleth service provider intercepting all requests to the entire Sitecore instance
- Sitecore configured to ignore the Shibboleth.sso paths
- A pipeline that will authenticate the user to Sitecore as a virtual user with the details received from the identity provider.
Some common issues I ran into:
- The Identity Provider (IdP) needs to be able to reach your Service Provider (SP), so you need to make sure your installation has an external IP your IdP can see, or you need to install an IdP on the same network/machine as your SP for development purposes.
- Keystore passwords and X509 certs are in some of the config files that get configured for the IdP and SP, so don’t pass those configs around to each other blindly. Otherwise, you will get cert signing issues.
- Configuring your attribute_map.xml is very important, otherwise there will be no headers to read. If you see no user properties in the Request.Headers while debugging, then it is likely an attribute map issue.
- Just like with Sitecore, make liberal use of the logs. The online search results are not super helpful in a lot of scenarios and you need to be able to do some debugging first to get the right keywords to search for.
- If it seems like Shibboleth isn’t running, it might not be. Make sure the service is running in the windows Services list. If it isn’t, there may be a startup error that is killing the process.
Sitecore and the ‘Always Authenticated’ Intranet
If you hadn’t already heard, Sitecore is starting to have more and more traction as an optimal technology solution for your next Intranet project. Combined with tools such as Telligent and Coveo, you can really start to pull together all of your content and manage your publication in a way that makes sense. This brings about using Sitecore in a slightly different context than you might be used to and will also bring in a lot more integration work, authentication scenarios, but also allows you to leverage the experience management of Sitecore to deliver more personalized resources to your user base.
In almost all intranet scenarios, your user base can be identified. This really allows you to leverage xDB with identified contacts and provide multi-device learning and personalization experiences. Are you usually working at the office, but sometimes remotely, and on your phone in between? With an identified user Sitecore can tie all this behaviour together and deliver you a consistent personalized experience as you move between your working models.
Bringing SSO into the Mix
Having an ‘Always Authenticated’ experience is pretty awesome, but it does bring about an identity management issue. Intranets are often portals into the variety of digital applications and resources that your organization uses and your employees expect to be able to seamlessly transition from one to the other. This integration requires Single Sign-On (SSO) and most likely a centralized identity management system to make sure you can easily manage the identities of your users from a central location and allow all your applications to have a single flow for authentication.
What’s this Shibboleth thing?
Shibboleth comes onto the scene as a free open-source project that provides Single Sign-On capabilities. It happily runs on Windows or Linux systems, making it a popular choice in verticals such as Higher Education. You can configure your SP to protect some, or all, of your application without needing to make any changes to your application. The only change you need to make is to consume any headers passed by the IdP if you would like to read attributes about the user that has logged in. This non-interfering installation approach is useful when working with many different applications that may not have a consistent implementation language or platform.
If you are interested in learning more about using Sitecore as an Intranet solution, check out our webinar and our demo of a Sitecore-Telligent solution.
