Overview

To increase adoption and provide a seamless experience, Deem provides single sign-on (SSO) capabilities for enterprise services, employing a wide variety of industry open standards. Through the use of SAML 2.0, an enterprise can provide seamless access for its employees without any additional user authentication, and without requiring users to remember new passwords.
For users, SSO is all about experience: fewer passwords to manage, and fewer barriers to getting their job done. Enterprise employees can automatically be provisioned and authenticated, becoming immediately productive with Deem services in a completely transparent manner. For an enterprise, SSO translates into higher adoption rates, tighter security, fewer help-desk calls, and enhanced return on existing technology investments.
By integrating Deem enterprise services with enterprise identity stores, it is also possible to include user provisioning information in the SAML single sign-on token. This allows a single process flow from the corporate Identity Provider into Deem, eliminating the need for a separate provisioning process. If the user does not already exist in the Deem system, or if there is updated information about the user, the SAML assertions may contain provisioning information, allowing for automated, simultaneous update or pre-population of the user's profile when they log in.

Note: We require SAML 2.0. The code examples in this document are based on SAML 2.0.

Introduction to SAML

Deem provides support for the Security Assertion Markup Language (SAML) to implement SSO. SAML version 2.0 is an XML-based framework for exchanging security information. SAML provides a standardized means for identity providers to issue security related statements about an identity in XML. SAML also defines an XML-based protocol for request and response of SAML assertions, so that there may be standardization of the client/server processing of these messages. SAML profiles the logistics of SAML message exchange for SSO between two SAML enabled entities, which is referred to as federation.

SAML assertions and protocol messages are encoded in XML and use XML namespaces. The structure of the SAML assertion is defined by an XML schema that is specified by the OASIS SAML standard. It contains header information, the subject, and statements about the subject in the form of attributes and conditions — such as a start and logout URL. SAML assertions and protocol messages are typically embedded in other structures for transport, such as HTTP POST requests or XML-encoded Simple Object Access Protocol (SOAP 1.1) messages.

The SAML authentication flow can start in one of two ways, Identity Provider (IdP)-initiated or Service Provider (SP)-initiated. An IdP-initiated login starts with the user first navigating to the enterprise services (IdP) and then going to Deem (SP) with a SAML assertion. A SP-initiated login starts with first navigating to Deem (SP), getting redirected to the enterprise services (IdP) with a SAML request, and then redirected back to Deem (SP) with a SAML assertion. IdP-initiated is more prone to man in the middle attacks making it less secure.

Because SP-initiated is more secure, all new implementations need to be SP-initiated and existing IdP-initiated implementations should be migrated to SP-initiated.

SAML Message Exchange

The SAML message exchange process follows these steps:

SP-initiated

• The user navigates to Deem

