Single Sign On (SSO) overview – Support Center

Introduction

Single Sign On (SSO) lets users gain access to a connected system or systems by only requiring they sign on once, with just one username and password.

Organizations that use the Jostle platform often use systems where they support SSO. For these organizations, the usability of their platform is enhanced if SSO can be extended to Jostle. In order to do this, the organization must become an identity provider to Jostle.

Road map to using SSO with Jostle:

If not already done, set up your SSO ( see the SSO partners )
Send Jostle the XML metadata (email: support@jostle.me)
Wait for confirmation that Jostle has applied the metadata in our system
Convert existing users from Jostle password to SSO (learn more)

For the complete list of our SSO-related content, you can jump to the section directory here.

About SSO and SAML

The rest of this document describes how SSO using SAML works between an organization and Jostle.

There are a number of standards which exist for web single sign on including WS-Federation, OpenID and Security Assertion Markup Language (SAML). The current mainstream approach to web single sign on in the enterprise space is SAML.

Web Single Sign On

There are three parties involved in a web single sign on process:

User agent (browser)
Service Provider
Identity Provider

User agent is the browser which user uses to access the Jostle. Jostle is the service provider. The organization is the identity provider since it is the user identity at the organization which is being extended to the service provider.

The sign on process proceeds as in Figure 1.

User accesses resource at service provider using browser.
Service provider (Jostle) send authentication request to identity provider (organization) through a browser redirect
The identity provider authenticates user. These steps are entirely internal matter to the identity provider.
Identity provider returns authentication response to service provider through a browser redirect.
Service provider returns requested resource to browser.

The key pieces of information return in 4 are the identity of the user (a unique identifier of a user in the identity provider, usually email address or username) and the duration for which the response is valid. The exact details of the information exchanged between the service provider and identity provider in steps 2 and 4 are dependent on the standard in use. The details for SAML will be described in the next section.

SAML

Security Assertion Markup Language is an OASIS standard which provides a framework for exchanging authentication and authorization information. The current version of the standard is 2.0. SAML defines assertions, protocols, bindings and profiles. An assertion contains security statements issued by an identity provider to the service provider. The security statement may be one of three types: authentication, attribute (property), or authorization. For single sign-on, only authentication statements are required. A SAML protocol describes how SAML elements, including assertions, are packaged in SAML request and response elements and also defines processing rules that SAML entities must follow when producing or consuming the elements. For SSO purposes, the protocol of interest is the Authentication Request Protocol. A SAML binding is a mapping of SAML protocol elements into standard messaging formats and/or communication protocols. A SAML profile describes in detail how SAML assertions, protocols and binding combine to support a defined use case. For SSO, the applicable use case is the Web Browser SSO Profile (service provider initiated).

The Web Browser SSO Profile allows service provider to choose from 4 bindings and the identity provider has 3 bindings to choose from (HTTP Redirect, HTTP POST, HTTP Artifact). Each provider is able to use the binding of its choice when sending message to the other side. The most common binding in use is HTTP POST binding, where the sending side return a page containing an HTML (XHTML) form to the browser, where the HTTP POST of the form to the other side is triggered on loading of the page using some javascript.

There is metadata exchanged between the service provider and identity provider so that each side knows about the other side. This exchange for us would be done out of band (simply just let each other know through email or some other means).

The content of the Authentication Request sent from the service provider (Jostle) to identity provider (organization), step 2 in Figure 1, is as follows:

<samlp:AuthnRequest
   xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
   xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
   ID="identifier_1"
   Version="2.0"
   IssueInstant="2004-12-05T09:21:59Z"
   AssertionConsumerServiceIndex="0">
 <saml:Issuer>https://sp.example.com/SAML2</saml:Issuer>
 <samlp:NameIDPolicy
   AllowCreate="true"
   Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
</samlp:AuthnRequest>

The information transmitted here is the identity of the service provider making the authentication request in “<saml:Issuer>”.

