Bug 962863 - [RFE] Improve REST API integration for UI Plugins
[RFE] Improve REST API integration for UI Plugins
Status: CLOSED WONTFIX
Product: oVirt
Classification: Community
Component: ovirt-engine-webadmin (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: vszocs
bugs@ovirt.org
ux
: FutureFeature, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-14 11:38 EDT by vszocs
Modified: 2015-04-02 14:35 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Improve REST API integration for UI Plugins Reason: Result (if any):
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-22 11:46:49 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description vszocs 2013-05-14 11:38:26 EDT
Currently, UI Plugin infrastructure works in the following way:
- upon WebAdmin GUI login, take GUI (admin) user credentials and initiate (one) REST API session
- broadcast received (single) session ID to all UI plugins

Despite very simple, this approach has following disadvantages:
- when UI plugin talks with REST API via session ID, the session has exact same privileges as GUI (admin) user
- having only one REST API session, some evil UI plugin can close the session (enforce logout) which can compromise behavior of other UI plugins

This RFE essentially suggests replacing "One [admin-gui-user] session for all plugins" with "One [plugin-user] session per each plugin" approach.

Design proposal:
1. when processing WebAdmin GWT application request (server-side) - during UI plugin discovery phase:
   - check if the given plugin explicitly enabled REST API integration (boolean) via its metadata/config
   - if yes, load username/domain/password credentials + permissions (REST API integration user) via its metadata/config
   - validate above mentioned user credentials, create user if it doesn't exist yet
   - synchronize permissions from plugin metadata/config with given user, i.e. update permissions for that user
2. when processing WebAdmin GWT application request (server-side) - during embedding plugin data into HTML phase:
   - eagerly create REST API session for the user specified in previous step (REST API integration user)
   - embed REST API session ID into runtime plugin information, no user credentials allowed here!
3. when starting up WebAdmin GWT application (client-side) - during UI plugin load phase:
   - pass REST API session ID to given UI plugin via UiInit function
   - this means RestApiSessionAcquired is not necessary anymore, since session creation is not asynchronous from client perspective

What we gain:
- each UI plugin will have its own dedicated REST API session, unrelated to GUI (admin) user credentials
- each UI plugin can (must) explicitly define permissions it requires with regard to REST API integration
- for each UI plugin, we can selectively enable/disable REST API integration as necessary (useful for WebAdmin end-users)
- we don't have to keep-alive the single "shared" session anymore, because there will be no "shared" session anymore

Potential issues:
It might be difficult to create REST API session from within server-side code, I'd really like to avoid doing "Engine -> HTTP request -> Engine" cycle.
Comment 3 vszocs 2013-05-28 12:09:34 EDT
CC'ing Michael, maybe it's worth revisiting support for passing session ID (i.e. JSESSIONID value) in a way other than HTTP cookie.

This would allow UI plugin code (JavaScript) to communicate directly with Engine REST API. Using JSESSIONID cookie is most likely impossible because REST API expects this cookie to be set for path=/api and plugin code runs under path=/webadmin -> worth giving a try, though. (maybe we can try setting the cookie for the root path)
Comment 4 vszocs 2013-06-10 11:55:39 EDT
(In reply to vszocs from comment #3)
> (maybe we can try setting the cookie for the root path)

Bad idea, since there are different JSESSIONID cookies for different applications, depending on cookie path.
Comment 5 Sandro Bonazzola 2013-11-19 03:14:46 EST
Target version?
Comment 6 vszocs 2013-11-19 06:03:43 EST
Target version = future for now, currently low priority

To summarize positive impacts of this RFE:
1. isolation -> each UI plugin will have its own REST API session assigned, i.e. avoid single shared session and issues that come with it
2. transparency -> each UI plugin will have to state permissions for its REST API session explicitly, i.e. permissions unrelated to admin GUI user
3. control -> we can disable REST API session functionality per each UI plugin if necessary
4. simplification -> no need for "keep-alive single shared session" functionality anymore
Comment 7 vszocs 2014-03-26 13:07:42 EDT
We should consider following items for this RFE:

- have one REST session per UI plugin (which also means creating associated Engine user for this purpose) -> plugin vs. plugin REST session isolation

- create REST session not from client (WebAdmin/JavaScript) but from server (when serving WebAdmin.html) -> avoid issues with cookies [*] & HTTP Basic Auth handling [**]

[*] multiple-cookies (one per UI plugin) with same name (JSESSIONID) for same origin (REST API) is not possible

[**] browsers usually cache HTTP "Authorization" request header for given origin (REST API) which complicates authentication from plugin perspective
Comment 8 Itamar Heim 2015-03-22 11:46:49 EDT
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Note You need to log in before you can comment on or make changes to this bug.