Single Sign-On (SSO) is a simple idea that can quickly cause developers not-so-simple headaches. At a high level, it’s very straightforward: SSO is what allows you to sign into Gmail and switch over to Google Calendar or YouTube without typing your password in again. It’s so common that you probably use it every day without thinking – and so do your users.

Like most “simple” things in software engineering, making single sign-on work on the backend can be painful. Stormpath already makes SSO between your applications easy with our ID Site solution, and we recently rolled out support for another flavor of single sign-on: SAML.

What is SAML?

SAML (Security Assertion Markup Language) is a standard for exchanging authentication and authorization information between parties. As far as standards go, it’s a relatively old one – it was ratified over a decade ago. As a result, it’s been adopted by a large number of identity providers, such as Salesforce, Okta, OneLogin, and Ping Identity (to name a few).

SAML allows you to sign into a site with your credentials from one of these providers. If you’ve ever used your Salesforce credentials to log in somewhere that wasn’t Salesfoce, for example, you’ve used SAML.

Service Providers vs. Identity Providers

The terminology of SAML can be a little confusing at first glance. There are two main entities:

  • The SAML Service Provider (SP) – This is your application, which will ask an IdP for authentication information when a user tries to log in.
  • The SAML Identity Provider (IdP) – The service that stores the user’s actual credentials – such as Salesforce, OneLogin, or an open-source system like Shibboleth.
  • Easy SAML SSO for Your .NET Applications

    A downside of SAML being an old standard is that it relies on paradigms from the early-2000s, namely every developer’s favorite way of tearing out their hair expressing data: XML. This is one of the reasons why many teams find it difficult to quickly implement SAML.

    Never fear! The SAML support in the Stormpath .NET SDK can significantly decrease the time (and pain) it takes to implement SAML login in your .NET application.

    If you’re using an older version of the SDK, be sure to update to release 0.5 or greater. That release contains all the SAML goodies.

    Then, follow the SAML configuration guide to set up a Stormpath Directory with SAML credentials, and configure your identity provider on the other side.

    Time for some code! You’ll need a SAML login controller which constructs a special URL and redirects the user:

    After the user authenticates with the external identity provider, Stormpath will redirect the browser back to the callback URL that you defined. (Make sure this URL is in your Application’s authorized callback URI list!)

    The callback controller will need to handle the incoming assertion:

    That’s all there is to it!

    Further Reading

  • Upcoming SAML CRUD support in the SDK. (Configure your SAML Directory from code instead of the Stormpath UI.)
  • Stormpath SAML documentation and setup guides