Is Liberty Panoptical?

Dr Stefan Brands, of Credentica and McGill University, recently asserted that Liberty is ‘ panoptical‘. I questioned the applicability of this description, and Stefan kindly blogged an explanation. Stefan makes a number of good points, and I’d like to respond to some of them here.

Specifically, in Liberty Alliance the Identity Provider knows all the user aliases with the different service providers, and is involved in real time whenever the user connects with a service provider. As such, it knows exactly which user is talking with what service provider at what moment, can cross-profile all the actions of the user across the entire circle of trust.

It is true that the identity provider (IdP) knows all the user aliases, but the IdP need not necessarily be involved in every user contact with a service provider (SP). The user can still authenticate at the SP independently of the IdP. The user’s account still exists there, it has merely been linked to the account at the IdP. The benefit in convenience of single sign-on has a cost in privacy that the IdP knows you are visiting the SP.
Further, the IdP has no idea what the user is doing at the SP – it merely knows that the user went there at a particular time.

Which of the following two distributed identity architectures is more privacy-invasive and prone to identity theft? One in which each user uses a single identifier for all service providers that he or she interacts with; or one in which a new central party is created that doles out different aliases for users for use with different service providers, and that is involved in real time in all the interactions between users and service providers in order to reconcile between user aliases and their “real” identities.

In every use case and real-world implementation I have seen so far, the identity provider is an existing organization that already has the users’ data – wireless operators, employers, airlines etc. No ‘new central party’ is required or proposed. There can and will be multiple circles of trust, not just one great identity provider in the sky.

There is no reason why the User should inherently have more trust in the Identity Provider than in individual service providers…

Well, the specs obviously do not mandate this, but the reality is that identity providers are and will be organizations that users necessarily trust to some extent. And that trust will have to be earned and maintained lest users take their business elsewhere.

Ultimately, it all depends on who the user trusts with what.

I couldn’t agree more. I trust my employer with a lot of my personal information, and I would be happy for Sun Microsystems to act as an identity provider when I, for instance, access my 401(k) account or my health benefits, since they are linked to my employment. However, there is no reason for Sun to be my identity provider outside a work context. Depending on the setting, I might choose my bank, my ISP or my wireless operator. Or I might choose to forego the convenience of single sign-on and just authenticate directly to

Indeed, a sceptic might argue that the only party that genuinely benefits from the use of SAML 2.0/Liberty Alliance “pseudonyms” is not the user, but the Identity Provider: by preventing service providers from all getting to know the user under the same unambiguous name, service providers cannot engage in any user-related data sharing other than by going through the Identity Provider.

Separate pseudonyms per service provider are not mandated by Liberty, although it does obviously allow them and they are attractive from the identity provider’s point of view, for the reasons Stefan mentions.
Liberty’s Identity Web Services Framework (ID-WSF) does indeed allow service providers to exchange data directly. The identity provider is instrumental in allowing those services to find each other via the discovery service, but has no knowledge of the details of their interaction. For example, my airline (SP) can ask my employer (IdP) where my preferred car rental agency (another SP) is. My employer verifies with me that it is ok to share this information, and then the airline can interact directly with the car rental firm without the IdP being involved.

Again, from the privacy perspective of the user it is not clear at all that forcing all data transfers to go through a central choke point (even if encrypted) is truly a privacy or even security improvement over allowing direct transfers between service providers; which, once more, ties into the fact that users have only make-believe power to decide which data transfers about them are enabled and which spheres of activity remain segmented.

I’m not sure why the user’s power is make-believe. Assuming that the user trusts that the IdP will act on his instructions, the user can link and unlink accounts at will. And, as I mentioned above, if I don’t want to use single sign-on into a given service provider, I can just login directly.

…the identity provider (whether its insiders or hackers and viruses that gain insider status) can arbitrarily deny access in real time to a user on a selective basis and can arbitrarily impersonate that user – across the entire circle of trust.

Ah – the most apocalyptic version of this point. The identity provider has no powers of denial of service whatsoever. The user is always free to just login directly to whichever service provider he likes, without the identity provider being in the loop at all.
Further, we can assume some sort of trust agreement between the IdP and the SP. If the SP does not trust the IdP, then the SP should not simply open its vault upon reception of an authentication response from the IdP.
As an aside, one interesting feature of Liberty and similar protocols that we are starting to see in the real-world is that users can access services at SPs without actually identifying themselves to the SP. For example, I could access a wireless horoscope service. The horoscope provider doesn’t care who I am, just that I am a paying subscriber of my wireless operator (the IdP) and my birthday is July 7th, which information I have explicitly directed the IdP to share with the SP. Is my privacy enhanced or reduced here? Sure, the wireless operator knows that I visit the horoscope service every day, but it knows that anyway, since it is in a position to monitor all my wireless internet traffic. But in this instance, the horoscope provider has no idea who I am.
Finally, the Liberty Alliance’s door is always open to new members – any organization or individual can directly
represent their point of view in the working groups and sponsors’ meetings.

Sun Java System Access Manager Federation-Enables Windows Logon

