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. 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>
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…

About Chris Phillips
Technical Architect for CANARIE specializing in the Canadian Access Federation. I get to deal with the hard stuff that matters to Canada at large and it's an exciting space to be in. Identity management, SAML2, eduroam, LDAP, directories, schema design and other emerging technologies are my specialties. Who needs sudokus when you have all these to play and work with during the day?

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

  1. Scott Cantor says:

    I wouldn’t use the Live example of ECP as a particularly great illustration of the trade-offs, in particular because their model assumes the password is visible to the RP (via a proxy), which is anathema to federation.

    Other points: any discovery mechanism Moonshot can use is likely usable with ECP as well. I simply dispute the viability of the email-as-discovery approach depending on your user base.

    Lastly, the direct analogy between ABFAB and ECP is the SAML ECP GSS-API mechanism I drafted. That’s usable in any scenario in which ABFAB would be. The base ECP model is HTTP only.

  2. Chris Phillips says:

    Thanks for the feedback Scott.
    yes, the Live@EDU is not the prettiest, but it is in use. If you have recommendations or can point me to others that can be used, I’m all ears…

    About Moonshot, it’s not email, it’s @, which yes, can look like email…and yes, will cause some grief…but is it a tolerable amount? In eduroam, yes…

    Anyone take the draft and put something into practice? I concur about the SAML/ECP/GSS-API piece, but I’m trying to identify what is ‘in play’ vs on the drawing board.

    I’m game to continue the thread here if that works. I just poked at the Kitten reference which recently expired which sounds like the SAML/ECP/GSS-API item right?

  3. Scott Cantor says:

    I believe Scott Koranda among others has been rolling out something based on ECP directly.

    I know it’s not an email address, but in practice that’s what users understand. I think it will cause much more grief outside of eduroam, because there’s not necessarily a provisioning step that can explain to the user what the ID is supposed to be.

    Regardless, it is not a differentiator. If it works, it works with everything. If it doesn’t, both are in need of something else.

    The Kitten document isn’t expired, there was a WG draft posted very recently.

  4. Pingback: Confluence: AAA Study

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: