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 intranet 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: firstname.lastname@example.org)
- 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.
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).
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:
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:
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:
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 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.
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.
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)