Bug 955261

Summary:	[RFE] add possibility to perform SSO when user connects with ticket issued through REST API
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	David Jaša <djasa>
Component:	ovirt-engine-restapi	Assignee:	Michal Skrivanek <michal.skrivanek>
Status:	CLOSED DUPLICATE	QA Contact:	Shai Revivo <srevivo>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.2.0	CC:	bazulay, bsettle, dblechte, iheim, juan.hernandez, michal.skrivanek, oramraz, rbalakri, Rhev-m-bugs, sherold, vszocs
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---	Flags:	sherold: Triaged+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	virt
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-06-30 06:29:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Docs	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Jaša 2013-04-22 16:46:52 UTC

Description of problem:
add possibility to perform SSO when user connects with ticket issued through REST API

Version-Release number of selected component (if applicable):
rhevm-m 3.2 beta2 / rhevm-restapi-3.2.0-10.19.beta2.el6ev.noarch

How reproducible:
always

Steps to Reproduce:
1. set a ticket of a tooled VM in (filtered) API
2. connect to the VM using this ticket:
remote-viewer --spice-ca-file <rhevm_ca> --spice-host-subject <host_subject> spice://<host>:<port>/tls-port=<secure_port>
3.
  
Actual results:
user is not logged in or screen remains locked

Expected results:
user gets logged in or the screen is unlocked for her

Additional info:

Comment 1 Itamar Heim 2013-04-22 20:00:40 UTC

I'd really like to see spice handling SSO via kerberos/other via spice-ga, not going via engine.

Comment 2 Michal Skrivanek 2013-04-23 09:12:00 UTC

if you want to do that via remote-viewer that would be a question to SPICE I suppose. David? I doubt it's easy

Otherwise you can use vdsClient to pass desktopLogin to the guest parallel to the remove-viewer invocation.

Comment 3 David Jaša 2013-04-23 10:30:04 UTC

(In reply to comment #1)
> I'd really like to see spice handling SSO via kerberos/other 

That would give you client user --> guest user SSO, not RHEV-M user --> guest user SSO if I understand correctly, and that is neither what User Portal does, nor what is needed for most scenarios.

> via spice-ga, not going via engine.

Why should be the session functionality duplicated in both agents? And wouldn't it be security risk to transfer password over client or to allow password-less login based on username that the client can easily fake?

(In reply to comment #2)
> if you want to do that via remote-viewer that would be a question to SPICE I
> suppose. David? I doubt it's easy
> 
> Otherwise you can use vdsClient to pass desktopLogin to the guest parallel
> to the remove-viewer invocation.

If that vdsClient call is exposed via REST API, we're halfway there. My goal is to have feature parity of REST API with User Portal so that custom user portals (or User Portal itself if it is ported on top of REST, too) can do the same things as current UP does.

With two separate REST actions, you still need to watch if client has successfully connected so you know if you should call SSO action or not - and that seems quite redundant to me because this very information is already known in qemu-libvirt-vdsm-engine chain (and if it is reported in usuitable way, I'd prefer to see the fix here).

Comment 4 Michal Skrivanek 2013-05-16 07:32:30 UTC

(In reply to comment #3) 
> If that vdsClient call is exposed via REST API, we're halfway there.
it is not, however it's not difficult to add that
But the remote-viewer would need to call it on connect.
It would be easy if we do implement the remote-viewer ability to invoke REST on RHEV-M engine.

Comment 5 Itamar Heim 2013-12-01 19:19:22 UTC

this won't work if engine doesn't have the user/password, since client did something like kerberos authentication (to be introduced).

also, see http://www.ovirt.org/Features/SSO

Comment 6 David Jaša 2013-12-02 12:41:33 UTC

There are at least these reasons to implement this RFE:
  * Windows VMs will be stuck with this "legacy" SSO for longer time
  * REST-based User Portal/webadmin will need it if merged before new SSO
The alternative is something in backend that would cache credentials, monitor connection events and current "Console user" (something like: if there is a new connection with Console user change, perform SSO).