How to properly setup Salesforce with OIDC based SSO for SCIM? (I'm new with AAD)

Question

Hello,

I have some issues while setting up SCIM for Salesforce that used OIDC-based SSO.

There is plenty of information and documentation on how to set it up for SAML-based SSO but can't find anything for OIDC.

As I understand Salesforce in the App Gallery is only for SAML. (Enterprise applications - New Application - Salesforce)

If I go to App registrations - New registration, I can create my custom app that is available for OIDC but it doesn't allow me to set up SCIM due to "Out of the box automatic provisioning to "My Test App" is not supported today. Ensure that "My TEST app" supports the SCIM standard for provisioning and request support for the application as described here. To determine if the application supports SCIM, please contact the application developer."

I also found these questions - https://learn.microsoft.com/en-us/answers/questions/274675/is-scim-provisioning-not-supported-for-oidc-based & https://learn.microsoft.com/en-us/answers/questions/725422/when-will-azure-ad-support-oidc-sso-non-gallery-ap but it lacks information on how to properly set it up. Can someone help?

Thanks!

Answer 1

Hi Arthur,

I will suggest you to raise a call with Microsoft and also provide a product feedback for this requirement, as I see many have raised similar queries for such setup and going via Microsoft channel will help you so a backend team is assigned for this issue/config.

https://learn.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new (click the feedback tab at the top)

https://feedback.azure.com/d365community

Hope this helps.

JS

==

Please Accept the answer if the information helped you. This will help us and others in the community as well.

Answer 2

Hey Arthur,

I have been working on this same issue for quite a while now, and the simple answer is that SCIM provisioning and OIDC SSO for Salesforce are functionally incompatible - but not for the obvious reasons.

You can setup both by creating a new SF enterprise app from the gallery, which will expose the option to do SCIM provisioning to Salesforce. This will also create a corresponding app registration that you can then use to setup OIDC SSO into Salesforce. Both will work individually, but not together, here is why:

SCIM provisioning requires you to choose an attribute/claim from Azure that will be used to match against accounts in Salesforce, and is most often either username/email (e.g. UPN ->SF Username) or OID (Object ID -> Federation ID). If you provision a user with say OID/Federation ID and setup SAML based SSO to use federation ID as the NameID claim it will work fine.

If you try to login via OIDC with this provisioned account it will fail, for the simple reason you cannot by default match using the OID, even though it is passed in the access and ID tokens. This is due to the restriction in the built in Salesforce Open ID and Microsoft auth providers where they only match on the SUB claim. The SUB claim is by standard an immutable value representing the user from the IDP and is used to create an object in the Salesforce user account for the purpose of linking the two (called the ThirdPartyAccountLink). The problem with this? Well the SUB claim that Microsoft uses is a pairwise value combo of the app ID and users OID, so it is an application specific user identifier. Guess what is not available as an attribute for mapping users in SCIM? You guessed it, SUB. So while you can provision a user with SCIM, SSO via OIDC will never find it and will want to create a new user.

Two potential workarounds, which I have started to explore:

1. Find a way to pass the OID from the auth providers into the registration handler and circumvent the default matching of SUB by doing an OID search first, and triggering an update rather than a create user event. This should apply the SUB to the matching user and SSO will work fine going forward.
2. Write a custom auth provider to parse the access/ID tokens and use the OID as the SUB claim that is passed to the reg handler.

I am not sure who could get Microsoft and Salesforce to put their heads together on this one, but is solvable on either side - Have Azure allow the SUB claim be changed to use the OID, or be able to provision using SUB; or get Salesforce to be more flexible on how mapping works in their auth provider/reg handlers.

For now I am using SCIM+SAML but I wish I could use OIDC.

Derek