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

OIDC logins are cached forever #100

Open
twz123 opened this issue Jul 14, 2020 · 9 comments · May be fixed by #310
Open

OIDC logins are cached forever #100

twz123 opened this issue Jul 14, 2020 · 9 comments · May be fixed by #310
Assignees

Comments

@twz123
Copy link
Contributor

twz123 commented Jul 14, 2020

During debugging of #41, I noticed that the information from the user's last full login are stored indefinitely in OicUserProperty. So there's already a caching/security problem, as anticipated in #41 (comment).

Any changes to the user inside the Identity Provider won't be reflected back into Jenkins if the user won't re-login. As a consequence, session cookies, API Tokens and so on may be valid forever, even if the user has long been disabled in the Identity Provider.

A possible solution would be to use the exp field of the ID Token to check how long the credentials are valid, and, if they are expired, transparently request a new ID Token from the Identity Provider, using a Refresh Token.

@vanhtuan0409
Copy link

@twz123 anyway to purge this cache? can logout from jenkins work :D

@twz123
Copy link
Contributor Author

twz123 commented Jul 29, 2020

Maybe logging out would help. But a malicious user wouldn't want to logout. That way, the malicious user can retain access to Jenkins indefinitely, even if administrators revoke access via the OIDC Identity Provider. So this is a real security concern.

The only workarounds that come to my mind would be to delete the user properties via some groovy script, or to delete the user XML file from the filesystem and refresh Jenkins configuration from disk.

@vanhtuan0409
Copy link

vanhtuan0409 commented Jul 30, 2020

seems like a full logout (both from Jenkins and OIDC) won't help. I encountered a problem when granting extra roles in OIDC provider won't reflect into Jenkins authorities.

A Jenkins restart did purge the cache in my situation. If possible, can you share the Groovy script to purge user cache? a possible workaround is putting a cron job to clear this cache every specific interval

@M1kep
Copy link

M1kep commented Apr 8, 2021

Running Jenkins 2.282 the Jenkins logout button appears to flush the roles. After clicking Logout, if I navigate to the jenkins url, it seamlessly re-auths with updated roles/groups

@michael-doubez
Copy link
Contributor

I'll have to check if the code still has the issue.
If that's the case, the refresh is a good time to renew user info.

@michael-doubez michael-doubez self-assigned this Oct 24, 2022
@michael-doubez michael-doubez added this to the 2.3 milestone Oct 27, 2022
@michael-doubez michael-doubez modified the milestones: 2.3, 2.4 Nov 22, 2022
@michael-doubez michael-doubez modified the milestones: 2.4, 2.5 Dec 15, 2022
@michael-doubez michael-doubez modified the milestones: 2.7, 2.6 Jan 8, 2023
@Janhouse
Copy link

Janhouse commented Feb 1, 2023

This is still an issue. Tried setting OIDC token lifespan to 1 minute but seems like it never refreshes it.
And while group info is now used for Jenkins API, it never gets updated if user is removed from certain groups that provide/limit access or if the user is disabled on the OIDC provider.

  1. It should start using the refresh token and update groups.

  2. And afterwards the Jenkins API token issue can be tackled somehow. One option would be to use OIDC backchannel-logout. In case when user is disabled or groups changed, session can be terminated on OIDC side and provider would connect to Jenkins and log the user out (and possibly remove groups to disable Jenkins API usage).

@michael-doubez
Copy link
Contributor

michael-doubez commented Feb 1, 2023

Yes, that one in on my "what's next" list.

I am investigating the use use of filter which seems to be called whenever an access occurs.
I ve not yet asked to experts on newsgroup channel - they may have a better answer.

@michael-doubez michael-doubez modified the milestones: 2.6, 2.7 Jun 8, 2023
@michael-doubez michael-doubez removed this from the 2.8 milestone Mar 15, 2024
@ZIRAKrezovic
Copy link

Hi @michael-doubez. I have found https://github.com/jenkinsci/keycloak-plugin/blob/master/src/main/java/org/jenkinsci/plugins/RefreshFilter.java which implements token refresh via filter. Would you accept such solution for this plugin? I would be willing to incorporate refresh token support in this plugin.

@michael-doubez
Copy link
Contributor

Hello

Gladly. Implementation should not assume an offline or refresh token is available. There should also be a configurable renewal interval.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants