Project

General

Profile

Actions

Feature #11755

closed

Impersonate user through REST API auth

Added by Vincent Caron over 12 years ago. Updated about 12 years ago.

Status:
Closed
Priority:
Normal
Category:
REST API
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

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

api-auth-switch-user.patch (1.74 KB) api-auth-switch-user.patch Vincent Caron, 2012-09-01 15:33
api-auth-switch-user-v2.patch (1.81 KB) api-auth-switch-user-v2.patch Vincent Caron, 2012-10-09 23:41

Related issues

Has duplicate Redmine - Feature #11551: REST-API: Admine can create time entries for other usersClosed

Actions
Actions #1

Updated by Vincent Caron about 12 years ago

  • Assignee set to Jean-Philippe Lang
Actions #2

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.

Actions #3

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).

Actions #4

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.

Actions #5

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).

Actions #6

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.

Actions #7

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.

Actions #8

Updated by Jean-Philippe Lang about 12 years ago

Hannes Meier wrote:

this enhancement solves my older ticket #11551 or?

Indeed.

Actions

Also available in: Atom PDF