Re: [scim] April 7 Meetup Agenda

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

Except for the case of a multiple value attribute having many (>100) values, I don't think there is much utility being able to specify a subset of values in a filter.  In your email example, it would be very practical for the client to receive all email values.  Once received, it is easy for the client to select the "work" emails (if this is all that the client is interested in).

The compelling case for multi-valued paging is for retrieving values of Group.members (members of a group) and User.groups (groups a user is a member of).  It is compelling because these are the only attributes in the base SCIM schema that are likely to have hundreds of values.

Fortunately, is still possible to handle the most common group memberships use cases without needing multi-valued pagination.  The following is a list of use cases for group memberships.  I have provided the SCIMv2 request that would satisfy the use case without the need for multi-valued attribute pagination or any changes to the SCIM v2 spec.  (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>

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

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

--
Matt Peterson
[e-mail]



From: scim <[e-mail]> On Behalf Of Phil Hunt
Sent: Wednesday, April 7, 2021 10:18 AM
To: Pamela Dingle <Pamela.Dingle=[e-mail]>
Cc: [e-mail]
Subject: Re: [scim] April 7 Meetup Agenda

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.

Regarding the discussion of the current draft proposals, the MV paging draft was originally designed to facilitate paging of large groups.

However, what I think is useful about the draft is it extends SCIM to allow both filters and paging parameters on attribute qualifiers.

It is handy if for example you want to return only specific value instances of a CMVA.  For example in PAM you could return only values of a specific credential type. In the draft, there is an example returning only work email addresses as a simple example.



GET /Users/2819c223-7f76-453a-919d-413861904646?

     attributes=*,emails[type eq \"work\"]

In the normal SCIM protocol, a filters and paging params are used to qualify which resources are returned.  In this draft extension, filters and paging params may be used to qualify which values returned.

I mention this, because the draft may be of broader use then just group paging.  If there is interest, I am happy to keep working on it.

Phil Hunt
@independentid
[e-mail]<mailto:[e-mail]>




On Apr 7, 2021, at 7:08 AM, Pamela Dingle <Pamela.Dingle=[e-mail]<mailto:Pamela.Dingle=[e-mail]>> wrote:

Hi all,

Our agenda for today's bi-weekly meeting at 8am PT will start with a review of the ietf scim PAM (privileged access management) draft as well as to look at the spreadsheet that you all might remember from a previous meetup.

Also - I believe I now have a calendar setup that can be exported to a .ics file and therefore reliably imported by you all.  That .ics link is going into our github repo, which is also where our notes will live and so we can start posting links to calendars, agendas, and notes with ease.

For now, here is the calendar link and also the teams link:

Calendar ICS: https://outlook.live.com/owa/calendar/00000000-0000-0000-0000-000000000000/25ef962b-555f-4781-b533-bfe7be451be8/cid-95C8043F862EFECA/calendar.ics<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.live.com%2Fowa%2Fcalendar%2F00000000-0000-0000-0000-000000000000%2F25ef962b-555f-4781-b533-bfe7be451be8%2Fcid-95C8043F862EFECA%2Fcalendar.ics&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7C84b7ebdd5371454ffb1d08d8f9e0d06c%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637534091259927361%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9jyWeXn9UU%2BfZnQuhNs724fjiQ0LP9hMLlauDIqnTZQ%3D&reserved=0>
Calendar HTML: https://outlook.live.com/owa/calendar/00000000-0000-0000-0000-000000000000/25ef962b-555f-4781-b533-bfe7be451be8/cid-95C8043F862EFECA/calendar.ics<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutlook.live.com%2Fowa%2Fcalendar%2F00000000-0000-0000-0000-000000000000%2F25ef962b-555f-4781-b533-bfe7be451be8%2Fcid-95C8043F862EFECA%2Fcalendar.ics&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7C84b7ebdd5371454ffb1d08d8f9e0d06c%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637534091259937351%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q3V5vJxLEz5K6VZVu8MB5IDy4ROtmuHnwiwlR0EoR%2BI%3D&reserved=0>

Teams: Click here to join the meeting<https://nam12.safelinks.protection.outlook.com/ap/t-59584e83/?url=https%3A%2F%2Fteams.microsoft.com%2Fl%2Fmeetup-join%2F19%253ameeting_Y2QxYzU0NjEtN2ZjNi00MGQ1LWJkMzUtZmQxZjZlZGZiYWZi%2540thread.v2%2F0%3Fcontext%3D%257b%2522Tid%2522%253a%252272f988bf-86f1-41af-91ab-2d7cd011db47%2522%252c%2522Oid%2522%253a%252285bc2986-6412-41c0-ab6d-98c80048fe64%2522%257d&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7C84b7ebdd5371454ffb1d08d8f9e0d06c%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637534091259947355%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SsCJvVHPNkG8GvzwDDsZEcWnyctDImM3QK4Q47vu37U%3D&reserved=0>

_______________________________________________
scim mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/scim<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fscim&data=04%7C01%7CMatt.Peterson%40oneidentity.com%7C84b7ebdd5371454ffb1d08d8f9e0d06c%7C91c369b51c9e439c989c1867ec606603%7C0%7C1%7C637534091259957345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X68aS58slt1ZtTVW40EKxOhmLZnmBKqL8yijtXeeKjs%3D&reserved=0>