The company I work for has a Web App that is published in the Azure AD Gallery, now we want to add SCIM provisioning to it. The problem I'm trying to solve is that in some scenarios a company may need access to two different instances of our Web App, using the same user. So in order to distinguish what instance they are provisioning to, I would need to receive a value that tells me the instance. The idea I'm currently exploring is to register two apps inside the same tenant, and retrieve some unique value depending on which App is sending the provisioning requests. If I was able to receive the Object Id or the Application Id that would be perfect but right now I only get the Tenant Id, which is the same for both apps. I followed the accepted answer from here https://learn.microsoft.com/en-us/answers/questions/135345/azure-ad-custom-claims-in-access-tokens.html to try to add some specific claim but I always get the same original claims. Should this plan of registering two apps and sending different claims ids work? I'm not sure if I'm doing something wrong or if there is some other easier way to accomplish my goal. Much appreciated any help.

Claims are a concept in tokens used in auth flows - SAML, OIDC, etc - not in SCIM, which is a standard for provisioning rather than authentication or authorization. Our service only allows you to map a flow for attribute values from the source Azure AD object itself - such as a user or group - and not about other objects in the directory, such as the directory itself (i.e.: a directory ID, or the application ID/service principal ID of the application being used for provisioning). The inclusion of the Azure AD tenant ID in a header of the request is not required by the SCIM standard and I believe is not documented either - meaning it could be subject to change in the future, and should not have production dependencies built on it. In order to distinguish what instance of the app is being provisioned to, you should build your web app to allow this to be determined either by a value in the SCIM URL (i.e.: https://example.xyz/UniqueValue/scim/v2/ ) or a value in the bearer token generated by your web app for usage by the SCIM provisioning config in Azure AD.

SCIM Custom Claims - Microsoft Q&A

Accepted answer

Danny Zollner 9,526 Reputation points Microsoft Employee

2022-04-29T17:42:06.24+00:00

Claims are a concept in tokens used in auth flows - SAML, OIDC, etc - not in SCIM, which is a standard for provisioning rather than authentication or authorization.

Our service only allows you to map a flow for attribute values from the source Azure AD object itself - such as a user or group - and not about other objects in the directory, such as the directory itself (i.e.: a directory ID, or the application ID/service principal ID of the application being used for provisioning). The inclusion of the Azure AD tenant ID in a header of the request is not required by the SCIM standard and I believe is not documented either - meaning it could be subject to change in the future, and should not have production dependencies built on it.

In order to distinguish what instance of the app is being provisioned to, you should build your web app to allow this to be determined either by a value in the SCIM URL (i.e.: https://example.xyz/UniqueValue/scim/v2/) or a value in the bearer token generated by your web app for usage by the SCIM provisioning config in Azure AD.
Please sign in to rate this answer.

1 person found this answer helpful.
Juan 66 Reputation points

2022-04-29T20:09:16.283+00:00

Thanks for your answer @Anonymous .

Both of your proposals sound promising. Since our SCIM will integrate to our Azure AD Gallery App and therefore we will use Azure AD Multitenant authentication, I'm wondering which one of the solutions will fit better.

1) I've never been involve in the integration of SCIM - Azure AD Gallery so I'm not aware of its limitations, Should I be able to ask to our customers to point to a specific URL? I mean a different URL for each customer vs the same one for all of them?

2) About the bearer token. I know that I can generate a token and give it to the customer

But I was hopping to be able to implement a solution were the token doesn't need to be sent and copied. In point 8 from here

I understood that I could rely on the token generated by Azure. I just need to leave the Secret Token field empty, the problem is that generated token contains a list of claims that I haven't been able to modify

since I'm the admin tenant I thought I should be able to add some claim. Is that possible? that could help: same URL for all customers, no need to sent tokens to customers and only those who need multiple apps will need to do some extra steps

Danny Zollner 9,526 Reputation points Microsoft Employee

2022-04-29T20:21:10.607+00:00

For #1, assuming you design your SCIM server to generate a different URL for each customer, then they should be able to provide that URL in the provisioning configuration on the app.

