Get groups of user during provisioning on Enterprise application in Azure AD

I am writing Azure AD provisioning support for our SAAS. I am using the SCIM standard to get user and group data from Azure AD.

However I am only getting groups that is actively added to the application (as it is set up to only sync users added to the enterprise application).

Example, we have three users

User One, part of groups IT and Rome
User Two, part of groups IT and Berlin
User Three, part of groups HR and Stockholm

I now add the following to my Enterprise application

Group IT, User Two, User Three

Now the data I will get sent to my application from Azure AD (via SCIM) is:

Create User One
Create User Two //Would have been created from adding group IT anyway
Create User Three
Create group IT
Add users One, Two to group IT

This is a very incomplete picture as I would like to have the missing groups (HR, Rome, Berlin, Stockholm) so that I can tag up the users in our SAAS so they can use these groups/tags to create rules.

Is there any way to get groups that a user on the application have, even if the group itself was not added to the application?

A good example is, I want to know users' cities as it's a good differentiator to create rules on. But I do not want to add a city-group to our application as I do not want all users for a city to have access. However I do want to know the city for the users that do have access!

Solution

Not possible. Groups in Azure AD are identified with their objectId value, and groups in SCIM are identified with their id value. The groups need to be managed by the AAD provisioning service in order to establish a link in the service where (based on AAD Provisioning configuration) it can be confirmed that group with AAD objectId of XYZ in Azure AD matches to the SCIM group with id of 123.

This is a requirement of the Azure AD Provisioning service, not specifically a limitation of the SCIM spec.

Best suggestion I can offer would be to store the data for what cities a user is associated with in a string attribute rather than handling this via group memberships.