SamlSsoConfig Metadata Type for Single Sign-On (SSO)

Why the SamlSsoConfig Metadata Type Is the Cornerstone of Enterprise SSO#

While AuthProvider configures OpenID Connect (OIDC) and OAuth 2.0 social/enterprise login, SamlSsoConfig (samlssoconfigs/<Name>.samlssoconfig-meta.xml) configures SAML 2.0 Single Sign-On with enterprise Identity Providers (IdPs) such as Okta, Microsoft Entra ID (Azure AD), PingFederate, and ADFS.

Key Metadata Fields on SamlSsoConfig#

Real-World XML Example (samlssoconfigs/Entra_ID_Enterprise_SSO.samlssoconfig-meta.xml)#

<?xml version="1.0" encoding="UTF-8"?>
<SamlSsoConfig xmlns="http://soap.sforce.com/2006/04/metadata">
    <executionUserId>jit.admin@acme.example.com</executionUserId>
    <identityLocation>SubjectNameId</identityLocation>
    <identityMapping>FederationId</identityMapping>
    <issuer>https://sts.windows.net/00000000-0000-0000-0000-000000000000/</issuer>
    <loginUrl>https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2</loginUrl>
    <logoutUrl>https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0</logoutUrl>
    <name>Entra_ID_Enterprise_SSO</name>
    <redirectBinding>false</redirectBinding>
    <requestSignatureMethod>RSA-SHA256</requestSignatureMethod>
    <samlEntityId>https://acme.my.salesforce.com</samlEntityId>
    <samlJitHandlerId>EnterpriseSamlJitHandler</samlJitHandlerId>
    <samlVersion>SAML2_0</samlVersion>
    <singleLogoutBinding>RedirectBinding</singleLogoutBinding>
    <singleLogoutUrl>https://login.microsoftonline.com/00000000-0000-0000-0000-000000000000/saml2</singleLogoutUrl>
    <useConfigRequestMethod>true</useConfigRequestMethod>
    <useSameDigestAlgoForSigning>true</useSameDigestAlgoForSigning>
    <userProvisioning>true</userProvisioning>
    <validationCert>MIIDBTCCAe2gAwIBAgIQN33ROa6p...</validationCert>
</SamlSsoConfig>

Querying SamlSsoConfig via SOQL#

You can audit all SAML SSO configurations, signature algorithms, and JIT handlers in your org using standard SOQL:

SELECT Id, DeveloperName, MasterLabel, Issuer, SamlEntityId,
       IdentityMapping, IdentityLocation, RequestSignatureMethod,
       OptionsSpInitBinding, OptionsUserProvisioning,
       SamlJitHandler.Name, ExecutionUser.Username
FROM SamlSsoConfig
ORDER BY DeveloperName ASC

Senior Architect Best Practices#

Frequently asked questions

Why should enterprise orgs use FederationId instead of Username in SamlSsoConfig identityMapping?

In Salesforce Sandboxes, usernames are automatically appended with the sandbox name (such as user@acme.com.uat), whereas FederationIdentifier remains identical across Production and all Sandboxes. Using FederationId ensures SAML SSO works across refreshes without modifying IdP claims.

Why does deploying SamlSsoConfig fail when requestSigningCertId or executionUserId is included?

Both requestSigningCertId (an 18-character Certificate record ID) and executionUserId (the JIT handler running User) are environment-specific. Use sfdx-project.json string replacements to inject the target org values during CI/CD deployment.

What is required to enable Just-in-Time (JIT) user provisioning in SamlSsoConfig?

To enable JIT provisioning, set userProvisioning to true, set identityMapping to FederationId, specify an executionUserId with Manage Users permission, and optionally reference a custom Apex class implementing Auth.SamlJitHandler in samlJitHandlerId.

Can you query SamlSsoConfig settings using SOQL?

Yes. You can query the SamlSsoConfig standard object in SOQL to audit DeveloperName, Issuer, SamlEntityId, LoginUrl, IdentityMapping, IdentityLocation, RequestSignatureMethod, and ValidationCert.