I’ve recently had the pleasure of figuring out how to set up SAML-based single signon. This was for a SaaS offering (at Glance Networks, my employer). Here are some of the things I learned along the way. I set up a so-called SAML Service Provider: a service that gets information about user identities from Identity Providers.
Single-signon is a helpful feature for end-users of Software-as-a-service systems. It permits them to sign on just once, to some “master” service. That master service can then vouch, securely, for their identity to other services. This means the master service can carry full responsibility for authenticating users. It allows centralization of security rules as two-factor authentication.
What’s the standard?
SAML 2.0 is the current standard for single signon in larger organizations. Organizational directories offer SAML front-ends. Active Directory Federation Services is the Microsoft offering. The Shibboleth consortium offers software and services, and is widely used in universities. SAML 2.0 is a stable standard.
How to get started?
Sign up for free or trial accounts on OneLogin.com and/or Ping Identity. Both these SaaS companies offer SAML identity provider services. You can use them to familiarize yourself with the concepts. OneLogin offers a very helpful Developer Portal you can use, including open-source code you can integrate.
Onelogin’s service is very forgiving. Ping’s is pickier about the details of the transactions. The Ping error messages are explicit and helpful. Salesforce.com’s identity provider service gives very unhelpful error messages.
There’s a data item that’s sometimes called an Entity Id, and sometimes called an App Id. It’s called a Display Name by onelogin.com. The value of this chunk of data must be the same in the identity provider and the service provider; ideally it you should make it globally unique by embedding a domain name you control in it. If this blog were a SAML service provider, I’d give it the Entity Id value of “plumislandmedia.net/sp/1”.
Stuff to Watch Out For
Salesforce.com offers an identity provider for its customers. This is handy for web app offerings used by companies that use Salesforce. But there’s a gotcha. Salesforce claims to provide both Http-Redirect and Http-Post service endpoints for requesting user authentication. Salesforce’s Http-Redirect endpoint does not work. You will need to use the Http-Post endpoint.
Encrypted Assertion messages
Identity providers send messages — they’re called Assertions — to service providers when they vouch for users. These messages are always cryptographically signed. They can also be encrypted if the policy of the identity provider requires. If your web sites use https, encrypting Assertions is redundant. If you can avoid encrypted Assertions when configuring an identity provider, you should do so.
If not, be aware that the Java-based SAML package (Shibboleth) handles Assertion encryption / decryption somewhat differently from Dot Net. My implementation was in Dot Net. I needed to insert some extra stanzas into encrypted assertions. Here’s the code.