yhlsn (yhlsn) asked a question.
Hello the Okta team,
In Okta I have an application where SCIM is activated. This application has the default mappings profile and I have only activated the “To App” synchronisation.
In the official documentation here : https://developer.okta.com/docs/reference/scim/scim-20/*update-a-specific-user-put we can see :
“After the User object is retrieved from the SCIM server, Okta modifies the attributes that were changed and runs a PUT method request with the new body to the /Users/${userID} endpoint”
Then If I have in MySys :
- userName: foo@foo.com
- attribut_1: A’
- attribut_2: B
and I create in Okta :
- userName: foo@foo.com
- attribut_1: A
And synchronise it, there is in a first step a GET following in a second step by a PUT sending from Okta to MySys:
- userName: foo@foo.com
- attribut_1: A
- attribut_2: B
So there is a something like a merge as despite the fact that attribut_2 is not set on the Okta side, attribut_2 is sent from Okta to MySYS. Doing this allow to not erase the actual MySys value by a null value. I think that this behaviour is what is documented by: “Okta modifies the attributes that were changed and runs a PUT method request with the new body”.
Now here is my question why this behaviour does not work for the fields of urn:ietf:params:scim:schemas:extension:enterprise:2.0:User like managerId ou department ? Indeed if the GET return :
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"department”:”MySYS departement"}
Okta does not send this attribut in his PUT
Yet, the mapping seems to work as if I define the department on the Okta side Okta is able to send it :
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User" : {
"department" : "okta department"
}
I see the same thing for the managerId field so could you confirm that there is a difference in behaviour between the fields of urn:ietf:params:scim:schemas:core:2.0:User and urn:ietf:params:scim:schemas:extension:enterprise:2.0:User ?
Hello,
Okta should do a merge for values that are not mapped on the Okta side (application profile). For example,
...
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
],
"testkey2": "testValue2",
"urn:ietf:params:scim:schemas:extension:enterprise:2.0:User": {
"testkey1": "testValue1"
},
...
In this case both testkey 1 and 2 are not defined attributes of the respective schemas they are set in, nor do I have either attribute created/mapped in my Okta application profile. So after Okta does a GET from the SCIM server that returns this, on the follow up PUT Okta from both of these attributes will be present. Okta just merges them with the record Okta has for the user.
In the case of 'department', this is an enterprise user attribute in the Okta application user profile. So when a GET is done and this is returned, Okta will update this attribute with what is stored for the user. If this value is blank or nil, then Okta will not send a value for it. The assumption is Okta is the source of truth in this scenario.
If you will not have these values stored in Okta, one potential workaround would be to removed the 'department' attribute mappings in the Okta application profile and then delete the attribute from the application profile. This way Okta will send back this value the same way as it does with non existent attributes in the Okta application profile.
If you are not seeing the same behavior I am, I suggest opening a case with Okta Support so further analysis of your application can be done.