Single Sign On (SSO) flows enable users to authenticate using their identity from an external system. There are three mechanisms which can be used to achieve this in Salesforce:
- SAML, where signed structured messages known as SAML requests and assertions are passed between the identity provider and service provider via the browser.
- OpenID Connect, which leverages OAuth web server or user agent flows to establish trust.
- Delegated Authentication, a mechanism based on capturing and submitting credentials for authentication via a SOAP message. Can be useful for authenticating to systems which don't offer other protocols.
Flows in this section summarise the sequence of messages in SSO approaches currently supported by Salesforce.
SERVICE PROVIDER (SP) INITIATED SSO
If Salesforce acts as the Service Provider:
- Salesforce "Single-Sign On Settings" should be configured with values from the IDP
- Certificate from the IDP should be uploaded as the identity provider certificate in Salesforce. This is used for signature validation on incoming SAML responses
- Requests will be signed by Salesforce with the selected certificate, which can be validated by the IDP if necessary
- IDP-encrypted assertions are also supported, and decryption certificate uploaded and selected as Assertion Decryption Certificate
- SAML request bindings can be configured to be bound to HTTP Redirect or HTTP POST (determines whether initial SAML authentication request is GET or POST)
- Just In Time (JIT) user provisioning can be configured to enable automatic creation/update of users based on contents of incoming SAML assertions. Salesforce will attempt to match a user and will either update this record or create a new user in real time. Standard provisioning allows assertion attributes corresponding to standard field names to be used for matching and values for field contents, or custom logic can be defined in a class implementing the
Auth.SamlJitHandlerinterface - The IDP will need to be set up with the Authorisation Consumer Service (ACS) URL ("Salesforce Login URL") and Entity ID
- MyDomain required for SP-Initiated SSO, which enables deep linking (landing on requested URL) and OAuth with SAML
For Salesforce to act as the Identity Provider:
- Salesforce identity provider setup must be enabled, and a connected app set up for each service provider specifying the Authorisation Consumer Service (ACS) URL and service provider's Entity ID, as well as general SAML configuration, which can differ by service provider
- User profiles or permission sets must be added to connected app for accounts to be used for SSO identity
- Optionally, SAML request signatures for a service provider can be validated by uploading the SP's signing certificate
- SAML responses can be encrypted for additional security
- The connected app's Start URL is used as Relay State if the app's icon is clicked in the Salesforce app launcher
IDENTITY PROVIDER (IDP) INITIATED SSO
- This flow is inherently less secure than the SP-initiated version, and is highly susceptible to Man-in-the-Middle and CSRF attacks (see links below). Careful consideration should be made before choosing to use IDP-Initiated SSO
- When Salesforce is acting as an IDP, clicking an SP's connected app icon in the App Launcher doesn't actually use this flow, but instead an SP-initiated version with Relay_State = Start URL is initiated
- IDP-Initiated SSO can be used as part of canvas app authentication by selecting "Identity Provider Initiated" as the canvas app's initiation method option. Unlike the "Service Provider Initiated" option, this has the advantage that the SAML response can be passed and the user authenticated without the need for the canvas app / service provider to first serve an un-authenticated login page, which may not permit embedding in an iframe (this applies to Salesforce's own standard login page, so this consideration is relevant to Salesforce -> Salesforce canvas apps)
- If Salesforce acts as the Service Provider, general setup considerations and capabilities described in the Service Provider Initiated SSO flow apply except the requirement for My Domain, which isn't necessary here
Documentation
OPENID CONNECT (OIDC)
- OpenID Connect is the accepted standard and most popular mechanism for identity verification using the OAuth 2.0 framework. Salesforce allows OpenID Connect providers to be set up as authentication providers for Social Sign On with simple configuration
- Many identity services offer an identity verification mechanism based on OAuth 2.0 and similar to but not completely consistent with OpenID Connect. It's possible to set up custom authentication providers for services like these by extending the
Auth.AuthProviderPluginClassclass with custom logic to initiate authentication and retrieve user information (details in Salesforce documentation) - OpenID Connect is offered by services such as Google and Microsoft, and is likely used in the pre-configured authentication providers available for these services
- Some popular OAuth-based identity services which don't comply entirely with the OpenID Connect spec are also pre-configured in Salesforce. Examples include:
- Facebook (which offers Facebook Login)
- Twitter (Login with Twitter)
- LinkedIn (Member Authorization API and Profile API for user attributes)
- GitHub (Allows retrieving a user's profile info after securing an access token)
- A Salesforce org can also act as the OpenID Connect Provider for other applications. In this instance, either the web server version (as shown) or another OAuth flow could be used for the authentication/authorisation
- In addition to Social Sign On, authentication providers in Salesforce can be used to authenticate content providers for Salesforce Files Connect (e.g. Google or Office 365)
- Client id and secret are managed by Salesforce for standard authentication providers (Facebook, Google etc), though these can be overridden in the org if required
General details around characteristics of OpenID Connect:
- Nonce if provided is included as an attribute in the ID token - this binds the token to a specific authorisation request and help protect against replay attacks possible through CSRF
- The UserInfo endpoint can be used to provide ID claims not included in the scope of the ID token, for example picture, email, website, locale, phone number etc
- The OpenID Connect Core spec includes details on implementation of this flow
DELEGATED AUTHENTICATION FROM SALESFORCE LOGIN
- Provides a method of using credentials for applications which don't offer SAML to login to Salesforce
- My domain is not required
- Delegated authentication SOAP endpoint must comply to specific WSDL (which can be downloaded from Salesforce)
- Password is not validated in SF and instead passed to authentication service for validation, so Salesforce password policy doesn't apply
- This flow requires delegated authentication endpoint to support processing passwords
- Delegated authentication can be enabled / disabled by an admin from Single Sign On Settings
- Permission "Is Single Sign-On Enabled" controls by user whether passwords are submitted to delegated authentication service
SAML migration trick: It can be useful to block certain users from logging in with username and password. By enabling delegated authentication and using the "Is Single Sign-On Enabled" permission, these users will be prevented from using their Salesforce password to login
DELEGATED AUTHENTICATION (HTTP)
- Enables authentication to Salesforce without prompting for credentials
- Application must manage or be able to acquire the token, assertion or password
- A token or assertion is preferable to avoid sending corporate passwords to or from Salesforce
- If a token or assertion is used, this should be set as the password in the POST to the Salesforce login page
No comments:
Post a Comment