Bug 962863

Summary:	[RFE] Improve REST API integration for UI Plugins
Product:	[Retired] oVirt	Reporter:	Vojtech Szocs <vszocs>
Component:	ovirt-engine-webadmin	Assignee:	Vojtech Szocs <vszocs>
Status:	CLOSED WONTFIX	QA Contact:	bugs <bugs>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	bazulay, ecohen, iheim, mgoldboi, pablo.iranzo, pstehlik, rbalakri, sbonazzo, vszocs
Target Milestone:	---	Keywords:	FutureFeature, Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	ux
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 15:46:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Vojtech Szocs 2013-05-14 15:38:26 UTC

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 Vojtech Szocs 2013-05-28 16:09:34 UTC

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 Vojtech Szocs 2013-06-10 15:55:39 UTC

(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 08:14:46 UTC

Target version?

Comment 6 Vojtech Szocs 2013-11-19 11:03:43 UTC

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 Vojtech Szocs 2014-03-26 17:07:42 UTC

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 15:46:49 UTC

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.