Subject: Re: [scim] pagination for users in READ of single group GET /Groups/{id}

From: Karen Nguyen <[email-masked]>
Date: Thu, 20 Jun 2019 08:26:05 -0700

Hi folks,

I’d like to echo that we are also encountering scaling challenges for the GET /Groups/{id} endpoint when the group contains 50k+ users.

We are considering leveraging the specification SCIM 2.0 section 3.4.2.4 Pagination.  

Would you recommend this, or do you have other guidance on what to do in this case.

Thanks,
Karen Nguyen

> On Mar 19, 2019, at 10:29 AM, [email-masked] wrote:
> 
> Send scim mailing list submissions to
> 	[email-masked] <mailto:[email-masked]>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>
> or, via email, send a message with subject or body 'help' to
> 	[email-masked] <mailto:[email-masked]>
> 
> You can reach the person managing the list at
> 	[email-masked] <mailto:[email-masked]>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of scim digest..."
> Today's Topics:
> 
>   1. Help needed on READ of single group  GET /Groups/{id}
>      (Ashok Dhakar)
> 
> From: Ashok Dhakar <[email-masked] <mailto:[email-masked]>>
> Subject: [scim] Help needed on READ of single group GET /Groups/{id}
> Date: March 19, 2019 at 10:29:23 AM PDT
> To: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> 
> 
> Hi Team,
>  
> The standard response defines the single group get result as
> {
>   "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
>   "id":"e9e30dba-f08f-4109-8486-d5c6a331660a",
>   "displayName": "Tour Guides",
>   "members":[
>     {
>       "value": "2819c223-7f76-453a-919d-413861904646",
>       "$ref": "https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646 <https://example.com/v2/Users/2819c223-7f76-453a-919d-413861904646>",
>       "display": "Babs Jensen"
>     },
>     {
>       "value": "902c246b-6245-4190-8e05-00816be7344a",
>       "$ref": "https://example.com/v2/Users/902c246b-6245-4190-8e05-00816be7344a <https://example.com/v2/Users/902c246b-6245-4190-8e05-00816be7344a>",
>       "display": "Mandy Pepperidge"
>     }
>   ],
>   "meta": {
>     "resourceType": "Group",
>     "created": "2010-01-23T04:56:22Z",
>     "lastModified": "2011-05-13T04:42:34Z",
>     "version": "W\/\"3694e05e9dff592\"",
>     "location": "https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a <https://example.com/v2/Groups/e9e30dba-f08f-4109-8486-d5c6a331660a>"
>   }
> }
>  
> In our case we have group with 50k members, so every time SCIM call is being made to GET the group details by its  /Groups/{Id}
> We encounter performance problems as it ends up listing of all the members every time.
> The problem becomes worse when we try to list of groups and each group contains 50k members. GET /Groups/{id}?count=20
>  
> As of now we are circumventing the problem by specifying the attributes as part of scim request /Groups/{id}?attributes=id,displayName.
>  
> Every time we do 3rd party integration with SCIM compliant adapters which is responsible for pushing the user information to our identity solutions this becomes as bottleneck,
> as it requires code changes.
>  
> I was thinking to address this in the following way
> Show only few members as part of /Groups/{id}
> Provide another endpoint to fetch members with pagination support /Groups/{id}/members?count=100
>  
> I would like to know any better solutions to this problem or work in progress to address this so that I don’t implement the custom solution.
>  
> Regards,
> Ashok
>  
> 
> 
> _______________________________________________
> scim mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/scim <https://www.ietf.org/mailman/listinfo/scim>