The content of the response to the Authentication Request sent from the identity provider to service provider, in step 4 of Figure 1, is as follows:

<samlp:Response
  xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
  xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="identifier_2"
  InResponseTo="identifier_1"
  Version="2.0"
  IssueInstant="2004-12-05T09:22:05Z"
  Destination="https://sp.example.com/SAML2/SSO/POST">
  <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
  <samlp:Status>
     <samlp:StatusCode
     Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
  </samlp:Status>
 <saml:Assertion
     xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
     ID="identifier_3"
     Version="2.0"
     IssueInstant="2004-12-05T09:22:05Z">
     <saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
        <ds:Signature
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
     <saml:Subject>
        <saml:NameID
           Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
           bob@idp.example.com
        </saml:NameID>
        <saml:SubjectConfirmation
           Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
           <saml:SubjectConfirmationData
              InResponseTo="identifier_1"
              Recipient="https://sp.example.com/SAML2/SSO/POST"
              NotOnOrAfter="2004-12-05T09:27:05Z"/>
        </saml:SubjectConfirmation>
     </saml:Subject>
     <saml:Conditions
 NotBefore="2004-12-05T09:17:05Z"
 NotOnOrAfter="2004-12-05T09:27:05Z">
        <saml:AudienceRestriction>
           <saml:Audience>https://sp.example.com/SAML2</saml:Audience>
        </saml:AudienceRestriction>
     </saml:Conditions>
     <saml:AuthnStatement
        AuthnInstant="2004-12-05T09:22:00Z"
        SessionIndex="identifier_3">
        <saml:AuthnContext>
           <saml:AuthnContextClassRef>
              urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
            </saml:AuthnContextClassRef>
         </saml:AuthnContext>
      </saml:AuthnStatement>
 </saml:Assertion>
</samlp:Response>

There is very little information being sent by the identity provider. The key piece of information returned is the user’s identity specified by the NameID field which is really the minimum piece of information which is required for SSO to operate:

<saml:Subject>
   <saml:NameID
       Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
 bob@idp.example.com
   </saml:NameID>
   …
</saml:Subject>

Security

We would configure all communications for SSO to take place using SSL (HTTPS). This means that both the service provider and identity provider must be capable of accepting HTTPS requests (port 443). Use of HTTPS also requires that a security certificate from one of the well known certificate issuers be obtained. If we want further security, SAML provides for both the signing (to prevent tampering) the messages and encrypting the messages. SAML also provides for limiting the time period during which the assertions are valid, and this time limit is usually kept short (5 minutes) to prevent replay type attacks.

SAML Products

SAML is a well established standard and there are many products, both open source and commercial which support the standard, including SSO. These products support the organizations being the identify provider and service provider.

Many organizations use Microsoft for their primary operating system, where domain controllers are used with Active Directory used as the user directory. Microsoft has a product called Active Directory Federation Services (ADFS) 2.0 which can be set up to allow such organizations to be a SAML 2.0 identity provider for SSO. The exact configuration details of ADFS as a SAML identity provider are out of scope of this document but for those organizations using Active Directory, the use of ADFS is likely the most straight forward way for them to become an SAML identity provider for SSO. There are also other open source and commercial products which serve a similar purpose.

Conclusion

In web based SSO using SAML there is minimal information exchanged between the identity provider and service provider during the single sign on. In Jostle's implementation, the only user-related data received by Jostle through the sign-on process is a secure confirmation from the organization that a user with a particular user name (work email address) should be granted access to Jostle.

References

Some useful references for SSO and SAML information:

Web Single Sign-On Systems (http://www.cs.wustl.edu/~jain/cse571-07/ftp/websso/index.html)

Wikipedia entry on SAML 2.0 (http://en.wikipedia.org/wiki/SAML_2.0)

Web Single Sign On Using SAML (http://cogprints.org/6695/1/2-41-48.pdf)

0 Comments