Re: [scim] Retrieving members of a group

["Jackson Shaw (jshaw)" <[e-mail]>]

Indeed. We are one of the ones who feel this question is not adequately addressed…

Jackson Shaw
Product Management, One Identity
☎ [phone]

From: scim <[e-mail]> On Behalf Of Phil Hunt
Sent: Tuesday, December 4, 2018 9:03 AM
To: Jaap Francke <jaap.francke=[e-mail]>
Cc: [e-mail]
Subject: Re: [scim] Retrieving members of a group

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

Jaap,

You are correct that the SCIM protocol does not support sub-pagination of group members.

This question has come up several times since, so I’ll pass along my *personal* thoughts...

As group membership grows, the associated confidentiality of that list also grows. As such many service providers do not return member values except to privileged clients. Listing the members of a team is one thing, but listing the employees of a company, or all customers is quite another.

As group size grows, the change rate of a Group resource also grows. Many use cases for pagination assume that consistent results between pages would also be supported. That means the SCIM SP would have to maintain a query results buffer in order to return results while the data may be changing underneath. This impacts SCIM service providers in key ways:
* Scalability costs of providing consistent result sets
* Results consistency and increased shared state costs across clusters.
* Denial-of-Service risks associated as attackers perform seemingly innocent queries that consume undue resources. LDAP has this problem, and it is one of the reasons I never recommend LDAP for open internet use without some form of counter-measures.

Many of the use-cases I have heard are often driven by user-interface designs intended to aid users in scanning through a group. In my experience I’ve found these systems to be particularly tedious with large groups. The UX often ends up requiring a user-agent side search function so you can find names rather than page through hundreds of pages. This is in part why I suggest group management be done using user-centric calls (see below) or relationship basis like we see in large-scale social networks.

One could argue that group membership should never be returned and instead:
* Use queries against User resources to search for groups a User is a member of.
* Use a query filter against Group resources to test if a User is a member.

There are cases where privileged services need to synchronize or reconcile across domains. In these cases, it is important to return the entire group object as of a point in time so that consistency between systems can be periodically compared.

It’s quite possible the group may re-form to tackle this question down the road. After-all the pagination question keeps coming up and is worthy of more discussion IMO.

Cheers,

Phil Hunt


On Dec 4, 2018, at 2:04 AM, Jaap Francke <jaap.francke=[e-mail]<mailto:jaap.francke=[e-mail]>> wrote:

Hi all,

I would like to have my understanding confirmed on usage of the GROUP endpoint.

When I do a GET on the GROUP endpoint, the members attribute of a returned GROUP resoiurce contains a list of all members of that group.
If the group contains only a few members, that’s not a problem.
However, when the group contains a lot of members, the payload gets “too big” and pagination for the members does not apply.

I assume the way to solve this is to return a partial representation of the group resource by setting the schema metadata returned=never (or returned=request) in the group schema definition?
When doing so, a GET on the GROUP endpoint results in a list of groups with common resource attributes (id, externalid, meta) and group displayName.

To retrieve the list of members of a group, one would have to do a GET on the user endpoint using a filter on the groups attribute, right? In this case pagination does apply.

Your responses are appreciated, thanks!

Jaap Francke
_______________________________________________
scim mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_scim&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=LsCH7qZCjIgw_Y1OrhcvqpsjNdeYbp7rYDyNrjjTeCY&s=f5f3wOp9RMHmsloc2YdksmbnaxEwZbhvA-_nP6fujvI&e=