SCIM PUT - unassigning attribute

By: Thomas W. user 28 May 2019 at 6:38 a.m. CDT

6 Responses
Thomas W. gravatar
Hi. I am wondering if there is an intended way of unassigning single-valued attributes on a user when performing a PUT request with SCIM. A multi-valued attribute can be unassigned through supplying an empty array, but the same does not seem to hold true for single-valued attributes. If I supply an empty string (`""`), I get a response where the attribute is described as being an empty string. If I supply `null`, the response shows the existing attribute unchanged. In both cases, the attribute remains unchanged in the LDAP backend. See the examples below. # Examples For the examples, assume a user that looks like this ``` { "schemas": [ "urn:ietf:params:scim:schemas:extension:gluu:2.0:User", "urn:ietf:params:scim:schemas:core:2.0:User" ], "id": "<user_inum>", "meta": { "resourceType": "User", "created": "2018-12-11T10:51:34.391Z", "lastModified": "2018-12-11T10:51:34.391Z", "location": "https://example.com/identity/restv1/scim/v2/Users/<user_inum>" }, "userName": "TestUser", "displayName": "TestUser", "active": true } ``` ## Example 1 - Empty string I perform the request ``` PUT /identity/restv1/scim/v2/Users/<user_inum> Content-Type: application/json Authorization: Bearer <some_token> { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:gluu:2.0:User" ], "displayName": "" } ``` Which returns a `200 OK` response with the following ``` { "schemas": [ "urn:ietf:params:scim:schemas:extension:gluu:2.0:User", "urn:ietf:params:scim:schemas:core:2.0:User" ], "id": "<user_inum>", "meta": { "resourceType": "User", "created": "2018-12-11T10:51:34.391Z", "lastModified": "2018-12-11T10:51:34.391Z", "location": "https://example.com/identity/restv1/scim/v2/Users/<user_inum>" }, "userName": "TestUser", "displayName": "", "active": true } ``` Which shows `displayName` as being an empty string. But, in LDAP, the attribute is still set to `TestUser`. ## Example 2 - null Similar to the above, I send a request ``` PUT /identity/restv1/scim/v2/Users/<user_inum> Content-Type: application/json Authorization: Bearer <some_token> { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User", "urn:ietf:params:scim:schemas:extension:gluu:2.0:User" ], "displayName": null } ``` Which returns a `200 OK` response with the following ``` { "schemas": [ "urn:ietf:params:scim:schemas:extension:gluu:2.0:User", "urn:ietf:params:scim:schemas:core:2.0:User" ], "id": "<user_inum>", "meta": { "resourceType": "User", "created": "2018-12-11T10:51:34.391Z", "lastModified": "2018-12-11T10:51:34.391Z", "location": "https://example.com/identity/restv1/scim/v2/Users/<user_inum>" }, "userName": "TestUser", "displayName": "TestUser", "active": true } ``` Which shows `displayName` as being unchanged. In LDAP, the attribute is also still set to `TestUser`. [RFC 7643, section 2.5](https://tools.ietf.org/html/rfc7643#section-2.5) seems to indicate to me that a value of `null` should be treated as unassigning the attribute. More specifically, the line I'm referring to is > Assigning an attribute with the value "null" or an empty array (in the case of multi-valued attributes) has the effect of making the attribute "unassigned". Since `PUT` in Gluu is somewhat non-standard, is this intended functionality, or a bug?
Ubuntu 18.04
closed

Answers

By Jose Gonzalez staff 28 May 2019 at 4:20 p.m. CDT

Copy
Jose Gonzalez gravatar
Hi, it's intended. Ignoring `null` values makes PUTs safer. Depending on your application language and/or serialization libraries, the absence of an attribute (like `displayName`) in a json message for instance, might produce the following payload sent to the server: ``` { ... displayName: null, ... } ``` which would lead to a silent removal of `displayName` where it was probably not the original intention. That's why we are ignoring `null`. To be able to remove an attribute from a resource [PATCH](https://gluu.org/docs/ce/3.1.4/user-management/scim2/#updating-a-user-patch) is the way to go. By version 3.1.4 we detected this [bug](https://github.com/GluuFederation/oxTrust/issues/1376) and thus I am not sure if removal would be defective in your case. If it does not clear your attribute, you'll have to update to 3.1.5 or newer.

By Thomas W. user 29 May 2019 at 2:51 a.m. CDT

Copy
Thomas W. gravatar
Hi Jose. Thanks for the clarification, that answers my question then. Using `PATCH` is definitely on the table, but just requires more work (might need to implement a JavaScript/Python library for frontend myself, doesn't seem to be a whole lot available). I believe I have already patched in the fix for the bug that you point out (I think it was actually you who helped me with that in an earlier issue regarding SCIM PATCH), but thanks. If you take suggestions, I'd like to suggest a setting to disable ignoring `null` in `PUT` requests for SCIM. That way, if an implementation only adds `null` values deliberately to a request, it would be possible to unassign attributes through `PUT`, making for less deviation from the standard. This would, of course, need to be a setting to avoid breaking any existing implementations that rely on the current functionality. I'm with you on the `PUT` implementation being less destructive than what is usual, but being able to remove attributes with it would be nice.

By Jose Gonzalez staff 29 May 2019 at 7:04 a.m. CDT

Copy
Jose Gonzalez gravatar
We'll consider your suggestion for version 4.1. Unfortunately we can't tackle this for 4.0 release due to current workload.

By Mohib Zico staff 30 May 2019 at 1:41 p.m. CDT

Copy
Mohib Zico gravatar
@Jose.Gonzalez: may be we can put a github issue for 4.1? We won't forget it then... ..

By Jose Gonzalez staff 31 May 2019 at 6:47 a.m. CDT

Copy
Jose Gonzalez gravatar
Added [#1668](https://github.com/GluuFederation/oxTrust/issues/1668)

By William Lowe user 03 Jun 2019 at 10:07 a.m. CDT

Copy
William Lowe gravatar
Seems like this can now be closed. We can now track progress on the GitHub issue. Thanks for you suggestion, Thomas.

Post an answer