For #2, if you're using a custom non-gallery app for SCIM rather than an Enterprise Application listed in the gallery's list of available SaaS apps, a long-lived bearer token is your only option. If your app is a gallery application that already has a listing for at least SSO in the gallery, you can submit a new request to add provisioning to the existing app. If that's the case, you can also implement OAuth 2.0 Authorization Code Grant which will allow for us to place an "Authorize" button that redirects to your service for login + OAuth consent grant and then redirects back to Azure AD with the token(s). In that case, there's no copy/paste needed and the provisioning service will continually roll the access/refresh tokens to keep them from expiring.

For the app submission topic, follow the instructions here: https://learn.microsoft.com/en-us/azure/active-directory/manage-apps/v2-howto-app-gallery-listing - there's a link to a submission portal under the Submit Your Application section

Juan 66 Reputation points

2022-05-02T16:06:31.407+00:00

Thanks for the feedback.

Our App is already in the Azure AD Gallery and already implements SSO + Consent Grant.

The part I don't understand is how the Provisioning SICM will interact with our Web App (Azure Gallery). when you said:

"you can also implement OAuth 2.0 Authorization Code Grant which will allow for us to place an "Authorize" button that redirects to your service for login + OAuth consent grant and then redirects back to Azure AD with the token(s). In that case, there's no copy/paste needed and the provisioning service will continually roll the access/refresh tokens to keep them from expiring."

is that means that both apps will be sharing the same tokens? and that we can add extra claims on the Azure AD Gallery App and those claims will also be sent to the SCIM API ? (right now our Web App and our SCIM API are two separated apps, is that ok?)

About the solution "one URL per client", is that applicable for Azure AD Gallery Apps? I mean when a customer installs an Azure AD Gallery app which has SSO + Code Grant + SCIM , Do they configure the SCIM URL manually? Can we provide individual URLs for each customer? or is this approach only valid for non-gallery apps?

Thanks for your help

Danny Zollner 9,526 Reputation points Microsoft Employee

2022-05-02T16:15:37.177+00:00

is that means that both apps will be sharing the same tokens? and that we can add extra claims on the Azure AD Gallery App and those claims will also be sent to the SCIM API ?

I would think no - there would be two separate OAuth 2.0 Authorization Code Grant requests that happen, one per app, and two separate sets of access/refresh tokens would be issued. You can go take a look at our provisioning tutorials for Dropbox and Workplace from Facebook/Meta, as both of those use OAuth 2.0 Authorization Code Grant.

About the solution "one URL per client", is that applicable for Azure AD Gallery Apps? I mean when a customer installs an Azure AD Gallery app which has SSO + Code Grant + SCIM , Do they configure the SCIM URL manually?

Customers can configure the SCIM URL manually.

Juan 66 Reputation points

2022-05-02T22:12:20.587+00:00

1) Related to the URL solution:

Thanks for the suggested tutorials, Worplace-Facebook has a step where they configure the URL but on their video they don't, and Dropbox also doesn't mention anything about configuring an URL. Is this URL setting optional? depending on the App?

No visible URL field

Configuration with URL

2) About the claims solution I'm getting a bit lost, please allow me to rollback to your initial comment.

[...]a value in the bearer token generated by your web app for usage by the SCIM provisioning config in Azure AD.

What did you meant with that? Did I understood you correctly when I assumed that I could add some extra claim to the tokens the SCIM will be returning?

Thanks for your help

Danny Zollner 9,526 Reputation points Microsoft Employee

2022-05-03T16:37:18.98+00:00

Whether the URL is configurable is a per-app thing. I pointed you towards those two apps for the OAuth 2.0 Authorization Code Grant flow piece, not the customizable URL piece.

For the token thing (#2), this would be for any tokens that your service issues. Your service needs to issue either long-lived bearer tokens (probably JWT) or OAuth access/refresh tokens. In either case, you can embed information about the customer's environment in your service inside of the token. I'm not an expert on this area so I can't give you a whole lot more than that, unfortunately. This isn't necessary, btw, it's just another option instead of embedding that environment-specific identifier in the SCIM URL.

Juan 66 Reputation points

2022-05-06T21:19:01.46+00:00

Thanks for your patience and for setting me in the right direction.

I will experiment with those ideas.
Sign in to comment

SCIM Custom Claims

0 additional answers