Re: [scim] Retrieving members of a group

[Jaap Francke <[e-mail]>]

Thanks Phil for your quick response,

I agree with you that I don’t see a use case for (sub)pagination on the user. Filters on the USER endpoint is a good way to look for particular user(s) who are part of a certain (large) group; probably in combination with a filter on some other user attribute.

I do see a use case for listing available groups. We plan to have a group schema extension so we can filter on the group endpoint to look for particular groups.
That’s why we plan to return partial group representations, excluding the members which are not relevant at that moment.
In this way we don’t get huge payloads without need for subpagination and we’re still conforming to the SCIM specification.

I was curious if anyone else did a similar thing when using the group-endpoint or has thoughts about this approach. If this is a common and good approach, it could be part of the SCIM specifications as an example.

Thanks

Jaap

On 4 Dec 2018, at 18:03, Phil Hunt <[e-mail]<mailto:[e-mail]>> wrote:

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=