EntraID is sending incompliant SCIM PATCH request when trying to modify attributes

Question

Hi

I am currently trying to provision users and groups from EntraID to an on-prem directory supporting SCIM interface. I’m using the Enterprise App SCIM provisioning to do that.We are testing different scenarios and one of the scenarios is trying to modify two attributes.

This works fine with two standard user-core-schema attributes of type "string” (not complex) : EntraID is sending the right PATCH-request with the right replace-operation-format.But when we try to modify two complex attributes or two custom attributes (from our custom-schema), our SCIM interface reject the operations. It looks like the PATH request sent from Entra ID is not compliant with the SCIM standard. The POST requests works as it should

This is an example to change two attributes from the complex core attribute “name”.This is what Entra ID is sending (and is rejected by our SCIM product):

// PATCH

{"schemas": [
"urn:ietf:params:scim:api:messages:2.0:PatchOp"    
],    
"Operations": [ 
       {            
             "op": "replace",            
                    "value": {
                        "name.formatted" : "test test2",                
						"name.familyName" : "test"            
								}        
		}    
		]
		}

This is what it should be I believe according to SCIM standard (working with our SCIM product).

// PATCH   
{    "schemas": [
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"    
		],    
	"Operations": [
        {            
			"op": "replace",
            "value": {                 
				"name”: {                  
					“formatted" : "test test2",                  
					"familyName" : "test"            
}        
}    
]}

Alternatively, the “name” should be defined in “path”.

Below another example using two custom attributes from our custom-schema “urn:ietf:params:scim:schemas:extension:myown:2.0:User” This is what Entra ID is sending (and is rejected by our SCIM product). // PATCH

{"schemas": [        
	"urn:ietf:params:scim:api:messages:2.0:PatchOp"    
		],    
		"Operations": [        
			{            
			"op": "replace",            
			"value": {                                			 
   				"urn:ietf:params:scim:schemas:extension:myown:2.0:User.arbeidssted": "test2", 
     			"urn:ietf:params:scim:schemas:extension:myown:2.0:User.section": "test3  
                         		 }            
				}    
]}

This is what it should be I believe according to SCIM standard (working with our SCIM product).

// PATCH

{    "schemas": [        
	"urn:ietf:params:scim:api:messages:2.0:PatchOp"    
	],    
	"Operations": [       
	 {            
		"op": "replace",            
		"value": {                
			"urn:ietf:params:scim:schemas:extension:myown:2.0:User": {                    
				"arbeidssted": "Svinesund",                    
				"section": "Seksjon Svinesund 6"                
		}                        
	}    
]}

The POST request works as it should

{    "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User",      "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User",        "urn:ietf:params:scim:schemas:extension:myown:2.0:User"    
	],    
	"meta": {        
		"resourceType": "User"    
	},    
			"active": true,    
			"displayName": "Harry Test",    
			"externalId": "5315ce50-9b26-4f27-322a-4898137b454a",    
			"userName": "HATT ",    
			"name": {        
				"familyName": "Smart",        
				"formatted": "Smart, Harry",        
				"givenName": "Harry"    },    
			"urn:ietf:params:scim:schemas:extension:myown:2.0:User": {        
				"mail": harry.holly@test.local,       
			    "title": "Undsersjef"    
}}

Kind regards Henrik Sommerschild

Answer 1

Hello @HEIBERG SOMMERSCHILD Henrik and thanks for your question. Entra ID SCIM implementation conforms to the following specifications:

• RFC 7644 section 3.10 (Attribute Notation) which states that Complex attributes' sub-attributes are referenced via nested dot ('.') notation, i.e., {urn}:{Attribute name}.{Sub-Attribute name}. For example, the fully qualified path for a User's givenName is "urn:ietf:params:scim:schemas:core:2.0:User:name.givenName".
• RFC 7644 section 3.5.3.2 (Replace Operation)which states that If the target location specifies a complex attribute, a set of sub-attributes SHALL be specified in the "value" parameter, which replaces any existing values or adds where an attribute did not previously exist. Sub-attributes that are not specified in the "value" parameter are left unchanged.

Based on the aforementioned I would recommend to ensure your on-premise SCIM implementation follows them too.

Let us know if you need additional assistance. If the answer was helpful, please accept it and rate it so that others facing a similar issue can easily find a solution.