The user navigates to Deem using either the Deem Domain URL (https://<domain>).deem.com or the Deem Domain Start SSO URL (https://<domain>.deem.com/rc/ssoStart.do). The user is redirected to the enterprise services with a SAML request.

• The enterprise services authenticates the user

The user is authenticated using the existing security framework, such as a web access management system, authentication to an LDAP directory, or integration with Windows via Kerberos. After the user is authenticated, the system constructs a SAML assertion (see below), digitally signs the assertion, and returns it over a secure link to the browser, embedded as a hidden form field in a HTTP form. At this step, the SAML assertion may optionally include additional provisioning information about the user (see "Provisioning with SAML").

• The SAML assertion is sent to Deem. 

Using JavaScript, the HTTP form is sent to Deem over a secure link, thus passing the embedded SAML assertion. The user does not need to be prompted again for a username and password or another credential.

• The user's session with Deem begins.

Deem receives the assertion, and validates its signature using the X509v3 certificate that was provided by the enterprise when the federated trust relationship was originally established and configured. Having validated the integrity of the assertion, Deem is able to trust the identity of the user as specified in the SAML Subject attribute of the token. Based on this trusted assertion, a new user session is created and the SSO is complete. Optionally, at this point, the user may be simultaneously provisioned as part of this process, if additional user provisioning data has been provided with the token. (For more information see "Provisioning with SAML").

IdP-initiated

• The user logs into and accesses the corporate intranet.

The user logs into the corporate intranet and is authenticated using the existing security framework, such as a web access management system, authentication to an LDAP directory, or integration with Windows via Kerberos. The SAML-enabled intranet is aware of this authentication. Having validated the user, the user's browser session with the intranet is created, and the user can browse the intranet.

• The user clicks the link to use Deem services.

The corporate intranet provides a link, and the user clicks it to access Deem services. When the user clicks the link, the system constructs a SAML assertion (see below), digitally signs the assertion, and returns it over a secure link to the browser, embedded as a hidden form field in a HTTP form. At this step, the SAML assertion may optionally include additional provisioning information about the user (see "Provisioning with SAML").

• The SAML assertion is sent to Deem. 

Using JavaScript, the HTTP form is sent to Deem over a secure link, thus passing the embedded SAML assertion. The user does not need to be prompted again for a username and password or another credential.

• The user's session with Deem begins.

Deem receives the assertion, and validates its signature using the X509v3 certificate that was provided by the enterprise when the federated trust relationship was originally established and configured. Having validated the integrity of the assertion, Deem is able to trust the identity of the user as specified in the SAML Subject attribute of the token. Based on this trusted assertion, a new user session is created and the SSO is complete. Optionally, at this point, the user may be simultaneously provisioned as part of this process, if additional user provisioning data has been provided with the token. (For more information see "Provisioning with SAML").

The User's SSO Experience

Accounts for the enterprise's employees can be created for Deem services in the Partner Dashboard, uploaded in a feed from the enterprise Human Relations department, or provisioned automatically through SSO. Enterprises can also choose to allow open enrollment, which enables its employees to create accounts from the login page. Enterprises can choose whether or not to send activation emails to employees to access their accounts. By default, Deem generates an activation email with a link for accessing Deem services.
An enterprise can configure a Deem site to provide one of the following user experiences for logging in and SSO: direct-access link, "token not present" failover endpoint for deep-link access, or hybrid mode.

Direct-access link

An enterprise can configure a direct-access link to Deem services and place it in the corporate portal or intranet for employees to find. For either SP-initiated or IdP-initiated, this link can point to the Deem Company Start SSO URL, which will initiate the appropriate SAML authentication flow for the user. For IdP-initiated, this link should point to the enterprise or partner SAML service endpoint and pass the desired target to Deem. Note that it is possible to specify a TARGET or RelayState (SAML 1.1 or SAML 2.0) as either a parameter of the link or as part of the SAML token, which specifies a target other than the home page once SSO is established. If no RelayState is specified, the target defaults to the home page.

"Token not present" failover endpoint for deep-link access

Employees may want to use a bookmark rather than a direct-access link to access Deem services. A "Token Not Present" SSO error condition will occur if the user tries to access Deem services without presenting a valid SAML token as part of the request.
In this case, the user can be referred to initiate the appropriate SAML authentication flow or an error-handling endpoint within the enterprise SSO infrastructure. This endpoint can then validate the user within the intranet network context, and then seamlessly relay the user back to Deem with the appropriate SAML token. When authentication succeeds, the original desired URL is recovered from a cookie and the user accesses the desired page. This mechanism is useful for implementing SSO for bookmarks such as links to travel itineraries or notifications that are emailed to the user.

Hybrid model

Some enterprises may have two or more categories of users (such as employees and contractors) or may want to accommodate users that are not always able to connect to the corporate intranet.

Users without credentials on the corporate intranet, or who are unable to access them, are required to have issued to them separate Deem usernames and passwords in order to authenticate into Deem without relying on the intranet SSO infrastructure and identity store. By configuring a Deem site using the hybrid model, which combines a direct-access SSO link with regular login access, a user who accesses the home page without presenting a valid SAML token is shown a "hybrid login page" in which the user can enter an ID and password to log into Deem services. The "hybrid login page" also displays a link to the intranet SSO entry point — if the user has intranet credentials and the SAML infrastructure can access them, this link will initiate the appropriate SSO process for the user. If "Token not present" failover is configured for the domain, it is still possible to access other site URLs directly through SSO if the user has already been (or can be) authenticated on the corporate intranet.