One of the more tedious jobs as a Salesforce admin is resetting users’ passwords. Even though there’s a button on the Salesforce login screen that says “Forgot your password”, some people don’t notice it. If only there were an easier way!
Single Sign-On (SSO) is a simple idea: you will instantly be signed into all the other applications you require after signing into one system. You’ll have fewer passwords, fewer headaches, and less redundancy, which should free you up to focus on your original goals rather than getting mired down in administrative tasks like looking for your password hint.
The most significant SSO implementations appear to operate magically. It should be invisible to the user because it passes your login information from one system to another without requiring input from the user. It’s not necessary.
What is SSO?
Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials.
SSO eases the management of multiple usernames and passwords across accounts and services. SSO is an FIM (federated identity management) tool.
When you set up SSO, you configure one system to trust another to authenticate users, eliminating the need for users to log in to each system separately. The plan that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider.
You can configure your Salesforce org as an identity provider, a service provider, or both. You select the authentication protocol for these use cases. See Single Sign-On Use Cases. Salesforce also has preconfigured authentication providers that you can use to enable SSO with systems that have their own authentication protocols, like Facebook. Watch this video to see a SAML SSO implementation where Salesforce is the identity provider.
You can also set up a single identity provider to authenticate users for multiple service providers.
Need for SSO?
1. A single set of credentials reduces password fatigue.
2. More robust security (always recommended with MFA)
3. Users’ valuable time
How does SSO work?
1. SSO works by sharing and verifying login credentials between the identity provider and the service provider.
2. SSO does not store user information or identities. It works by checking and matching credentials stored in LDPS.
3. An auth token that identifies the user is verified and created for a user to sign in to an organisation. This authentication token uses SAML.
Salesforce as an Identity Provider
Configure single sign-on (SSO) so users can log in to an external service provider or rely on the party with their Salesforce credentials. You can enable your Salesforce org as a SAML identity provider and integrate a service provider as a SAML-connected app. You can also use OpenID Connect to integrate a relying party with your org.
Salesforce as a service provider
Configure single sign-on (SSO) so users can log in to your Salesforce org with their credentials from an identity provider or authentication provider. For this use case, you can define an identity provider with Security Assertion Markup Language (SAML). You can also use a predefined authentication provider, configure an OpenID Connect authentication provider, or create a custom authentication provider.
Salesforce as Service Provider and Identity Provider for SSO
Depending on your authentication needs, you can create an identity provider chain, configure SAML single sign-on (SSO) across multiple orgs or Experience Cloud sites, or use the predefined Salesforce authentication provider. Set up an identity provider chain if you want users to log in to Salesforce from a third-party identity provider and immediately have access to a client app. Suppose you want users to access several orgs or sites with one set of credentials, and set up SAML SSO between multiple orgs or sites. You can also set up SSO between two orgs with the Salesforce authentication provider, which authenticates users and authorizes access to protected data.
What is SAML?
SAML stands for Security Assertion Markup Language. It is an XML-based open standard for transferring identity data between an identity provider (IDP) and a service provider (SP).
SAML is a protocol that enables SSO between apps SAML uses XML to communicate between User, SP and IDPs
When you set up a single sign-on (SSO) with SAML, you can initiate login from the service provider or the identity provider. Service provider-initiated login and identity provider-initiated login use different flows, but both result in the user being logged in to the service provider.
Identity Provider-Initiated SAML Flow
An identity provider-initiated flow is a shortened version of a service provider-initiated flow. In an identity provider-initiated login flow, a SAML request is unnecessary because the identity provider starts the flow with a SAML response. Here’s how this flow works:
1.The user logs in to the identity provider.
2.The user clicks a button or links 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.
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.
Advantages of SSO
Without a doubt, the following are some concrete advantages of SSO:
1. Increased user adoption (really, people stop logging in if they find it too tough to remember password #87).
2. Reduced administrative costs (fewer support requests)
3. Time savings (5–20 seconds per user, per transaction, assuming they never make errors)
4. Better security (one policy; no need to align various sets), and as long as the lead system is updated, users will be immediately and automatically eliminated when they depart.
5. Savings on licences (see above point about automatic decommissioning of access to applications)
With SSO, you’ll have fewer passwords, fewer headaches, and less redundancy, which should free you up to focus on your original goals rather than getting mired down in administrative tasks like looking for your password hint.
Let us know your thoughts!
For more blogs: https://areya.tech/blogs/
To know more: connect with us today!
Contact: [email protected]