Nice to see Ping Identity catching up with functionality that Access Manager has provided for a whole year now. Access Manager 6.2 (released in 2004Q2) introduced Windows Logon authentication via SPNEGO tokens over HTTP – the protocol is described by Microsoft here. Access Manager federation-enables all of its authentication modes, from username/password against LDAP through Windows Logon to smartcards and other hardware tokens.
We don’t stop there, either. From the current version (6.3, aka 2005Q1), Access Manager generalises the mechanism to any other platform that can provide a Kerberos ticket via a compliant browser (for example, Mozilla/Firefox), so you can authenticate to the Solaris or Linux desktop and access protected resources wherever they may be.
Beat that, Ping.

It’s Official – SAML 2.0 is now an OASIS Standard

Announced today on the OASIS tc-accounce list. A consolidated zip file with all specifications and schema is publicly available. See the OASIS SAML site for individual PDFs, XSDs, etc.
Briefly, SAML 2.0 unifies the previous disparate federated identity building blocks of SAML 1.1 with input from both higher education’s Shibboleth initiative and the Liberty Alliance’s Identity Federation Framework. There is an executive overview of SAML 2.0 that summarizes what’s new.

XACML vs WS-Policy vs WS-Trust

Interesting post by Joseph Chiusano of Booz Allen Hamilton to the sunxacml-discuss mailing list discussing US Federal Government classification of standards and specifications. Key quote (my links):

XACML would be considered to be a “Voluntary Consensus Standard (VCS)” (aka an “open standard”) according to OMB Circular A-119[1], the authoritative federal mandate on this topic. WS-Policy and WS-Trust, however, would not be considered VCSs.

It is important to understand the difference between a standard and a specification – imho, standards are created in organizations (such as OASIS, W3C and Liberty) whose membership is open to all. Non-standard Specifications on the other hand, are created by consortia of vendors outside standards bodies such as the above. That’s not to denigrate their usefulness in any way, but the difference in process can be significant – open standards level the playing field; in contrast, you can never be sure whether a multi-lateral specification favours the members’ products. In fact, it would be somewhat irrational if it did not.

Firewalls’ False Sense of Security

Opinion piece in Computerworld by Jerrold M. Grochow, vice president for information services and technology at MIT, on the limitations of perimeter security and the importance of authorization – closing quote:

Firewalls can go only so far — at some point, you’ll have to develop a secure identity structure that’s incorporated into each and every application. And projects such as Kerberos, Shibboleth and Liberty will lead the way.

I would add SAML to that list, and note that SAML 2.0 incorporates functionality from both Liberty ID-FF and Shibboleth.

Federated Single Sign-On Shifts GM into High Gear

eWeek is featuring a great article covering General Motors’ ‘MySocrates’ employee portal and its pilot Liberty implementation. GM are using Sun Java System Access Manager as their Liberty identity provider, deploying federated single sign-on to 70,000 of its US-based employees. The pilot implementation provided SSO to GM’s 401(k) provider; GM is now looking at enabling further services using Liberty.
A very telling quote: “While [GM’s director of software technology, John] Jackson estimated the technology should take no longer than two months to deploy, he said legal and business issues may cause the project to take as much as one year to complete.”

The Laws Of Identity

Kim Cameron of Microsoft has written a fascinating piece on ‘The Laws of Identity’. Kim lays out an initial 6 laws (sample: ‘1. The Law of Control: Technical identity systems MUST only reveal information identifying a user with the user’s consent‘) and explores a scenario (originally suggested by Eric Norlin from Ping Identity) where a Polycom conference phone requests your music preferences from your Bluetooth phone. As Eric points out, this is technically possible via the Liberty specifications.

I just discovered Kim’s blog, so I need to do a bit of reading before commenting much more, but, for now, I’ll just point out that Liberty WSF’s interaction service provides the mechanism by which your phone would beep and request your consent before handing over personal data to the Polycom, thus obeying Kim’s first law.

Mobile Operator Federation/Web Services Use Cases

My principal role, since I turned away from the ‘dark side’ of marketing and moved back into engineering, is technical architect for federation standards on Sun’s JavaTM System Access Manager product. This means I get to work with some great technology and, more importantly, some great people. One such person is Fulup Ar Foll; Fulup is another techie, a Breton, and the goto guy for mobile federation/web services.

Fulup and I recently contributed to a joint Nokia/Sun whitepaper on identity federation and web services. The domain is mobile operators, but the paper covers a number of variations on the basic Liberty ‘circle of trust’/’identity provider’/’service provider’ model that can apply to any industry. It’s pretty technical, but essential reading if you want to understand the future of mobile services.

Shameless Self Promotion

Last year, Pirasenna Velandai Thiyagarajan (Piras to his friends) and I co-presented a webinar titled ‘Federated Identity, Access Control, and Single Sign-On’. The webinar covered

  • – the basics of single sign-on and access control in the enterprise
  • – a simple example of SAML cross domain single sign on, with code samples
  • – a more complex example of identity aware web services using the Liberty Web Services Framework (WSF)

If you’re wondering what I sound like, click the link above to find out.

Piras and I later teamed up with Marina Sum to write a technical article on the same topic.

These are great resources for anyone getting to grips with SSO and federation – but then, I would say that, wouldn’t I 🙂

Look out for another technical article later this year, showing step-by-step how WSF can identity-enable a simple web service.