Single Sign-On Salesforce (SSO) is a facility for all users by which they can manage all accounts using one login they no need to do manage more accounts (User Id and Passwords). Single Sign-on Salesforce user gain access in multiple sites using just a single login. Salesforce Single Sign On (SSO) is an independent software system.
There are two way to enable Salesforce Single Sign On (SSO) for your system
- By cookies
- By LDAP(Light Weight Directory Access Protocol)
How Single Single on Salesforce User login works and how a single sign-on salesforce access to multiple accounts.
(Diagram is taken from the link http://www.opengroup.org/security/sso/sso_intro.htm)
SSO is a concept of federated identity. In IT language federated identity meaning is to linking users’ electronic ids and all attributes and stored in different systems for user identity management.
How we achieve Single Sign-On Salesforce (SSO)?
There are three federated identity Standards:
We are discussing here SAML-Single Sign-On Salesforce (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)
- User (Web-Browser)
- Identity Provider (Authorization Server)- Users authenticate with the IDP
Advantages of SAML:
- SAML is Platform neutral.
- Loose Coupling of directories.
- Reduced administrative costs for service providers.
- Risk transference
Disadvantage of SAML:
- SAML is not mobile friendly
- 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 Outlook you 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:-
Understanding SAML-based Single Sign-On Salesforce (SSO) for Google Apps
Here I am taking the example of SAML based SSO for Google Apps from the given link.
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.
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.
Figure: Logging in to Google Apps using SAML
This image illustrates the following steps.
- The first User attempts to reach his application from the browser.
- Google generates a SAML authentication request. The SAML request is encoded and embedded into the URL for the partner’s Single Sign-On Salesforce(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.
- 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.
- 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.
- 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.
- 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.
- 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.