1

I am implementing Salesforce as a service provider and I am expected to provide some general guidelines to the application which will be set as the identity provider.

There is documentation explaining this process of implementation. However, I was not able to understand the difference between the SAML Identity Type and the SAML Identity Location.

SAML Identity Type

  • The SAML assertion element that contains the string identifying a Salesforce user. Values include:
  1. Assertion contains User’s Salesforce username - Use this option if your identity provider passes the Salesforce username in SAML assertions.
  2. Assertion contains the Federation ID from the User object - Use this option if your identity provider passes a user identifier for customers or partners in the SAML assertion
  3. Assertion contains the User ID from the User object - Use this option if your identity provider passes a user identifier for users from your org in the SAML assertion.

SAML Identity Location

  • The SAML assertion element that specifies where to locate the user’s identity. Values include:
  1. Identity is in the NameIdentifier element of the Subject statement The Salesforce Username or FederationIdentifier is in the statement of the assertion.
  2. Identity is in an Attribute element - The Salesforce Username or FederationIdentifier is specified in an in the assertion’s .

Attribute Name

  • If you select Identity is in an Attribute element, this field contains the value of AttributeName that’s specified in , which is the User ID.

Could anyone explain the difference?

For example, I need to map the users based on their Email field on User object. Which configuration do I choose?

1 Answer 1

2

So, basically what is going on here is the following:

SAML Identity Location - identifies within the XML of the SAML assertion where the service provider will find the user's identity as provided by the IdP. The options are either in the NameIdentifier or Attribute. Your IdP metadata file will preset this for you.

SAML Identity Type - this tells the service provider (i.e. SFDC) that given where to find the user's identity in the XML (see above), how to match that value against data in the SFDC User record.

  • Is the user's identity to match the SFDC userName?
  • Is the user's identity to match the SFDC Federation Id?
  • Is the user's identity the same as the SFDC User.Id?

In your use case, I'd recommend that you choose Identity Type Federation Id and populate the SFDC User record Federation Ids with the user's email. This decouples the User.UserName from the SAML processing and enables easier configuration with SSO to PROD and SSO to sandboxes - the Federation Ids will be the same in both PROD and sandbox but the usernames are of course not.

2
  • Your IdP metadata file will preset this for you - only if the IdP is nice and kind, most aren't. Email as an identifier is not a good idea, emails change. As a last resort option and if there's no other identifier available - sure, but only then.
    – identigral
    Dec 26, 2022 at 16:47
  • 1
    @identigral - decent point and you have more experience of this than me - every SSO implementation I've done, the IdP uses the user's email as their "identifier" and hence the SFDC FedId was populated with the email. That said, in a corporate merger use case, email addresses will change
    – cropredy
    Dec 26, 2022 at 19:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .