Re: [scim] Feedback and support for draft-hunt-scim-mv-filtering-00.html

["Matt Peterson (mpeterso)" <[e-mail]>]

Hi Nancy,

I have read the draft.  We have no plans to implement the draft-hunt-scim-mv-filtering-00.    Except for group memberships (which have many values) it is far easier to filter simple multi-valued attributes (like email) on the SCIM client-side.

The only attributes in the base SCIM schema that are likely to have so many values that server-side filtering is useful are: Group.members (members of a group) and User.groups (groups a user is a member of).

We handle the most common group memberships use cases without needing multi-valued pagination - using existing SCIM filtering and SCIM *object* pagination.   The following is a list of use cases for group memberships.  I have provided the SCIMv2 request that we use to satisfy each use case (without the need for multi-valued attribute pagination or any changes to the SCIM v2 spec).  For additional clarity, I have also included the equivalent Microsoft Graph query for each use case to show how the SCIMv2 request would translate to another familiar API:

Use Case #1:  I have the group id "ffffffff-1111-49f5-b200-2c8aa95f3a49", I want to get all the members of the group (even if there are many paged results):

Solution: Use the SCIMv2  /user resource:
GET https://scimserver.mydomain.com/user?filter=groups.value+eq+ffffffff-1111-49f5-b200-2c8aa95f3a49

Corresponding Microsoft Graph API:
GET https://graph.microsoft.com/v1.0/groups/ffffffff-1111-49f5-b200-2c8aa95f3a49/members

Use Case #2:  I have the user id "aaaaaaaa-1111-4306-8e52-bb1921f1a7ed" and I want to get all the groups that the user is a member of (even if there are many paged results):

Solution: Use the SCIMv2  /group resource:
GET https://scimserver.mydomain.com/group?filter=members.value+eq+aaaaaaaa-1111-4306-8e52-bb1921f1a7ed

Corresponding Microsoft Graph API:
GET https://graph.microsoft.com/v1.0/users/aaaaaaaa-1111-4306-8e52-bb1921f1a7ed/transitiveMemberOf


Note that that the SCIMv2 solution to use cases #1 and #2 (above) may have many results. However, the results are *objects* that are paged using existing SCIM object pagination (RFC 7644 3.4.2.4).  No pagination of multiple values is necessary.


Use Case #3:  I have the user id "aaaaaaaa-1111-4306-8e52-bb1921f1a7ed" and I want to check if the user is a member of group with id "ffffffff-1111-49f5-b200-2c8aa95f3a49"

Solution: Use the SCIMv2 /user or /group resource with a compound filter:
GET https://scimserver.mydomain.com/user?filter=id+eq+aaaaaaaa-1111-4306-8e52-bb1921f1a7ed+and+(groups.value+eq+ffffffff-1111-49f5-b200-2c8aa95f3a49)

-OR-

GET https://graph.microsoft.com/v1.0/group?filter=id+eq+ffffffff-2222-4263-abd9-878238d6f7b2+and+(users.value+eq+ aaaaaaaa-1111-4306-8e52-bb1921f1a7ed)

Corresponding Microsoft Graph API:
POST https://graph.microsoft.com/v1.0/users/aaaaaaaa-1111-4306-8e52-bb1921f1a7ed/checkMemberGroups
{ "groupIds": [ "ffffffff-1111-49f5-b200-2c8aa95f3a49" ] }

Use Case #4:  I have the group with id "ffffffff-1111-49f5-b200-2c8aa95f3a49" I want to check if the group has a member with user id "aaaaaaaa-1111-4306-8e52-bb1921f1a7ed"

Solution:  This is essentially the same as use case #3 above (just worded from the group perspective).


LDAP has taught us that representing group membership as a multi-valued attribute makes common use cases difficult.  As a result, new APIs (like Azure Graph) represent group memberships with separate resource types.   Even though it is possible to handle common use cases with SCIM filters (described in use cases above), it might still be useful to investigate the addition of two new SCIM resource types (as an extension): a "GroupMembers" and a "UserGroups".  These would be used in the following way (same use cases as above):

Get me the members of a group (returns User objects):
GET https://scimserver.mydomain.com/GroupMembers/<groupId<https://scimserver.mydomain.com/GroupMembers/%3cgroupId>>

Get me groups a user is a member of (returns Group objects)
GET https://scimserver.mydomain.com/UserGroups/<userId<https://scimserver.mydomain.com/UserGroups/%3cuserId>>

Is user a member of a group?
GET https://scimserver.mydomain.com/GroupMembers/<groupId>?filter=<https://scimserver.mydomain.com/GroupMembers/%3cgroupId%3e?filter=> id+eq+<userId>
GET https://scimserver.mydomain.com/UserGroups/<userId>?filter=<https://scimserver.mydomain.com/UserGroups/%3cuserId%3e?filter=> id+eq+<groupId>

--
Matt Peterson
Distinguished Engineer
[e-mail]<mailto:[e-mail]>

From: scim <[e-mail]> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Thursday, May 19, 2022 3:23 PM
To: [e-mail]
Subject: [scim] Feedback and support for draft-hunt-scim-mv-filtering-00.html

CAUTION: This email originated from outside of the organization. Do not follow guidance, click links, or open attachments unless you recognize the sender and know the content is safe.

Hello SCIMers,

We need feedback on to gauge support and adoption of
https://datatracker.ietf.org/doc/html/draft-hunt-scim-mv-filtering-00.html<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-hunt-scim-mv-filtering-00.html&data=05%7C01%7Cmatt.peterson%40oneidentity.com%7C10503fa871554b5554af08da39ddc433%7C91c369b51c9e439c989c1867ec606603%7C0%7C0%7C637885921896175212%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=leZb8egHAXQd8WBKXfujrYd1iWHldZy%2Bww02KOQyDsQ%3D&reserved=0>

Please respond to this thread on the following:


  1.  You have read the draft and believe it is ready to be adopted by the working group. Any other feedback on the content of the draft is welcomed too.
  2.  You are willing to contribute to the draft as a co-author or editor
  3.  You are willing to be an active contributor to the content but can not be a co-author
  4.  You support the draft and plan to implement
  5.  You support the draft but have no time or plans to implement now, but can provide feedback
  6.  You have no interest in the draft

Please provide your feedback by June 10th.

Thanks,
   Nancy