Dave's Bit Bucket

Friday August 31, 2007

A Holy Grail: Non-Web Single Sign-on across Multiple Labels, with Trusted Extensions and Secure Global Desktop

As a result of lots of configuring and a workaround from Stephen Browne, I've finally got a significant element of my Trusted Extensions (TX) lab environment to where I wanted it to be!

Background, and Problem Statement

One of the things I've been working on, is eliminating the need for users to log on to systems they access from a TX environment. After all, they've already authenticated to the TX environment to its satisfaction, in order to get their sesson running in the first place; so, why should they need to enter more passwords in order to use remote, per-label systems?

Password-entry profusion, while it's something most folk working in a single-label world of distributed systems are reasonably pragmatic about living with, really starts to become a bind in a multi-label environment, where a user would most likely need to enter passwords to usefully interact with systems which have an isolated instance at every label in their clearance range in order to start productively doing their job, once they come on shift or watch. This makes staff changeovers take much longer than the single smartcard-swap and password entry you'd expect in a streamlined Sun Ray environment.

So, as the Krikkiters said about the rest of the Universe at large, "it has to go".

Technology Choices

The initial idea was to use Kerberos, on the grounds that it's elegant and I'm reasonably familiar with it. If each zone in the TX environment was a Kerberos client, and there was a KDC on each stovepipe network, then a bit of scriptage (or, more likely, PAMmery) in a user's Trusted Path home directory could potentially call runinzone (see page 15) or something similar, to do a kinit in the zone and thus get the user a per-zone ticket. The "runinzone or similar" hack would be necessary as the zone_enter() call with which TX engages a user with processes running at a label (ie, in a non-global zone) doesn't traverse the non-global zone's PAM stack, so tweaking around with /zone/<zone>/root/etc/pam.conf wouldn't be productive.

There are "various things being done" to Kerberos to make it play more nicely in a TX environment, so while this is still ongoing, I was left scratching my head.

By considerable good fortune, I caught up with John Pither, who told me about the "JDS Integrated Mode" in SGD. This does some cunning single sign-on to the SGD server when you log into your regular account, and nails an extra menu into the JDS Launch tool, populated with the same pick-list apps you get in your SGD Webtop app menu, so that you can use the apps and render their windows in your main desktop session without having to launch a browser and manually log into SGD.

As users are likely to migrate eventually from Trusted CDE to Trusted JDS on their TX / SNAP environments, "game on"!

SGD Integrated Mode and the Trusted JDS Launch Tool

Integrated Mode works by adding an extra action to those performed at user login (or, in our case, non-global zone entry). This looks up the .tarantella/tcc/profile.xml file which gets installed in the user's home directory when Integrated Mode is first set up, looks for the SGD server defined in the file's <url> tag, and authenticates to it with the token in the <AT> tag. As each user has a home directory at each label in their clearance range, plus one on Trusted Path, setting this up means that a given user has multiple .tarantella/tcc/profile.xml files, one per label, and they are different from eachother.

Extra menu items, to integrate with the Launch tool, are also copied into the user's .gnome2/vfolders hierarchy.

This is all fine, so far; and the lookup / authenticate action is independent of the PAM stack, so it works just as well on a zone_enter() as a regular login.

(An aside: we're not running the SGD server in a non-global zone on the TX box right now, as it doesn't work; SGD wants to bind its own X server, and the X11 ports are already in use as multi-level ports across all zones by TX's own label-aware X server. The SGD team assure me that this will be addressed in the next release, but right now, you just need to have an SGD server running on regular Solaris on each of your stovepiped, labelled networks.)

However, there's a snag with the Trusted JDS Launch tool; when a user starts a session, it reads its configuration from the user's home directory on Trusted Path (since Trusted Path is the label which paints the Launch tool on the display, anyway) and leaves it at that. It doesn't read any further configuration from user home directories at other labels in other zones. It would be Really Cool if the behaviour associated with the Trusted JDS Launch tool was commensurate with the configuration of the user's home directory at the label at which the currently-shown workspace is running; the RFE is in, and I'm assured that the functionality will be implemented in the next-but-one incremental release of Solaris 10 (ie Update 5, for folk keeping count).

Workaround

The current workaround - which most organisations are likely to find acceptable anyway - is to:

cp ~/.gnome2/vfolders/applications/*.desktop ~/Desktop

...for each user at each label within their clearance range where SGD-style SSO is required. This puts the application launch actions which would be presented in the Launch tool, on the backdrop.

So once this is all set up, a user can log into their TX environment, switch to a workspace at the appropriate label, click the appropriate icon on their backdrop and be presented with an authenticated session to whichever remote system or application they need to access, at the appropriate label.

Job done :-).

btw, a small teaser; I put "non-web" in the title to distinguish this type of single sign-on from other types of single sign-on. I'm thinking of writing a posting summarising, and perhaps comparing, the types of single sign-on I'm aware of. Maybe more, later...

(2007-08-31 09:44:48.0) Permalink Comments [0]