Single Sign on in Salesforce

Single Sign On (SSO) in Salesforce enable users to authenticate using their identity from an external system. Join us to learn about what is Single Sign-on (SSO) in Salesforce and different Salesforce SSO Flows. Let start our complete guide for Salesforce SSO.

What is Single Sign on in Salesforce?

Salesforce Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials. This is also called as Identity Flows.

Why SSO is so great?

How to implement Single Sign-on in Salesforce

There are three mechanisms which can be used to achieve this in Salesforce.

1. Delegated authentication
2. Federated Authentication
   • SP-Initiated SAML
   • IDP-Initiated SAML
3. OpenID Connect

Let see them in Details

1. Delegated authentication

Using delegated authentication, Force.com does not validate passwords but instead uses an external Web service to validate user credentials. When a user attempts to login, the platform checks the user’s profile to see if they are enabled for SSO. If so, it makes a Web services call to the the endpoint specified for the organization (environment), asking it to validate the username and password. The Web services checks the credentials against an identity store (for example LDAP or OpenID) and either returns “true” or “false”. If true, the user is granted access to the application and proceeds normally. If false, the user is informed that their credentials are invalid.

2. Federated Authentication

As with delegated authentication, federated authentication does not validate the user’s actual password on the Force.com platform either. Instead, the platform receives a SAML assertion in an HTTP POST request. The SAML assertion has a limited validity period, contains a unique identifier, and is digitally signed. If the assertion is still within its validity period, has an identifier that has not been used before, and has a valid signature from a trusted identity provider, the user is granted access to the application. If the assertion fails validation for any reason, the user is informed that their credentials are invalid. The rest of this article shows how to set this up.

3. OpenID Connect

This leverages OAuth web server or user agent flows to establish trust. OpenId Connect authenticate users without having to get your hands dirty with passwords. Consume OpenID Connect from popular Identity providers with Social Sign-On. Provide a single, branded Identity to your own users and applications using OpenID Connect.

We’ll look at steps and considerations for the following single sign mechanisms:

• SAML Service Provider Initiated SSO
• SAML Identity Provider Initiated SSO
• OpenID Connect (Social Sign On)
• Delegated Authentication

Single Sign-On Use Cases in Salesforce

There are two use cases to implement Single Sign-on in Salesforce. Where Salesforce can be Service Provider/Relying Party (IdP) or Salesforce as the Identity Provider/ OpenID Connect Provider.

1. Salesforce as the Service Provider (SP)

If your customer already has an identity/authentication provider, you can configure Salesforce as the service provider or relying party. Users are logged in to Salesforce org from an identity / authentication provider, which authenticates their credentials.

When we configure Salesforce as the service provider, authenticated users can flow from a third-party identity provider into Salesforce.

Service Provider-Initiated SAML Flow

In a service-provider-initiated flow, the service provider begins the login process with a SAML request to the identity provider. Here’s how this flow works.

1. The user requests a secure session to access a protected resource in the service provider.
2. The service provider initiates login by sending a SAML request to the identity provider, asking it to authenticate the user.
3. The identity provider sends the user to a login page.
4. The user enters their identity provider login credentials and the identity provider authenticates the user.
5. The identity provider now knows who the user is, so it sends a cryptographically signed SAML response to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
6. The service provider validates the signature in the SAML response and identifies the user.
7. The user is now logged in to the service provider and can access the protected resource.

Check Okta Single Sign-On (SSO) with Salesforce post for Where OKTA is Idp and Salesforce as SP. Check about Salesforce and Azure SSO.

2. Salesforce as the Identity Provider(IDP)

We can use Salesforce as an identity provider for third-party service providers or relying parties by implementing SAML or OpenID Connect.

Identity Provider-Initiated SAML Flow

In an identity provider-initiated login flow, a SAML request is unnecessary because the identity provider starts the flow with a SAML response. An identity provider-initiated flow is a shortened version of a service provider-initiated flow. Here’s how this flow works:

1. The user logs in to the identity provider.
2. The user clicks a button or link to access the service provider.
3. The identity provider initiates login by sending a cryptographically signed SAML response to the service provider. The SAML response contains a SAML assertion that tells the service provider who the user is.
4. The service provider validates the signature in the SAML response and identifies the user.
5. The user is now logged in to the service provider.

Learn about how to implement Single Sign on Between Two Salesforce Org.

Salesforce Single Sign on Flows Decision guide

Please all session recording here before check below session. Check below recording to understand which flow we should use and when. For each flow we’ll cover:

• Sequence of steps
• Interesting characteristics
• Implementation considerations and trade-offs

Single Sign-on TERMINOLOGY

Lets check some terminology used in SSO.

SAML

• Security Assertion Markup Language (SAML) – Provides an open standard for XML-based confirmation of identity and transfer of identity attributes between an Identity Provider and Service Provider
• Identity Provider (IDP) – An application with the capability to authenticate a user’s identity (i.e. allow the user to login), and confirm authentication and identity attributes to a Service Provider
• Service Provider (SP) – An application which defers to an Identity Provider for authentication of a user, and allows this user access to protected resources or capabilities based on this authentication
• SAML Assertion – The portion of the SAML Response which confirms identity attributes of the authenticated user.
• SAML Request – The structured XML message sent by the Service Provider to an Identity Provider, identifying itself and requesting authentication of the user.
• SAML Response – The XML message sent by the Identity Provider to the Service Provider identifying itself as the issuer, indicating the status of the authentication attempt, and including the SAML Assertion if this can be issued (typically signed with the Identity Provider’s certificate).

OPENID CONNECT

• OpenID Connect (OIDC) – An identity extension to the OAuth 2.0 framework which specifies a JSON Web Token structure for confirmation of identity and communication of identity attributes
• OpenID Connect Provider (OP) – The application with the ability to authenticate a user and confirm identity attributes and authentication event information to a Relying Party. This application is playing the role of Authorisation Server in the terminology of OAuth 2.0
• Relying Party (RP) – The application deferring to the OpenID Connect Provider for an end user’s authentication and authorisation, and providing an authenticated service to the user once identity and authorisation is confirmed. This application is playing the role of Client in the terminology of OAuth 2.0
• ID Token – The JSON Web Token (JWT) structure used to communicate identity attributes from the OpenID Connect Provider to the Relying Party
• UserInfo Endpoint – Protected resource at the OpenID Connect Provider which will validate an access token and return authorised information about the user this token relates to

Further learning

This is not a summary of certification content but general best practice, and independent from official Salesforce recommendations.

• https://cloudsundial.com/salesforce-sso-flows