Skip to content
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

Merged
merged 4 commits into from
Nov 12, 2024
Merged

Conversation

mmattel
Copy link
Contributor

@mmattel mmattel commented Nov 11, 2024

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.

Co-authored-by: Phil Davis <phil@jankaritech.com>
@@ -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.
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Copy link
Contributor

@rhafer rhafer left a 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.


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.
Copy link
Contributor

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:

  1. 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)
  2. 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.
  3. 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

Copy link
Contributor Author

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.

@mmattel
Copy link
Contributor Author

mmattel commented Nov 12, 2024

@phil-davis mind to have a another look on the language?

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.
Copy link
Contributor

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)

Copy link
Contributor Author

@mmattel mmattel Nov 12, 2024

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


* 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compare

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@mmattel mmattel merged commit 951de08 into master Nov 12, 2024
2 checks passed
@mmattel mmattel deleted the update_claims branch November 12, 2024 14:46
ownclouders pushed a commit that referenced this pull request Nov 12, 2024
[docs-only] Claim update process (proxy service readme)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants