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…

Canada needs to seize the green energy opportunity

The world’s Information and Communications Technology (ICT) sector is in need of a green energy provider, and, according to Mohamed Cheriet, spokesperson for the GreenStar Network (GSN) project, that’s where Canada has the potential to make its mark.

Cheriet, a Professor in the Department of Synchromedia at the École de technologie supérieure in Montreal, gave an overview of the GSN project at the CANARIE Annual General Meeting (AGM) held on Tuesday, June 21. The virtual AGM was videoconferenced across four sites using CANARIE’s advanced network and the GSN. Cybera’s Calgary facility was one of the broadcast locations, joining Montreal, Ottawa and Vancouver.

Cheriet showed a map plotting 2,000 datacentres in the world. Of those, he said that half are based in the United States (US), 57 in Canada, and the rest are spread around the world. These centres are one of the ICT sector’s largest energy consumers. As more and more research organizations, institutions and businesses of all sizes turn to cloud, virtualization and remote storage as data solutions, the reliance on ICT — and the amount of greenhouse gases this sector produces — is expected to grow. Currently, Cheriet noted, the ICT industry in the US accounts for 8% of its national power consumption. The carbon dioxide produced from that energy consumption is growing by at least 6% per year.

This is where Canada and the GSN come in.

The Calgary-based GreenStar Network node is operated by Cybera and powered by eight solar panels located on the roof of the Alastair Ross Technology Centre.

As we’ve already noted in past blogs, the GSN project draws renewable energy from five nodes across Canada. Cybera is a local partner in the project, operating the Calgary solar-powered node located on the roof of the Alastair Ross Technology Centre (pictured at right). With a global reach in mind, the GSN project has expanded overseas to host nodes in Ireland, the Netherlands, Belgium, Iceland, and Spain. A Memorandum of Understanding has also been signed with partners in China, and one with Egypt is in the works.

Cheriet says Canada offers unique advantages which make it an ideal green energy producer. The country’s expanding investment into hydro, wind and solar resources means energy can be provisioned at a low price. Access to high-speed optical network infrastructure (such as that provided by CANARIE) enables high-performance connections with major content providers, allowing for large-scale research projects and leading-edge network-enabled platforms. This has also set the stage for the GSN project to experiment with key areas of ICT operation and management technology, namely virtualization, cloud management, carbon monitoring and energy optimization. The next step, argues Cheriet, is to continue rallying and building government and industry support for adopting green IT and green energy platforms.

CANARIE, a major funder of the project, is on board with GSN’s vision.
“If we can become a leader in green IT, it creates economic advantages for all Canadians,” said Mark Roman, CANARIE President and CEO.

As CANARIE begins its mandate renewal process, the GSN is one of many funded projects that demonstrate CANARIE’s impact on advancing Canada’s digital economy strategy. Both Roman and Mark Whitmore, Chair of CANARIE’s Board of Directors, highlighted the following as priority areas for the organization’s mandate renewal:

  • reach out to more Canadian users and enhance international collaborations
  • incorporate emerging technologies such as cloud and wireless
  • spearhead economic development and job creation

Strong collaborations remain a cornerstone to these plans, Whitmore noted, and CANARIE will continue to develop and support partnerships in Canada’s research, education and industry sectors.

So what does the upcoming year look like for you? Is green energy or some form of green IT on the horizon for your organization? Are you using Cybera’s or CANARIE’s advanced network for a project or pilot? We want to hear about it. Leave your comments below!