CODEWITHSUNDEEP
azure-active-directorysingle-sign-onscim2
Brijesh Shah
Brijesh Shah

Reputation: 655

SCIM Customize Attribute mapping to support multitenant

We are trying to support Customer IDP Auto Provisioning service for our application. while researching on that we found that could be done through SCIM 2.0 supported protocol. We are currently relying on Azure Active Directory and OKTA and we were following most of the documentation available through Microsoft for Azure AD to use SCIM 2.0.

We have few question and like to clarify if anyone can help us.

Background: Our application is multi-tenant application and according to our understanding to support Customer IDP Auto Provisioning, we need to provide token which customer side they will use while they complete the handshaking and provisioning through the Azure Enterprise Application.

As our application is multi-tenant, we like to support multiple customer from the same portal and that's where we like to understand How do we architect this better. Again, I understand that is a big design question so instead of that, I am asking very specific questions which might help us to drive that decision/ design.

For the above scenario, we were thinking of the schema we are supporting from the customer enterprise application, we will be looking for the tenant id mainly appOwnerTenantId (described here in Microsoft Documentation)

So that all the users coming from the customer side will carry this additional property which we can read and use in our workflow.

I know that won't be sufficient enough from a security point of view but that could be a good start, we believe. we still require additional bells & whistles.

Can someone help answer these questions on this line:

Question #1: If we like to add this property to Custom Schema as Edit Attribute, How should I do that because that is not part of the dropdown it is coming and as per Azure documentation, it supports Azure AD attribution. enter image description here

Question #2: Any suggestion that you can provide to do this multi-tenant architecture for SCIM to support so that, we don't have to provide customer-based URL (for their token and user sync) and we can support multiple customers from the single endpoint?

Upvotes: 0

Views: 532

Answers (1)

Zollnerd
Zollnerd

Reputation: 912

As far as the attribute itself goes, the core and enterprise user schemas are defined in the SCIM spec. You shouldn't use that existing enterprise namespace for your custom attribute, and instead should define a custom namespace. The SCIM spec allows for any urn - i.e.: urn:foo:bar:attributeName, but Azure AD Provisioning right now requires a format like urn:ietf:params:scim:schemas:extension:AppName:2.0:User:attributeName.

That being said, this isn't a good approach and I would strongly recommend against it. If you're looking to identify what customer tenant a user should be provisioned/routed to, it shouldn't be defined by the customer's IT admins - or really anyone externally. The two options that are commonly used are:

A) Per-customer/tenant URL - i.e.: https://api.foo.bar//scim/v2 B) Include the relevant data in the token used for authorization - if you're issuing a JWT, for example, this would be the "iss" claim.

The way that you have proposed seems easily exploitable - a SCIM client (either via an IDP or just someone with curl, postman, etc) could provide any value they like.

Upvotes: 0

Related Questions