...

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").

IdP-initiated

...

• 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").

Anchor
user user

The User's SSO Experience

...

<saml:Assertion ID="uuid-5D036492-5000-0DA1-02BF-68B5583580A1" IssueInstant="2013-03-16T00:02:54Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <saml:Issuer>${parterProvidedIssuerName}</saml:Issuer>
    <saml:Subject>
      <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified">bob.barker@thepriceisright.com</saml:NameID>
      <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
        <saml:SubjectConfirmationData Recipient="https://go.deem.com/sp/ACS.saml2" NotOnOrAfter="2013-03-16T00:12:54Z"/>
      </saml:SubjectConfirmation>
    </saml:Subject>
    <saml:Conditions NotBefore="2013-03-16T00:02:54Z" NotOnOrAfter="2013-03-16T00:12:54Z">
      <saml:AudienceRestriction>
        <saml:Audience>https://go.deem.com/sp/ACS.saml2</saml:Audience>
      </saml:AudienceRestriction>
    </saml:Conditions>
    <saml:AuthnStatement AuthnInstant="2013-03-16T00:02:54Z">
      <saml:AuthnContext>
        <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:Password</saml:AuthnContextClassRef>
      </saml:AuthnContext>
    </saml:AuthnStatement>
</saml:Assertion>

Customizing your SSO Configuration

Deem services for enterprises can be configured to support a wide variety of custom behaviors. You must provide the following data to your Deem Activations Manager to support a custom configuration.

...