Thoughts about Canonical's UCCS Service

In Octobre 2012, I visited UES (Ubuntu Enterprise Summit) 2012.10 in Copenhagen. Amongst other new features in Ubuntu 12.10 the new UCCS service at Canonical got introduced.

UCCS is a session broker[1] (as of Ubuntu 12.10 for RDP fullscreen sessions only) that provides login / session information to LightDM. In Quantal, the user can select a Remote Login Session as login option.


How UCCS works together with LightDM

If Remote Login in LightDM is selected, LightDM retrieves a list of session profiles from the UCCS service site. The user can select from one of his pre-configured session profiles and log on to some remote application server (RDP only for now) that he/she has previously configured at UCCS.

LightDM launches a minimal guest session and within this guest session it does an XFreeRDP call to the remote application server using the login information stored at UCCS.

The login information stored at UCCS can be: username, domain, password(!?!), hostname. All information can be entered in UCCS. The UCCS client behind LightDM retrieves any of this information from UCCS. Information that is missing in the session profile can be entered as part of the LightDM logon process.

During (RDP) session startup the login information is piped through a unix file socket into xfreerdp via a patched-in command line option (--from-stdin, only available in the Ubuntu version of the freerdp-x11 package).

Thoughts on UCCS

There are the following issues I see with this new UCCS service:

  • Only MS Windows services can be used with UCCS. At the time of UES 12.10 there had been no concepts for remote terminal services based on GNU/Linux remote application servers
  • the UCCS services can be used to collect non-anonymous data for remote desktop behaviour of Ubuntu users, if people use such a service they should be aware of this(!!!)
  • the UCCS client in LightDM retrieves passwords from UCCS (if people are stupid enough to enter them into the UCCS session profiles) in clear text, so the assumption comes quick that passwords are stored unencrypted (or symmetrically encrypted) within the UCCS database, so my recommendation is not to leave any password on the UCCS site that you don't want to see compromised(!!!)

Current projects around UCCS

Nonetheless, I see quite some benefits behind session brokerage like is provided via UCCS. However, I do think that the administrator of a terminal server site should not have using a public service such as UCCS as the only option available. Providing a UCCS like session broker on the local network should be an objective for a future version of Ubuntu.

So, what I am currently working on within the context of my upstream X2Go activities are the following aspects/feature:

  1. X2Go integration into Ubuntu, includes X2Go integration into UCCS
  2. Provide non-fullscreen sessions called `Remote Apps' through X2Go, goal is a mixed desktop consisting of a Unity guest session and remote (GNU/Linux) applications provided via X2Go's Published Applications feature
  3. A session broker for X2Go. This session broker--by default--can be used with X2Go Client and Python X2Go
  4. A LightDM add-on that can replace the UCCS client behind LightDM's remote login feature, so that LightDM can talk to an X2Go Session Broker instead. With this, a non-public UCCS-like session broker can be deployed on local sites. Thus, the login information stays within the boundaries of the local network