-
Notifications
You must be signed in to change notification settings - Fork 191
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
[docs-only] Claim update process (proxy service readme) #10537
Conversation
Co-authored-by: Phil Davis <phil@jankaritech.com>
services/proxy/README.md
Outdated
@@ -128,6 +128,14 @@ somewhat costly operation, especially if the user is a member of a large number | |||
groups. If the group memberships of a user are changed in the IDP after the | |||
first login, it can take up to 5 minutes until the changes are reflected in Infinite Scale. | |||
|
|||
### Claim Updates | |||
|
|||
OpenID Connect (OIDC) scopes are used by an application during authentication to authorize access to a user's detail, like name or picture. Each scope returns a set of user attributes, which are called claims. The scopes an application should request, depends on which user attributes the application needs. Once the user authorizes the requested scopes, the claims are returned in an ID Token. |
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.
While the content is technically fine. I don't we should add this paragraph here. After all this is the Readme of the proxy
service and not some general introduction to OpenID Connect.
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.
OICD is quite complex, and not everyone undestands this. Therefore I will add this paragraph to the admin docs anyways for the ease of a common understanding of terms and relations. If you think we should drop it here I can remove it.
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.
Yes, OIDC is complex. But still I believe the proxy's README is the wrong place for explaining it.
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.
I think the section should be more specific to oCIS behavior and not so much about generic OIDC stuff.
services/proxy/README.md
Outdated
|
||
OpenID Connect (OIDC) scopes are used by an application during authentication to authorize access to a user's detail, like name or picture. Each scope returns a set of user attributes, which are called claims. The scopes an application should request, depends on which user attributes the application needs. Once the user authorizes the requested scopes, the claims are returned in an ID Token. | ||
|
||
Claims cant get updated automatically in Infinite Scale when there is a change in the IDM (identity management). JWT tokens generated by the IDP (OpenID Connect provider) requested by Infinite Scale, are immutable, means they reflect the IDM claim state when issued. Therefore you can't change or update claims on existing tokens. To provide updated claim information for users in Infinite Scale, a new immutable token must be requested. This especially affects claim changes like changed user details or group names and applies for users individually. |
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.
I guess the main purpose of the "Claim Updates" section is to document the fact that with autoprovsioning enabled updates to user attributes/group membership on IDP side of things (please don't call it IDM here, as that will cause confusion with the idm
service in ocis) are not immediately reflected on the oCIS side.
There are multiple reasons for that:
- There is no active sync process between the IDP and oCIS, the autoprovisioning works based on the users claims returned by the IDP's userinfo endpoint (or extracted from the access token when
PROXY_OIDC_SKIP_USER_INFO
is true) - If e.g. the group membership of a user is changed in the IDP, the earliest possible time that ocis will notice it is, when the current access token expired and a new access token is issued by the IDP.
- There might be an additional delay if the last change of groupmemberships was less than 5 minutes ago. (This was introduced as the whole process of checking and updating group memberships is somewhat resource intensive)
I guess we should also document the facts that
- oCIS can't differentiate between a group being renamed in the IDP and a users being reassigned to a different group.
- oCIS does not get aware when a groups is being deleted in the IDP
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.
For completness, after chatting:
Group renaming or deletion has an impact on sharing or space membership.
ocis cant distinguish between the cases. Users will get access rejected.
@phil-davis mind to have a another look on the language? |
services/proxy/README.md
Outdated
Because there are many ways to implement expiry and handling of access and refresh tokens, only the general advice to (re)log in to get updated claim information can be given. This also applies for connected apps like the Desktop, iOS or Android app! | ||
**NOTES** | ||
|
||
* When there is a changed group information for thousands of users, an additional delay may occur to get updated information based on optimizing computational resources needed for group handling. |
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.
The delay doesn't have to do anything with the number of users or groups. Currently there is an explicit limit in the autoprovisioning code in oCIS to skip the any checks and updates on groupmembership if the last update happened less than 5min ago. (Like a wrote in the other comment)
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.
I interpreted it wrong, will correct.
Fixed
services/proxy/README.md
Outdated
|
||
* Infinite Scale can't differentiate between a group being renamed in the IDP and users being reassigned to a different group. | ||
|
||
* Infinite Scale does not get aware when a group is being deleted in the IDP, an updated claim will not hold any information from the deleted group. Infinite Scale does not track a claim history to comapare. |
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.
compare
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.
Fixed
|
[docs-only] Claim update process (proxy service readme)
Fixes: #10445 ([deployment][ocis-keycloak] Both old and new group names appear in OCIS web-UI after renaming the group name from keycloak)
Add a description about the claim update process and background info.