Patch behaviour when provisioning custom roles with Azure SCIM

Question

We have a non-gallery Enterprise Application, set up with SAML single sign-on and using Azure's automatic provisioning for users and roles.

To improve compliance with SCIM protocol, the aadOptscim062020 feature flag is used.

To manage user roles, custom App roles were created that reflect roles on the target system. These roles are assigned one-to-one to Groups within the SSO application.
This way, user roles are managed via their membership to these Groups. For example:

App role	Group
Role1 { display: Role1, value: role1 }	Group1
Role2 { display: Role2, value: role2 }	Group2

A custom field, named roles, is added to user attribute mapping; using the expression AppRoleAssignmentsComplex([appRoleAssignments]) to extract assigned roles, as described in this section: Provisioning a role to a SCIM app

When a user, member of both groups above, is created, Azure provisioning makes the expected request to add roles:

   ...  
   {  
       "op": "add",  
       "path": "roles",  
       "value": [  
           {  
               "primary": false,  
               "type": "WindowsAzureActiveDirectoryRole",  
               "display": "Role1",  
               "value": "role1"  
           },  
           {  
               "primary": false,  
               "type": "WindowsAzureActiveDirectoryRole",  
               "display": "Role2",  
               "value": "role2"  
           }  
       ]  
   }  
   ...  

When the provisioned user is requested from the target system, the response includes the roles field:

   ...  
   "roles": [  
       {  
           "primary": false,  
           "type": "WindowsAzureActiveDirectoryRole",  
           "display": "Role1",  
           "value": "role1"  
       },  
       {  
           "primary": false,  
           "type": "WindowsAzureActiveDirectoryRole",  
           "display": "Role2",  
           "value": "role2"  
       }  
   ]  
   ...  

If that user is then made a member of a third group Group3 (assigned Role3), a PATCH request comes from Azure to add the new role, Role3; but also the roles already assigned before (Role1, Role2). This isn't a huge issue for us, apart from performance.

The real issue is when the user is removed from one of the Groups, say Group1. The expected request in this case, according to SCIM, would be something like:

   ...  
   {  
       "op": "remove",  
       "path": "roles[value eq \"role1\"]"  
   }  
   ...  

But instead, Azure sends the following request:

   ...  
   {  
       "op": "add",  
       "path": "roles",  
       "value": [  
           {  
               "primary": false,  
               "type": "WindowsAzureActiveDirectoryRole",  
               "display": "Role2",  
               "value": "role2"  
           }  
       ]  
   }  
   ...  

which results in the user still having both roles, Role1 & Role2, in the target system.

Can you help in understanding if this issue is a known limitation of Azure's SCIM implementation, or for some reason the custom roles field is not recognized when returned from the target system?

Thanks in advance,
Domeniko

Answer 1

The Azure AD provisioning service doesn't rely on data from the response to a POST/PATCH at this time but would be reliant on the data returned on a future GET operation. Do the roles show correctly with a GET as well? If the roles are not returned during a future GET, our service will attempt to correct the state of the object at that time, which could be leading to the add operation(s). Beyond that, this sounds a bit complex and could be caused by some issues with our service or by problems with your SCIM implementation. I'd recommend creating a support case if the first thing I mentioned doesn't pan out.

Answer 2

We have rolled out and published a new method AssertiveAppRoleAssignmentsComplex here that will send a Replace instead of the Add function. This will ensure that roles that are removed on the source are also removed on the target.

Answer 3

Hi, Was this ever solved for you? Wondering if in the SCIM provisioning for groups, do you have DELETE selected as well as UPDATE?