awslabs / ssosync

Populate AWS SSO directly with your G Suite users and groups using either a CLI or AWS Lambda
Apache License 2.0
531 stars 182 forks source link

Pagination does not work (maybe incorrect use of count parameter) #1

Closed cep21 closed 4 years ago

cep21 commented 4 years ago

I have more than 10 users and the code only fetches the first ten. Inside getUserPage you have

       q.Add("count", "10")

I think this means "only return 10 total" not "return 10 at a time".

I removed that line and the code worked fine for me.

Edit: Nope removing the line did not resolve the problem :(

cep21 commented 4 years ago

I wonder if the response from "https://scim.us-west-2.amazonaws.com/ is correct

I ran in debug mode and added a Println to the response body. I see the outbound HTTP request URL /scim/v2/Users?count=10&startIndex=1 and see the incomming response body {"totalResults":10,"itemsPerPage":10,"startIndex":1,"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],"Resources....

Which seems to imply there are only 10 total results ,but I have many more than 10 users currently synced to AWS.

cep21 commented 4 years ago

If I modify the code to remove the count parameter entirely I see the request URL /scim/v2/Users?startIndex=1 and the response body {"totalResults":50,"itemsPerPage":50,"startIndex":1,"schemas":["urn:ietf:params:scim:api:messages:2.0:ListResponse"],"Resources....

grugnog commented 4 years ago

Can reproduce this - it looks to me like you can use count to limit the result size below 50, but that (a) totalResults is incorrect and (b) startIndex is being ignored - it doesn't matter what value startIndex is set up, it always gives the first set of results. These seem to be the case if count is set and if it is removed.

Given this, it seems like it's currently impossible to use AWS SCIM to efficiently provision more than 50 users?

grugnog commented 4 years ago

https://tools.ietf.org/html/rfc7644#section-3.4.2.4 is the spec for this

mattbryant-asana commented 4 years ago

Rather than querying for all users, you can do individual filter=externalId eq "foo" queries on each individual user. It's definitely not efficient, but it mostly works.

katallaxie commented 4 years ago

@grugnog you are right, this is a current limitation. But filtering for the user is sufficient efficient operation. I have added it to #3. This would need some testing from your end. @cep21 you maybe want to try develop with the filter sync approach.