Single sign-on (SSO) is an authentication method that enables users to access multiple applications with one login and one set of credentials. For example, after users log in to your org, they can automatically access all apps from the App Launcher. You can use Salesforce as Identity provide (IDP) or as Service provider (SP).
In this session, we will talk about Salesforce As a service provider (SP). When a user attempts to access a service provider (SP) resource, the SP can redirect and request an identity provider (IDP) to authenticate and confirm identity.
NOTE: The system that authenticates users is called an identity provider. The system that trusts the identity provider for authentication is called the service provider
Service Provider Initiated SAML Flow Basic requirements
- Participating systems support SAML 2.0 protocols and up to date recommended security countermeasures
- SAML sign in URL, entity ID and certificate from IDP configured in SP
- SAML ACS URL and entity ID from SP configured in IDP
- If Salesforce is the SP, my domain must be enabled
Service Provider Initiated SAML Flow Video
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.
- The user requests a secure session to access a protected resource in the service provider.
- The service provider initiates login by sending a SAML request to the identity provider, asking it to authenticate the user.
- The identity provider sends the user to a login page.
- The user enters their identity provider login credentials and the identity provider authenticates the user.
- 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.
- The service provider validates the signature in the SAML response and identifies the user.
- The user is now logged in to the service provider and can access the protected resource.
What else to know
- Requests and assertions are XML
- Implementation generally browser-based
- SAML request bindings can be made on redirect / POST
- Assertion Subject contains username / federation ID
- Assertions are specific: Issuer, Audience, In ResponseTo, Issue Instant
- Replay detection (AssertionId)
- Optional extra security:
- Request signing and verification
- Assertion encryption
- CA-signed X509 certificates
- Session level
- Custom attributes
- Single logout
- Registration handler & JIT provisioning
Considerations for choosing SP-Initiated SSO
- Widespread and supported by many enterprise applications
- Established and proven secure (when implemented well)
- Standard implementation is browser-based:
- No back channel required
- Easy to debug
Think before
- XML tokens suboptimal for mobile
- Requires IDP to “know” the SP
- Adequate only for basic info transfer from IDP to SP
Soon we will share all step to perform in Salesforce for Service Provider flow.
