Single Sign-On Setup

SAML / OpenID / Microsoft Entra ID

How to configure federated single sign-on for GoldFinch, with a dedicated walkthrough for Microsoft Entra ID.

  SAML 2.0       OpenID Connect       Microsoft Entra ID       MFA supported 

GoldFinch runs natively on the Salesforce Platform, so single sign-on is configured at the Salesforce layer using federated SSO standards — SAML 2.0 or OpenID Connect. This includes tested integration with Microsoft Entra ID (formerly Azure AD), the most common identity provider among GoldFinch customers. Salesforce can also enforce multi-factor authentication (MFA), either through Salesforce itself or through your identity provider's policies.

Supported protocols & identity providers

How SSO authentication flows

Figure 1 — SP-initiated SAML login flow between a user, Salesforce, and Microsoft Entra ID.

Setting up SSO with Microsoft Entra ID

This is the standard configuration pattern implementation teams follow. Screens and field names may shift slightly as Microsoft and Salesforce update their admin consoles.

1. Enable My Domain in Salesforce

SSO requires a Salesforce My Domain to be enabled first — it provides the unique login URL and ACS (Assertion Consumer Service) endpoint that Entra ID will send authentication responses to.

2. Create the Entra ID enterprise application

1. In Microsoft Entra ID, add a new Enterprise Application — search the gallery for “Salesforce,” or add a non-gallery SAML app if you need custom configuration.
2. Under Single sign-on, choose SAML.
3. Set the Identifier (Entity ID) and Reply URL (ACS URL) to the values from your Salesforce My Domain SSO settings.

3. Exchange metadata and certificates

1. Download the SAML signing certificate and metadata XML from Entra ID.
2. In Salesforce Setup, go to Single Sign-On Settings and create a new SAML SSO configuration.
3. Upload the Entra ID certificate and set the Identity Provider Login URL and Entity ID from the Entra ID metadata.

4. Map user identity

Decide whether Salesforce will match users by Federation ID or by username/email (NameID), and configure the same attribute in the Entra ID SAML claims. Federation ID is generally preferred since it decouples the SSO identity from a Salesforce username that might later change.

5. Map groups to permissions

Entra ID security groups can be used to control who is assigned the Salesforce enterprise app, but group-to-Salesforce-Permission-Set mapping is not automatic out of the box — it typically requires either a provisioning integration (e.g., SCIM-based user provisioning) or a documented manual process for assigning the right Profile/Permission Set when a user is provisioned. Coordinate this with your Salesforce admin during implementation.

6. Assign users and test

1. Assign the pilot users or group to the Entra ID enterprise application.
2. Test both IdP-initiated login (from the Entra ID My Apps launcher) and SP-initiated login (from the Salesforce My Domain URL).
3. Confirm a deprovisioned or disabled Entra ID user immediately loses Salesforce access.

Conditional Access & MFA

You can enforce MFA either in Salesforce or delegate it to your identity provider's Conditional Access policies (e.g., requiring MFA, a compliant device, or a trusted network before granting access). When you delegate MFA to Entra ID, Salesforce trusts the IdP assertion rather than separately challenging the user—avoid requiring MFA twice, as it creates a confusing login experience.

Certificate rotation

Entra ID SAML signing certificates typically expire on a fixed schedule (commonly every 3 years, configurable). Salesforce will reject assertions signed with an expired certificate, which locks out every SSO user at once if you don't renew it proactively. Set a calendar reminder well before the certificate expires, and update the certificate in Salesforce's Single Sign-On Settings before it lapses.

Pre-go-live checklist

• My Domain enabled and SSO configuration saved in Salesforce
• Entra ID enterprise application configured with correct Entity ID / ACS URL
• Certificate uploaded and NameID / Federation ID mapping confirmed
• Group-to-Permission-Set assignment process documented
• IdP-initiated and SP-initiated login both tested
• Deprovisioning tested — disabled user loses access immediately
• MFA/Conditional Access policy confirmed and not duplicated at the Salesforce layer
• Break-glass admin account exempted from the SSO requirement
• Certificate expiration date logged with a renewal reminder

See also

• Role-Based Access Control (Profiles & Permission Sets)
• Password Policies & Login Lockout Configuration
• Audit Trails & Field History Tracking Setup
• Solution Architecture Overview