Introduction to Single Sign On (SSO) and SAML

Author

mirketa

August 7, 2015

Single Sign On (SSO) is a facility for all users by which they can manage their all accounts using one login they no need to do manage more accounts (User Id and Passwords). In SSO user gain access in multiple sites using just single log in. Single Sign On (SSO) is independent software system.

Salesforce single sign on There are two way to enable Single Sign On (SSO) for your system

We are discussing here About SAML-Single Sign On (SSO)

SAML (Security Assertion Markup Language)

Security Assertion Markup Language (SAML) is an XML standard that allows secure web domains to exchange user authentication and authorization data. Using SAML, an online service provider can contact a separate online identity provider to authenticate users who are trying to access secure content. (Definition taken from Google).

There are three main player part of SAML:

Service Provider (this is the web-server user is trying to access)

1. User (Web-Browser)
2. Identity Provider (Authorization Server)- Users authenticate with the IDP

Advantages of SAML:

SAML is Platform neutral.

1. Loose Coupling of directories.
2. Reduced administrative costs for service providers.
3. Risk transference

Disadvantage of SAML:

SAML is not mobile-friendly

1. SAML requires SSL certificates to provide digital signing and encryption of assertion.

(for more details about SAML you can visit here: http://saml.xml.org)

Note:- It is important to note that the SSO solution only applies to web applications. If you want to enable your users to access Google services with desktop clients such as Outlook for example, providing POP access to Gmail using Outlookyou will still need to provide your users with usable passwords and synchronize those passwords with your internal user database using the Admin SDK’s Directory API. In addition, when synchronizing your passwords, it is useful to understand how users are authenticated using the admin control panel login URL.

The Google Apps SSO service is based on the SAML v2.0 specifications. SAML v2.0 is supported by several widely known vendors. For more details, you can visit here:-
(https://developers.google.com/google-apps/sso/saml_reference_implementation)

Understanding SAML-based Single Sign-On (SSO) for Google Apps

Here I am taking the example of SAML based SSO for Google Apps from the given link.
(https://developers.google.com/google-apps/sso/saml_reference_implementation)

In this blog, I am showing you how SAML Based SSO works.

The following process explains how a user logs into a hosted Google application through a partner-operated, SAML-based SSO service.
The figure shown below illustrates the process by which a user logs in to a Google Apps application, such as Gmail, through a SAML-based SSO service. The numbered list that follows the image explains each step in more detail.

Note: Before this process takes place, the partner must provide Google with the URL for its SSO service as well as the public key that Google should use to verify SAML responses.

This image illustrates the following steps.

First User attempts to reach his application from browser.

1. Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner’s Single Sign On (SSO) service. The RelayState parameter containing the encoded URL of the Google application that the user is trying to reach is also embedded in the SSO URL. This RelayState parameter is meant to be an opaque identifier that is passed back without any modification or inspection.
2. Google sends a redirect to the user’s browser. The redirect URL includes the encoded SAML authentication request that should be submitted to the partner’s SSO service.
3. The partner decodes the SAML request and extracts the URL for both Google’s ACS (Assertion Consumer Service) and the user’s destination URL (RelayState parameter). The partner then authenticates the user. Partners could authenticate users by either asking for valid login credentials or by checking for valid session cookies.
4. The partner generates a SAML response that contains the authenticated user’s username. In accordance with the SAML 2.0 specification, this response is digitally signed with the partner’s public and private DSA/RSA keys.
5. The partner encodes the SAML response and the RelayState parameter and returns that information to the user’s browser. The partner provides a mechanism so that the browser can forward that information to Google’s ACS. For example, the partner could embed the SAML response and destination URL in a form and provide a button that the user can click to submit the form to Google. The partner could also include JavaScript on the page that automatically submits the form to Google.
6. Google’s ACS verifies the SAML response using the partner’s public key. If the response is successfully verified, ACS redirects the user to the destination URL.
7. The user has been redirected to the destination URL and is logged in to Google Apps.

So yes, that’s pretty much it. Please try it for yourself and feel free to ping me, I would love to help you out on this.

Pranshu Goyal, Director of Products at Mirekta, states: “We envision DSM to be used by every small to a medium-sized organization dealing with bad data and want to get rid of duplicates easily with no cost. We have faced issues dealing with duplicates in our organization. That inspired us to make a solution that is not only simple to use but can be used widely to make the organization’s data clean to make them more efficient and productive. We want DSM to be a solution for every organization looking for duplicate management capability better than the Salesforce out-of-the-box solution with no additional cost.”