-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: SCIM list provider users #3405
Conversation
539872d
to
fde8f21
Compare
fde8f21
to
af0b4d7
Compare
- add SCIM list users endpoint
- scan provider user scim fiekds
- start index begins at 1
73d4d06
to
b3bdb8e
Compare
- default names not null
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, but I think we might be missing an authorization check
internal/access/scim.go
Outdated
// this can only be run by an access key issued for an identity provider | ||
ctx := GetRequestContext(c) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this missing a call to RequireInfraRole
(or IsAuthorized
) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Originally that was part of this change, but after building out the rest of the SCIM functionality I realized that the SCIM role wasn't needed. This endpoint can only be called with an access key issued for a provider, and it can only modify the provider that the access key was issued for. In this way is acts similarly to our other isSelf
endpoints.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ahh, because we query with AccessKey.IssusedFor
, which will have a providerID in the case of these SCIM access keys, and there should never be an overlap between userIDs and providerIDs, got it!
Co-authored-by: Daniel Nephin <dnephin@gmail.com>
Co-authored-by: Daniel Nephin <dnephin@gmail.com>
Restore #3379
Summary
Checklist
Related Issues
Part of #3378