Here, Service Provider (SP) is Salesforce and Identity Provider(IdP) assume as Active Directory.
“Single Sign On” Options:
- Delegated authentication is a single sign-on method that uses a Web service call sent from salesforce.com to an endpoint.
- Federated authentication, a single sign-on method that uses SAML assertions sent to a Salesforce endpoint.
Configuration Steps
- Configure the Identity Provider (IdP)
- Register new Application Service
- Generate Metadata – Download the IdP Metadata XML [SSO URL, Issuer ID, and X.509 Certificate, ACS URL=BLANK, Entity ID=BLANK][BLANK will be provided later after SP configuration]
- Map Attributes (federation id) – IdP should send this to the application in the authentication token.
- Integrate the Service Provider (SP)
- Enable SSO in the App
- Upload IdP Data (Metadata XML shared by IdP team)
- Obtain SP Metadata:
- Copy the ACS URL (Assertion Consumer Service) and Entity ID from the application and paste them back into your IdP configuration to complete the “trust” loop.
Note: ACS URL for SAML but Redirect URIs for OIDC
- User Provisioning for auto-sync between systems (e.g. employee retired)
- SCIM (System for Cross-domain Identity Management) – Use the SCIM 2.0 API to synchronize user accounts. When an identity is updated in IdP, a RESTful request (POST/PATCH/DELETE) is sent to the SP to keep account states in sync.
Integration Protocol:
- SAML 2.0 (Security Assertion Markup Language): An XML-based protocol primarily used for web-based enterprise applications.
- OpenID Connect: An identity layer built on top of OAuth 2.0, using JWT (JSON Web Tokens). It is preferred for modern mobile apps, SPAs, and microservices.
Orchestrate the Authentication Flow:
- SP-Initiated Flow: The user hits the application first; the SP sends an AuthnRequest to the IdP, which then redirects the user back with an Assertion.
- IdP-Initiated Flow: The user starts at your company portal (e.g., Okta or Entra dashboard) and is “pushed” into the application with a pre-signed token.
Validation and Security Hardening:
- Token Lifecycle: Define TTL (Time-to-Live) for tokens to prevent session hijacking.
- Single Logout (SLO): Integrate SLO to ensure that when a user terminates their session at the IdP, a LogoutRequest is broadcast to all active SPs.
- Clock Skew: Ensure NTP synchronization between the IdP and SP, as many integrations fail if timestamps differ by even a few minutes.
Enable Multi-Factor Authentication (MFA) Conflict
The conflict may occur when both platforms simultaneously try to enforce their own MFA rules, resulting in a redundant, frustrating “double MFA” user experience, or an SP-initiated login block if Salesforce does not receive proof that MFA occurred at the IdP level.
The standard industry best practice is to delegate MFA completely to the Identity Provider (Azure AD) and configure Salesforce to trust and accept Azure AD’s MFA verification.
Conflict Resolution:
- Configure Azure AD to Pass the MFA Claim within SAML.
- If to make user as SSO enabled, profile or permission set is used then go to that profile or permission set and edit. Under System Permissions, check the box for “Waive Multi-Factor Authentication for Exempt Users”.
- Else, go to Setup > Session Settings. Ensure that High Assurance is properly mapped. Move “Multi-Factor Authentication” to the High Assurance column and ensure your SAML SSO provider is also mapped to the High Assurance This tells Salesforce that an SSO login inherently satisfies the MFA requirement.
- Disable “Multi-Factor Authentication for User Interface Logins” option from Profile or Permission Set (under System Permission).
- Note: Setup>>Identity Verification>>Option = “Require multi-factor authentication (MFA) for all direct UI logins to your Salesforce org”. (No need to change)