Red Hat Bugzilla – Bug 962863
[RFE] Improve REST API integration for UI Plugins
Last modified: 2015-04-02 14:35:12 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.
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
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.
CC'ing Michael, maybe it's worth revisiting support for passing session ID (i.e. JSESSIONID value) in a way other than HTTP cookie.
(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.
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
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
[*] 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
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.