Feature #11755
closedImpersonate user through REST API auth
0%
Description
The following patch implement a 'switch user' feature which lets an admin-level user impersonate any other user in the context of the REST API.
For any API authentication method, it is allowed to either pass a 'su' parameter or a 'X-Redmine-Switch-User' header, which is only considered if the primary auth led to an admin-level user. The expected value is a user 'login' (no ID or API key).
This is currently very useful when linking different applications with Redmine which share the same authentication reference (LDAP in my case), but don't have access to user's credentials (their Redmine API keys or their plain password). I use an admin-level account for every app which wants to talk with Redmine, but this app should ideally lower its privileges to its current user. This feature does just that, without diving into complex SSO problems.
Files
Related issues
Updated by Jean-Philippe Lang about 12 years ago
- Target version set to 2.2.0
Is the parameter option really needed? I'd like to keep the X-Redmine-Switch-User
header option only to avoid any clash with other parameters.
Updated by Jean-Philippe Lang about 12 years ago
I think we should handle the case of an invalid username with a specific error response (eg. 412 Precondition Failed
seems appropriate).
Updated by Vincent Caron about 12 years ago
Is the parameter option really needed?
I don't think so, I simply mimicked the api_key implementation which proposed both a param and a header for authentication. I personnaly only use the header way.
I think we should handle the case of an invalid username with a specific error response (eg. 412 Precondition Failed seems appropriate).
Indeed. Right now it will continue as 'admin' which is unsafe.
Find attached a new patch which takes into account those two remarks.
Updated by Jean-Philippe Lang about 12 years ago
- Status changed from New to Closed
- Resolution set to Fixed
Feature added in r10608, thanks.
Patch was slightly refactored and tests were added. A small change was introduced: a 412 response will be returned if the given username exists but is not active (eg. locked).
Updated by Vincent Caron about 12 years ago
Thanks !
I remembered wondering if fetching a user with User.find_by_login() was handling the locked account case and forgot to check.
Updated by Hannes Meier about 12 years ago
this enhancement solves my older ticket #11551 or?
So this can be closed as well i guess
thank you.