You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Login as a userA, go to My RSpace -> My Profile page, generate API key.
Logout, login as a System Admin, go to System page, start 'Operating as' the userA
While operating as the userA, navigate to their profile, scroll down to 'API key and click on 'show key'
-- the System Admin will be able to see the user's API key
Additionally, there is a sysadmin API allowing to retrieve users' API keys.
Expected behavior
Only user should be able to access their API key. While the System Admin is a privileged user, they shouldn't be able to impersonate users outside the impersonations scheme provided by the GUI app itself.
There may be specific migration scenarios that use API to re-create user's content, and for that they need to create/retrieve/delete API keys. We may keep supporting API methods meant for that, but these should be guarded by deployment property that is disabled by default.
Also note that while action of viewing user's API key is traceable (logged in httpRequests.log and error.log) it's maybe worth additional logging in SecurityEvents.txt.
mKowalski256
changed the title
System admin should not see user's API key in 'operate as' mode
System admin should not be able to read user's API key
Jul 30, 2024
Fixed with commit 73ae18d522a - System Admin should no longer be able to retrieve API key generated by the user.
Note that System Admin can still revoke/regenerate new API key for the user - these are useful in some support scenarios, and risk-wise it's similar to how we allow System Admin to change user's password.
To Reproduce
Steps to reproduce the behavior:
-- the System Admin will be able to see the user's API key
Additionally, there is a sysadmin API allowing to retrieve users' API keys.
Expected behavior
Only user should be able to access their API key. While the System Admin is a privileged user, they shouldn't be able to impersonate users outside the impersonations scheme provided by the GUI app itself.
There may be specific migration scenarios that use API to re-create user's content, and for that they need to create/retrieve/delete API keys. We may keep supporting API methods meant for that, but these should be guarded by deployment property that is disabled by default.
Also note that while action of viewing user's API key is traceable (logged in
httpRequests.log
anderror.log
) it's maybe worth additional logging in SecurityEvents.txt.Additional context
Based on a reported issue #58.
The text was updated successfully, but these errors were encountered: