One of the key puzzle pieces for federated ID is how to deal with sign on outside the browser. When you peek behind the curtain of the web you will see tools like SSH and SCP and jobs running on machines pushing content everywhere and people signing in to accomplish tasks ill suited for the web. In other areas you’ll see people wanting to use their ID to sign into a cloud application on their smartphone (like mail) or a specialized application on their desktop (think Google Earth).
We want to mask some of the complexity of using a Federated ID behind the curtain as much as we can and only reveal what is REALLY needed to get the job done. In this posting we’ll be exploring two candidate technologies to do this.
WARNING! Some technical content ahead! Ok, this posting may be a bit of a technical read, but I’ve tried to keep the acronyms to a minimum. I am also assuming that you know a bit about Single Sign On techniques and have slightly more than a passing familiarity with Shibboleth and SAML.
So put on your gear for something beyond a shallow dive, but not the full deep dive it could be, I don’t think you’ll get the bends but if the comments drag us into that territory don’t blame me 🙂
We are going to take a look at two approaches to non web sign on; Shibboleth with the ECP (Enhanced Client or Proxy) plugin and the IETF’s ABFAB (Application Bridging for Federated Access Beyond web) that was formally known as Project Moonshot. Both techniques have their merits and drawbacks. I hope that by offering this comparison I can help identify some of the things to think about and hear back from others about how on target (or not) I am with the analysis.
Non Web Federated ID Use Cases
Use cases take the shape of many things:
- IMAP mail access for your smartphone
- plain SSH/SFTP for secure shell access
- A rich or ‘fat’ client that leverages local graphic and compute capabilities.
- Insert your clever outside the browser use of id/passwords.
Use Case: Mail in the Cloud
This is/was slide 51 from the Live@edu slide deck from one of their TechNet in late 2010 (credit: Microsoft). It illustrates the use of the Microsoft Federation Gateway communicating with Shib ECP for authentication. The end users offers their userid scoped with their domain (e.g. email@example.com) and the ‘hint’ of the domain allows the gateway component to direct the authentication request to the appropriate ECP enabled interface. This hint is not part of the SAML protocol at all, but a function of how the cloud service provider will route the request it receives to the right provider. The password DOES transit the cloud so it is up to the Identity Provider to have sufficient assurance from the vendor that the right steps are taken (e.g. IMAPS, safe transit within the cloud etc).
The reply by the Shibboleth IdP via a reverse SOAP call (PAOS, yes soap written in reverse) and carries a special identifier for the Live@EDU service: PersistentID. This value is special to the cloud mail service as it links the person to their mailbox. My understanding from IdPs participating in this space is that the PersistentID is generated upon account creation in the institutions person registry.It is just an attribute passed over the wire instead of a dynamically computed attribute like eduPersonTargetedID. It is also BASE32 encoded which eduPersonTargetID is not.
Use Case: Federation Aware Rich Desktop Client
Screenshots of some of the OpenJump documentation that uses SAML. OpenJump deals with the discovery issue by having you as the user enter the Metadata URL into the actual application. Good? Bad? Well, you judge, but if you say bad, help us understand how you would do it to minimize the user managed discovery aspect? Hand waves don’t cut it, please be specific…
Key Considerations – Tipping Point Concerns
You can argue that we need to look at many facets of the conversation, but I contend that there exists tipping point ones you need to pay attention to and are the key drivers — these are ‘the who’ and ‘the what’. Once you wrestle those to the ground, the rest will follow when going through a comparison on what to use in your situation.
‘The who’ is your audience of users and the important question to ask about them is ‘How diverse a group are they?’ If you can influence/control the diversity as in keep them all originating from the same bucket, then this may work to your advantage — more on this in a moment. If you can’t and are talking about a diverse set of users originating from many identity providers then this is important too. In either case, there will always be an identity provider of last resort to capture the corner cases and our goal is to minimize this set as much as possible.
‘The what’ is what are you trying to deliver or improve? Are you trying to allow a smartphone or tablet access to their email or are you trying to allow SSH/SFTP access to unix boxen under your control? Are you trying to do both? Your endpoints you want to serve are going to influence your selection.
Comparing and Contrasting
The table below highlights some of the comparison points to be considered:
||Userid/Password pair seen & transits outside classic Shibboleth infrastructure boundaries
||Userid/Password seen @ endpoint & transits through RADIUS infrastructure via SSL tunnel
|Home Institution Discovery
||Somehow preconfigured either via user or by static configuration in proxy & proxy under an infrastructure providers control
||Userid contains hint to institution so it is present in credential and implicitly discoverable on usage
||Exchanged via SAML2, aggregated via standard Shibboleth fashion (DB/LDAP/static values etc)
||Exposed via GSS API, delivered via RADIUS pack/unpack technique, aggregated from many potential sources
|‘Breadth’ of accounts
||ECP configuration or end user intervention drives breadth of coverage
||If RADIUS uses eduroam, entire set of federation accounts are available
|Environment Used in
||Mobile devices, IMAP clients, very targeted and controlled infrastructures. Unix machines with a preconfigured Id Provider.
||Unix shell environments, rich clients, anywhere that the GSS-API exists.
There are more, but to me these are the big ones. I’m sure there are readers out there that have thoughts, so please share them and I’ll see if they fit in.
If you were looking for me to declare one method over the other, I’m sorry to disappoint — the answer is of course it depends. It will depend on how you respond to ‘the who’ and ‘the what’ and then feed that into the calculation of Total Cost of Ownership (TCO) of the approach you choose.
Some of these things are going to be intangibles too, like ‘are you staffed with the right skills?’ and ‘how many calls to the helpdesk can you avoid?’. I think anyone going through the decision process on deploying one or the other or even both needs to think about the big picture topics.
I accept that this comparison is incomplete but I believe it to be complete enough for the purpose of kick starting a dialog about it. I look forward to the comments and emails to see how well my position holds…