Bug 1164286

Summary:	[RFE] RHEV-M API needs mechanism to allow an authenticated user to query in the context of another user
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Matt Smith <mjs>
Component:	ovirt-engine	Assignee:	Martin Perina <mperina>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	bazulay, gscott, juan.hernandez, lpeer, lsurette, mjs, mkalinin, rbalakri, Rhev-m-bugs, srevivo, ssekidde, tmishler, ykaul
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-02-23 17:20:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1523346

Description Matt Smith 2014-11-14 14:45:53 UTC

Description of problem:
RHEV-M API currently returns results constrained by the user that has authenticated.  E.g., accessing /api/vms lists VMs that the currently authenticated user has access to view.

It is desirable to allow an account used by an application (e.g., a custom customer-developed RHEV portal consuming the API) to query the API in the conext of another user.  E.g., this application account needs to list the VMs available to a specific user.

Customer recommendations are:
* Support some kind of "su"-like mechasism, maintaining the authcid while changing the authzid
* Extend the existing API to allow passing a user account
* Add new API duplicating current API but with ability to pass a user account
* Support a session token mechanism, where a token can be generated by the application account reflecting a valid session for the user account


Version-Release number of selected component (if applicable):
RHEV 3.x

How reproducible:
RFE - not repoducible bug

Steps to Reproduce:
1.
2.
3.

Actual results:
API does not support ability to change user

Expected results:
API should have mechanism to change user queries are constrained by

Additional info:

Comment 2 Juan Hernández 2014-11-17 08:08:41 UTC

I'd suggest to implement this using the HTTP "From" header (or any other custom header). That header could contain the identifier of the user to impersonate:

  GET /ovirt-engine/api/vms HTTP/1.1
  From: joe
  ...

This could be combined with a new "Impersonate" permission that the authenticated user should have in order to be allowed to actually impersonate other users. This could be a system permission or attached to specific profiles, users or groups.

The required changes should be confined to the authentication layer and to the backend.

Comment 3 Juan Hernández 2014-11-17 08:18:21 UTC

Note also that for this particular use case (finding pools available for a particular user) it may be simpler to add support to query pools by user, like we can query VMs by user. If we do so then the caller could run the query with the admin user:

  GET /api/vmpools?search=user.name%3D=theuser HTTP/1.1

Comment 4 Matt Smith 2014-12-10 13:24:16 UTC

(In reply to Juan Hernández from comment #3)
> Note also that for this particular use case (finding pools available for a
> particular user) it may be simpler to add support to query pools by user,
> like we can query VMs by user. If we do so then the caller could run the
> query with the admin user:
> 
>   GET /api/vmpools?search=user.name%3D=theuser HTTP/1.1

This query would also need to be extended beyond pools, e.g., to allow identification of VMs that the user instantiated from those pools.  At which point, it may be beneficial to simply implement the query across all resource types.

Comment 16 Franta Kust 2019-05-16 12:54:30 UTC

BZ<2>Jira re-sync