So you’re throwing a party! And in this case, it’s a Relying Party, or as we like to call them in the Higher Education world, a Service Provider. For the sake of broader audience appeal, and to make my whole “party” analogy work, I’ll stick with “Relying Party” in this post.
The goal of this article is to help people running Relying Parties throw the best bash possible when inviting social identities along.
Let’s start with the most important party planning question? Not food. Not booze. Not music. But...
Who are you going to invite?
There are lots of questions to consider, like how many people to invite, what they should bring, what they should wear, and how you get them to leave. Let’s explore each for a bit.
How many people do you want to invite?
Do you want to let anyone with a social identity walk into your Relying Party? If you let anyone with a Google, Facebook, Twitter or LinkedIn account log in to your application, you could end up with millions of party crashers!
You might want millions of guests, if all those guests bring the valuable gifts of lots of personal private data you can mine. As a protocol, OAuth2 serves in large part to facilitate data exchange between services, and if you’re a Relying Party that wants lots of data, you’re going to want an open invitation to your party.
But maybe you are a discriminating host, with a select guest list and a bouncer at the door to keep the riff raff out. In that case, you will need some mechanism for “inviting” or “registering” only those social identities you want to let in. Writing up a guest list for your Relying Party sounds like way more fun than “user provisioning”, doesn’t it?
Anyhoo, on to the next big question…
What should you ask your guests to bring?
Face it. If all you say is “bring something to share”, lots of people will bring a bag of potato chips (delicious, but not very high value) and a handful of people will bring a nice bottle of wine. And as the host, you appreciate some gifts much more than others. When you host a Relying Party, when a guest brings the gift of a persistent, unique identifier, that’s pretty hard to beat! Sadly, not enough guests bring those, as a quick review of social identity provider attributes will illustrate:
- LinkedIn: LinkedIn asserts unique targeted IDs, but those IDs are tied to the Relying Party’s API key. If the Relying Party needs to modify its API key for any reason, all existing users will come back with new user IDs (see thread on LinkedIn Developer support)
- Facebook: Facebook also asserts a targeted ID. Unlike LinkedIn, you can change the API key used by your Relying Party without remapping all your integrated Facebook identities. But the targeted ID is still per Relying Party, which can introduce challenges if you are trying to share the same Facebook ID across multiple relying parties
- Twitter: Users can change their Twitter handle anytime, so that might not be the gift you’re looking for. But Twitter the API also expose a persistent, unique Twitter ID you might prefer
- Google: Google supports OpenID Connect, an authentication protocol that sits on top of OAuth2. Via OpenID Connect, Google provides a unique, opaque, immutable identifier for users making Google IDs appealing for any Relying Party guestlist
What about other attributes? Name (first and last) might be thought of as the potato chip of Relying Parties. Lots of guests bring them, but they don’t add much to your party.
Then there is email…Email could be just as valuable as persistent unique identifiers depending on the kind of Relying Party you’re throwing. Google, Facebook, LinkedIn, Yahoo, and WindowsLive are all providers that assert email, but you have to be cautious about how you use email if you want to avoid Relying Party fail.
- Google hosts tens of thousands of email domains, so you can’t predict how the asserted email will be scoped
- Facebook asserts email, but users can change it anytime
- WindowsLive asserts email, but as a multi-valued attribute
- Twitter does not assert email
- Yahoo asserts email but has reassigned user email addresses in the past
Having the right guests at your party, and choosing your social identity providers carefully goes a long way toward ensuring maximum Relying Party fun. But there’s more!
Is this a costume party?
Of course! Every Relying Party is really a costume party, because every guest who attends is not real, but rather the digital representation of someone (or something) who might be real, but you just don’t know…
What is really behind that digital identity mask? A nice person? A malicious one? Is it someone you trust? Or at least the friend of someone you trust? Is it a person at all? Do you allow “things” into your party (you know the Internet is full of things these days)?
Different Relying Parties will have widely differing preferences when it comes to knowing what is behind the mask, that is, what Level of Assurance you have that the guest is who (or what) they say they are. Some Relying Parties will want as many guests as possible, and bringing those juicy attribute gifts every time they show up. Other Relying Parties will require an ID check at the door (maybe some knowledge-based authentication using data held internal to the Relying Party and known only to the user). Some Relying Parties might only allow people on a pre-determined guest list, while other Relying Parties might allow those pre-determined guests to bring a +1, like when an enterprise employee “invites” or “sponsors” the Google ID of a contractor to an enterprise system, or when a student invites the LinkedIn ID of his her parent to the university billing system.
Identity verification and sponsorship from an existing enterprise account holder are two ways to increase the Level of Assurance for social identities, thereby reducing some of the risk of inviting “costumed” guests to our Relying Parties. But what about the guest who keeps leaving and coming back in a different costume? What if you have a nice party bag for all your guests, but there are only enough for each guest to take one? How can you know you’re dealing with the same guest when they show up with their Twitter mask on one minute, and then minutes later they reappear wearing their Google mask?
In situations like these, an account-linking service would come in handy. A check-in table of sorts, where one guest can register multiple identities, but always get the same name badge before they walk in the door. This “pre-screening” makes your life as a Relying Party host a lot easier (how many times have I heard higher ed IT Identity Management leads say “we just don’t want Service Provider admins to have to think about it”), but it requires that the registration desk, or account linking service, be staffed at all times by people who don’t screw up the data, or else that “simple integration” you are trying to achieve will become a party disaster.
You will have to do even more pre-screening if you are running a gateway service that talks to lots of Relying Parties. The social providers have no consistent way to describe the attributes they release. For first name alone, you will get the following from different social providers:
- Google: given_name
- Facebook: first_name
- LinkedIn: firstName
The Relying Parties sitting behind your gateway will cry party foul unless you come up with some consistent mapping for attributes that mean the same thing but are labelled differently across the providers. With input from our customers, Cirrus Identity has established a mapping of social identity provider to SAML attributes leveraging the eduPerson schema developed by Internet2’s Middleware Architecture Committee for Education.
Phew! I don’t know about you, but I think it’s about time for this party to end. Which brings us to one final question…
How do you get people to leave?
Of course your party is fabulous, and sometimes people won’t leave unless you insist upon it. How do you decide when to kick them out? Do you give them a time limit (guest accounts expire after 6 months? One year?). Do you kick them out for rowdy behavior, like if a guest using a social ID violates your enterprise terms and conditions? Does that mean you need to have your guests agree to terms and conditions when they show up? Do you kick your guests out after a certain period of inactivity (the dude who passes out on the couch is just annoying and takes up space). Do you require that guests leave when their “sponsor” leaves?
These are all important questions to consider if you don’t want your Relying Party to be ruined by guests who break things or overstay their welcome.
Clearly throwing a badass party is a serious undertaking, and the more thoughtful the host is about the guest list, the gifts, the costumes, and the closing, the more badass the party will be. I hope this article has provided helpful tips for inviting social identities to your Relying Party. Now go throw an amazing bash!
-Dedra