Single Sign-On (SSO) - Feature Overview

Overview

Single Sign-On (SSO) is a session/user authentication process that permits a user to enter one set of credentials in order to access multiple applications. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when they switch applications during a particular session.

There are various types of SSO, and 'Identity Provider Initiated Logon' is what RLDatix uses for implementation. When a user is logged into your organisation's network and clicks a link to Assure Expenses, a message will be sent to your Identity Provider which will acknowledge that the user is on the network. The Identity Provider then sends an encrypted access token to Assure Expenses which is decrypted, then the user is confirmed, and access is granted to the product.

How It Works

How Identity Provider Initiated Logon Works - Less Techie

This assumes that you are a user logged in to your network and you want to access Assure Expenses.

You begin by clicking on a link to Assure Expenses. This doesn’t go directly to Assure Expenses but sends a message to your Identity Provider (IdP) e.g. Active Directory. It says:

"You know who I am (because I am logged onto the network), please give me a token that I can send to Assure Expenses so that they know who I am".
The Identity Provider sends you the token and the link you are on sends the token to Assure Expenses.
Assure Expenses unencrypts the token and says:

"I know who you are and I will log you on".

How Identity Provider Initiated Logon Works - More Techie

Identity Provider Initiated Logon ensures that a user logs into an application or service once. This validates the identity of the user (IdP). Any other applications or service providers (SP) are sent a Security Assertion Markup Language declaration (SAML Assertion) that identifies the user. Due to the trust relationship that is in place (via Security Certificate Encryption) the SP then allows the user access with no further verification of the user's identity.

Assertion Attributes and user validation

A SAML 2.0 Assertion declares a user’s identity. This is done using definable elements called 'attributes'. These are included in the SAML 2.0 Assertion and are encrypted to ensure security.

These statements are usually different for each Service Provider and will be configured separately within the Identity Provider setup.

Identity Providers

There are multiple Identity Providers available. These range from solutions like Active Directory, which is integrated into your IT infrastructure to cloud-hosted solutions such as Ping, Okta and OneLogin. Existing web-based applications like Salesforce can also act as an Identity Provider.

An internet search will provide a list of Identity Providers.

High Level Process Diagram

Sample SAML Response

This section provides some information to help those who might self-craft the SAML response.

About sending the response

For the Single Sign-On HTTP request, the SAML response is base64 encoded and sent as a POST variable with the name “SAMLResponse”.

About the sample Response

The sample below is descriptive only. Some security information has been removed and replaced with a description.

<samlp:Response ID="_75fa1802-164c-45f6-b99d-d4f2d4edc07b" Version="2.0" IssueInstant="2015-10-08T13:24:11.889Z" Destination="https://www.sel-expenses.com/shared/sso.aspx" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
       <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs.selenity.com/adfs/services/trust</Issuer>
       <samlp:Status>
              <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" />
       </samlp:Status>
       <Assertion ID="_77e4bd63-5fd5-4dc0-a737-c037e277fd9d" IssueInstant="2015-10-08T13:24:11.889Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
              <Issuer>http://adfs.selenity.com/adfs/services/trust</Issuer>
              <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
                     <SignedInfo>
                           <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                           <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
                           <Reference URI="#_77e4bd63-5fd5-4dc0-a737-c037e277fd9d">
                                  <Transforms>
                                         <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                                         <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                                  </Transforms>
                                  <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                                  <DigestValue>{{ENCRYPTED VALUE}}</DigestValue>
                           </Reference>
                     </SignedInfo>
                     <SignatureValue>{{ENCRYPTED VALUE}}</SignatureValue>
                     <KeyInfo>
                           <ds:X509Data xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                                  <ds:X509Certificate>{{ENCRYPTED VALUE}}</ds:X509Certificate>
                           </ds:X509Data>
                     </KeyInfo>
              </Signature>
              <Subject>
                     <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                           <SubjectConfirmationData NotOnOrAfter="2015-10-08T13:29:11.889Z" Recipient="https://www.sel-expenses.com/shared/sso.aspx" />
                     </SubjectConfirmation>
              </Subject>
              <Conditions NotBefore="2015-10-08T13:24:11.889Z" NotOnOrAfter="2015-10-08T14:24:11.889Z">
                     <AudienceRestriction>
                           <Audience>https://adfs.selenity.com/adfs/services/trust</Audience>
                     </AudienceRestriction>
              </Conditions>
              <AttributeStatement>
                     <Attribute Name="company">
                           <AttributeValue>{{YOUR COMPANY ID}}</AttributeValue>
                     </Attribute>
                     <Attribute Name="email">
                           <AttributeValue>{{EMAIL ADDRESS OF EMPLOYEE}}</AttributeValue>
                     </Attribute>
              </AttributeStatement>
              <AuthnStatement AuthnInstant="2015-10-08T13:24:11.858Z">
                     <AuthnContext>
                            <AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
                     </AuthnContext>
              </AuthnStatement>
       </Assertion>
</samlp:Response>

Features & Benefits

Efficient Login - Reduced password fatigue from different user name and password combinations.
Reduced Administrative Burden - Less administrative expenditure due to a lower number of IT help desk calls regarding login queries.
Maintainable Information - Ability to remove a leaver from multiple systems with minimal input.
Shared Authentication - SSO shares centralised authentication servers that all other applications and systems use for authentication, ensuring that user credentials are secure.

Feature	Description
Network User Login	Log into multiple products with one set of credentials.
SSO Action Logging	Actions logged to allow improved maintenance and issue management.

Implementation

SSO is a licenced product. Contact your RLDatix Account Manager (accountmanagers@selenity.com) to enable Single Sign-on configuration within Assure Expenses.
You will need the support of your IT department in setting up SSO on your system. There are various parts which need to be set up in your Identity Provider (e.g. Azure Active Directory, Salesforce).
Read our guide on configuring SSO within Assure Expenses.