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:
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.
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
(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.
BZ<2>Jira re-sync