Salesforce-Auth0 JIT User Provisioning Failure

0
votes

We're currently trying to set up JIT user provisioning with Salesforce Communities, using Auth0. The idea is pretty bog-standard SSO: users with accounts in our Auth0 tenant will be able to log in to Salesforce without having to manually create a new account.

Our SSO setup appears to be correctly configured, and we are able to create JIT community users. However, those users are unable to login after the initial account provisioning; subsequent login attempts yield an “INVALID_ACCOUNT_ID” (code 18) error. The users show up in our users table, have the correct emails and federation ids, and by all appearances are valid users. The SAML validator reports no errors, and the Login History log reports "Failed: SAML Provision Error“ for the subsequent login attempts. There is no meaningful (i.e. not timestamp, state, nonce related) difference I can discern between the initial, successful account-creating SAML submission, and the subsequent, failing SAML submission.

Any ideas what’s going on?

1
oauthsalesforcesingle-sign-onauth0

1 Answers

0
votes

From Salesforce Just-in-Time provisioning for Communities doc with only relevant language included below to follow the branch where your sign-in attempt is likely ending up:

Salesforce attempts to match the Federation ID in the subject of the SAML assertion

If a user with a matching user record isn't found, then Salesforce searches the contacts for a match based on the Contact ID (User.Contact) or email (Contact.Email). Contact.Email and Contact.LastName are both required properties when User.Contact is not specified, but matching is only based on Contact.Email when both properties exist.

If a matching contact record isn't found, then Salesforce searches the accounts for a match based on the Contact.Account or Account.AccountNumber specified in the SAML assertion. Account.AccountNumber and Account.Name are both required properties when Contact.Account is not specified, but matching is only based on Account.AccountNumber when both properties exist.

  • If a matching account record is found, Salesforce inserts a new user record and updates the account records based the attributes provided in the SAML assertion.
  • If a matching account record isn't found, Salesforce inserts new account, contact, and user records based on the attributes provided in the SAML assertion.​

When Salesforce processes the SAML assertion, Federation ID is likely not in the assertion subject or doesn't match what's in Salesforce. Therefore Salesforce thinks user doesn't exist. It then attempts to find a matching contact based on contact information in the assertion. Either it finds the contact in SF but SF contact's account parent doesn't agree with account specified in the assertion (likely root cause) or it doesn't find it and attempts to insert the contact with whatever account number is specified in the assertion and that account number doesn't exist in SF.

To fix - make sure the right user/contact/account information is present in Auth0 and it is sent in the SAML assertion with attribute names that Salesforce expects.

The out of the box matching algorithm in Salesforce JIT provisioning is usually insufficient for any scenario that deviates from a simple use case. Most implementations roll their own by implementing SAMLJitHandler.