Dispatches from REFEDS and VAMP2012

Good morning from Utrecht, NL where I am attending as CANARIE’s CAF representative for REFEDS & VAMP2012

I’ve found that this September is an inflection point for change; back to school kicks in, summer holidays recharge the batteries and give a chance to step back and take stock. To this end, I’m going to experiment with a  more brief communication model with this blog.  There may be the occasional essay like post because complicated topics need their due depth, but I would rather have more frequent postings to avoid the TL;DR (Too Long; Didn’t read) and see which ones to go deep on as people express an interest in them.


Research and Education FEDerations is one of the few locations dedicated to the interests of  CAF and our peers.  It is also a forum for advancing Federated Identity topics and collaborating on workplans to the benefit of multiple federations.  One topic that has been incubating in the REFEDS environment are recommendations for Service Providers for Federated ID sign on and discovery which are based in part on a NISO Espresso Report.  An interested and comprehensive document at 35 pages. More to come on this front soon.

As the REFEDS meeting progresses more will be posted to this blog entry.

In the mean time, I would like to point you to the 2 day VAMP2012 agenda and encourage you to post comments or questions that you would like to hear me bring forward.

Browserless Federated SignOn Techniques Contrasted: Shibboleth/ECP and ABFAB/Moonshot

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 🙂

The Contenders

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. joe@my-university.ca) 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

‘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

‘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:

Shibboleth+ECP Moonshot/ABFAB
Password Treatment 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
(e.g. <id>@realm.ca)
Attribute Exchange 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.

Conclusions…for now

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…