Skip to main content

Single Sign-on (SSO) via SAML2– Authentication & Authorization

Single Sign-On (SSO)

SAML is the gold standard for single sign-on for cloud applications. It eliminates passwords and instead uses digital signatures to establish trust between the identity provider and the cloud application. The ZeroedIn Platform handles SSO via the SAML standard.

How SAML Works

SAML SSO works by transferring the user’s identity from one place (the identity provider) to another (the service provider). This is done through an exchange of digitally signed XML documents.

Consider the following scenario: A user is logged into a system that acts as an identity provider. The user wants to log in to a remote application, such as a support or accounting application (the service provider). The following happens:

  1. The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.

  2. The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.

  3. The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.

  4. The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.

  5. The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.

  6. The identity of the user is established and the user is provided with access to the application.

SAML SSO Flow

The diagram below illustrates the single sign-on flow for service provider-initiated SSO, i.e. when an application triggers SSO.


ZeroedIn supports a single sign-on interface via SAML2 authentication. In configuring the
SAML2 authentication, a secure handshake is established between the client browser
environment and the ZeroedIn service, allowing the ZeroedIn service to obtain an authenticated
user identifier.

SAML SSO & Zeroedin

There are two available mechanisms for initiating the SAML2 interface:

  1. IdP (identity provider) initiated - meaning that the user hits the client's authentication
    provider first, then is redirected to the ZeroedIn service with a complete authentication
    assertion. We check the assertion against registered user accounts, and then grant them
    access.
  2. SP (service provider) initiated - meaning that the user connects to the ZeroedIn service
    first, and is then redirected to the IdP to verify their identity, then they are redirected back
    to us as in #1.

In either circumstance, ZeroedIn performs a lookup on the user identifier to determine if a user
account currently exists in ZeroedIn. When the lookup is successful, the process performs the
necessary authorization checks and initiates the user session under the security role previously
assigned to the user account. If the lookup process is not successful, the user is denied access to
ZeroedIn and routed to a web page (configurable) informing the user of recommended actions
(e.g. contact XYZ to establish an account).


The SSO process requires that client user accounts be pre-established in ZeroedIn and assigned
one or more user or system roles that also have been previously created. In its current state, the
SSO process cannot automatically provision a new user account or alter the role assignment of a
pre-established user account.


As part of the initial implementation, a user account synchronization process will be established
to batch create user accounts and assign roles, including data filtering restriction (e.g. on brand,
region, and/or district), from a data file that is sent on a recurring basis from client to ZeroedIn.

The following applicatoin system settings are used in the configuration of single sign-on:

System Setting Description
invalidDestination URL Location where system will direct the user if authentication is
not successful. Default is <blank> which directs the user to the
application native login page.
Example:
invalidDestination = “http://www.site.com/login.asp";
logoutDestination

LogoutDestination URL location where system will direct the user upon logout. Default
is <blank> which directs the suer to the application native login

Example:
logoutDestination = "http://www.site.com/portal/";

The above system settings work in conjunction with the automated login process. If the
automated login process determines that the user does not authenticate or any part of the login
process fails, then the user is directed to the webpage identified in the system setting
“invalidDestination”. If no value is present in invalidDestination, then the user is directed to the
application’s native login screen.


Because users can be directed to ZeroedIn from an external site (e.g. Enterprise Portal or HR
System), ZeroedIn can return users to that site or another desired location rather than returning
them to the application’s native login screen. The value of the system setting
“logoutDestination” determines where the user is directed upon exiting Impact Suite. If no value
is present in logoutDestination, then the user is directed to the Impact Suite native login screen
upon exiting the system.

Configuration

The process for setting up SSO via SAML starts with the trading of SAML XML Metadata.  This metadata identifies and describes the appropriate settings and information used during an SSO event.  Below is a sample of ZeroedIn’s SSO Metadata:

<md:EntityDescriptor xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" validUntil="2017-06-22T19:20:01Z" cacheDuration="PT604800S" entityID="https://hosted-dev.zeroedin.com/secure/login/CLIENTZONE>

<md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="false" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">

<md:KeyDescriptor use="signing">

<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:X509Data>

<ds:X509Certificate>

MIIEHz….SoD2wTL+UKGRpd6ZOR

</ds:X509Certificate>

</ds:X509Data>

</ds:KeyInfo>

</md:KeyDescriptor>

<md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://hosted-dev.zeroedin.com/secure/saml2_slo/tda"/>

<md:NameIDFormat>

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

</md:NameIDFormat>

<md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://hosted-dev.zeroedin.com/secure/saml2_acs/clientzone" index="1"/>

</md:SPSSODescriptor>

<md:Organization>

<md:OrganizationName xml:lang="en-US">zeroedin_platform</md:OrganizationName>

<md:OrganizationDisplayName xml:lang="en-US">ZeroedIn Platform</md:OrganizationDisplayName>

<md:OrganizationURL xml:lang="en-US">https://hosted-dev.zeroedin.com/</md:OrganizationURL>

</md:Organization>

<md:ContactPerson contactType="technical">

<md:GivenName>Neal Anders</md:GivenName>

<md:EmailAddress>neal@zeroedin.com</md:EmailAddress>

</md:ContactPerson>

<md:ContactPerson contactType="support">

<md:GivenName>ZeroedIn Support</md:GivenName>

<md:EmailAddress>support@zeroedin.com</md:EmailAddress>

</md:ContactPerson>

</md:EntityDescriptor>


ZeroedIn provides both Development and Production environments in which SAML SSO is supported.  Having both environments support SAML SSO allows greater flexibility for implementation and ongoing support, particularly when making changes or upgrading the security and SSO interface.

 

No Comments
Back to top