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:
I'd really like to see spice handling SSO via kerberos/other via spice-ga, not going via engine.
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.
(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).
(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.
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
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).