My OkCupid! Politics Test Result

Picked this up from Don Park, via the Planet Identity aggregator. Slightly apprehensive posting this, I have to say… If you don’t see another entry, you’ll know the black helicopters visited the Patterson household…

You are a

Social Liberal
(80% permissive)

and an…

Economic Liberal
(18% permissive)

You are best described as a:

Socialist

Link: The Politics Test on Ok Cupid

The ‘famous people’ version of the chart places me somewhere between Hilary Rodham Clinton and Mahatma Gandhi:

Interesting…

Mark Dixon on the Identity Grid

Mark Dixon posts today on the Identity Grid. I have to say right now, I am just completely impressed with the quality and frequency of Mark’s posts. I’ll also confess that, when the Waveset folks arrived at Sun nearly two years ago, and most of us saw the Identity Grid for the first time, some of us (myself included) rolled our eyes – it just looked like window dressing – eye candy. But I’ve lost count of the number of times I’ve used it since as an organizing framework for our Identity Management products.
Well – Mark brings the ‘Grid up to date in this post. There’s a lot to like here – particularly the emphasis on services rather than servers and stores. I was chatting with the Wizard of IdM, Don Bowen tonight (Don – it’s been far too long since your last post!), and, as he says “there’s smarts in them there data services”. Okay – he didn’t say it like that, but that was the sentiment. :-)
Anyway – they’re not just identity data stores anymore – there’s synchronization down there, virtualization, replication. The move from identity data stores to identity data services is like the move from flat files to database tables – sure, you can store 10 million order records in a flat file, but the world has moved on. We’re now at a position where a standard interface – LDAP – abstracts away an infrastructure that includes fault tolerance, load balancing, synchronization. Yup – directory servers are a commodity, just like file systems. The game has changed.

Emergent Effects in Identity Federation – a useful analogy

Very interesting entry at POSIWID (POSIWID = ‘the purpose of the system is what it does’) today about the effects of systems such as the panopticon and the Liberty Alliance Project. I think it’s a little premature to look for the effects of identity federation on users’ behaviour, but a very useful analogy for identity federation occurred to me this morning. I mentioned it in the last entry, but I think it’s worth expanding on it here…
Online bill pay is widespread now. You can log in to your bank’s website, set up bill payees and then setup one-time or recurring payments. This is very like identity federation:

Bank Identity Provider
Online banking credentials IdP credentials
Utility (e.g. cellphone co) Service Provider
Utility account details Name identifier – links SP account to IdP account
Bill payment Single sign-on

Now, all of your payee account details are typically visible in the online banking system. If your bank account login is compromised, then the attacker gets all your account numbers and can go and do bad things like cancel your phone service, assuming he has any additional credentials required (typically SSN). However, if an attacker (e.g. an insider at the phone company) learns one of your utility account credentials, the remainder are safe, as is your bank account. You trust your bank with all the account numbers – after all, they have all your money, anyway :-) – and get the convenience of online bill pay.
This is precisely analagous to identity federation as implemented in Liberty and SAML 2.0. You (the principal) have an account at the Identity Provider (IdP), and associated accounts at some set of Service Providers (SPs). The IdP has a name identifier to each SP account – each of which is unique for a given principal, in the same way as your cellphone account number is different from your electricity account number. If you trust the IdP, then the convenience of single sign-on (SSO) makes it worthwhile to link IdP and SP accounts. In fact, in a way, identity federation is ‘safer’, since the name identifier has no meaning outside SSO. You can’t use it to try to manually login to the SP, for example.
Now, returning to the question of effects. What has been the effect of online bill pay? Well, I believe (and I have nothing to back this up, so don’t ask!) that it is a classic technology adoption curve. You have your early adopters, who are quick to jump on any new technology in order to realise the benefits asap. Then you have the mass market, who will adopt when they see that the tech is working, and the early adopters have (usually unwittingly) worked the bugs out of the system. Finally, there are the skeptics, who are going to continue mailing checks, no matter what. So, an increasingly large number of people save money on stamps, and the banks save money by not processing paper checks.
It will be useful to watch identity federation as it continues along the adoption curve… POSIWID is a useful lens through which to observe systems.

What is Federation?

Rohan Pinto has posted an entry today entitled ‘DE-Federated Identity Access (DEAF)‘. This is an interesting post, but Rohan picks up a misconception from Wikipedia, and perpetuates it. I’ll step through Rohan’s post here: (sorry, Rohan – I copied and pasted text, so I don’t have all your links and markup here)

Identity Management, and Identity Federation has been the buzzword in this space for a while now. According to the definition of “Federated Identity” on wikipedia, it has two general meanings:

  • The virtual reunion, or assembled identity of a person’s user information (or principal), stored across multiple distinct identity management systems. Data is joined together by use of the common token, usually the user name.
  • The process of a user’s authentication across multiple IT systems or even organisations.

Wikipedia is just wrong here. Data need not be “joined together by use of the common token, usually the user name.” In fact, the prevailing model for identity federation (SAML 2.0/Liberty ID-FF) explicitly deprecates such a mechanism.
Instead, accounts are linked via pseudonyms. The Identity Provider (IdP) assigns a unique ‘name identifier’ to each Service Provider (SP) account (effectively a foreign key). So, the system can navigate from a user’s IdP account to that user’s SP account and vice versa. However, the system cannot navigate directly from one SP account to another SP account. Neither is there any concept of a ‘master identifier’.
Rohan continues

now, this is great when the Legal Entity has a unique “identity” on each of the disparate systems. But when the Legal Entity who has a identity on a system is provided access to a partner site or system, there is absolutely no “Federation” possible if the Legal Entity has no identity on the partner site or system.

Liberty (and SAML 2.0) defines the concept of one-time federation (I previously blogged about it here). A principal need not have an account at an SP. Instead, the principal can single sign-on (SSO) to the SP, identified only by the SAML assertion passed from the IdP to the SP in the SSO process – a one-time name identifier is used. Now the principal can access resources at the SP according to the information in the SAML assertion – which can include attribute-value pairs such as ‘membership=gold’. If/when the principal re-visits the SP, a new one-time name identifier is user, so no correlation can be made between visits (leaving aside the possibility of cookies from the SP, of course).
Alternatively, if appropriate, the SSO con proceed in the normal manner with a persistent name identifier, and the SP can dynamically create an account.

I was involved in a brainstorming session related to shibboleth with a few technical folks from a university. What came up was the need to allow students from one university to access resources from another university. The folks I was interacting with were “sold” on the idea of federation, but lacked complete understanding of how federation really worked.
Here were my concerns:

  • The user needed to have a unique identity on either systems.
  • The user needs to explicitly “federate” his identity. (If he does have a unique identity on each system)

Liberty/SAML do not explicitly define an offline ‘batch’ or ‘bulk’ federation mechanism, but one is possible, if you have an existing correlation between accounts – you can do the name identifier assignment and linking in a script for those accounts which you’re 100% confident you have a correlation, and let the remaining principals create their own account link.

  • If the users identity gets stolen, well, we have a much bigger issue.

Well – yes – if the user’s IdP identity is stolen, then all of the SP accounts are vulnerable. However, if the user’s SP identity is stolen, that cannot be leveraged into a wider compromise. An analogous situation exists for online banking with bill pay. You need to set up your account numbers for each payee – cellphone, leccy, etc in your bank account’s online bill pay system. Now, if someone steals a utility account – say your cellphone – your bank account and other utilities are safe. However, if someone steals your bank account identity, then all your other accounts are at risk, since online bill pay typically allows you to see the account details for each payee.

(I thought) What the university really needed was implicit Federation. Whereby when a user who has authenticated himself at one university, when provided access to resources in another, should be granted access even thought the user does not have a unique identity at the other.

This is precisely what Shibboleth does, and what Liberty and SAML 2.0 can do with one-time federation.

Here‘s an example:

  1. University1 and University2 belong to a “defined” Circle of Trust.
  2. Student at University1 authenticates at University1.
  3. Student tries to access resources at University2.
  4. University2 Requests University1 to assert the validity of the user session.
  5. University1 Asserts that the user is “A“ authenticated user, but does not actually reveal the users “handle“ or “identity” in any form
  6. University2 grants the user access by just knowing that the user is a “authenticated” user at University1, without even knowing who the user actually is. (University2 provides just generic content to the user)

Yup – so far, this is all supported, out-of-the-box, by Sun Java System Federation Manager, Sun Java System Access Manager, and most other Liberty/SAML 2.0 compliant products.

  1. User tries to personalize his “content“ or University2 needs to provide the User “specific” content based on role the student has at University1
    • University2 would need to prompt the user for “permissions” to derive his “role” from UnIversity1
    • User grants permissions by using a digital signature of some sort.
    • University2 uses that digital signature to request University1 for the Users roles
    • University1 verifies that the digital signature matches that of the Authenticated User and grants University2 the users roles and/or “identity/alias”.
    • University2 provisions a local “identity/alias” and associates it with the “role” as asserted by University1
  2. University2 can now allow the user to “personalize “content” or provide the user “content” as necessary.

This is the dynamic account creation I mentioned above. IIRC, you can get most of this working by simply configuring dynamic account creation in Access Manager – users who successfully authenticate have a new account created in the SP.

I believe that with this aproach, even though a student has no “identity” on one system or university (University2 in the example I used) he/She still gets to experience the “magic” of “federation”.

Right – and that’s why the designers of Liberty built it into the system :-)

On second thoughts, If I apply this to the examples widely used in “federation”, where a airliner and a car rental company are in a circle of trust, well, I am sure that the car rental company would love to receive a new unidentified user from a “partner airline” and dynamically provision the user and sell him a pr
oduct !!! it‘s all about making money in the bargain right ? or is it just making the user experience more enjoyable and easy ?
I believe that we‘d be kidding ourselves if we say that it‘s ONLY about “user experience“
Now: The user providing his/her “digital signature” to the car rental company is another story altogether.. ;-)

Heh – some assembly required…

Comment Away Please…

Consider this a comment :-)

Web Services: Where Identity Management Goes From Here

Thanks to Dave Kearns’ IdM News page for the pointer to an interview with Trustgenix‘s Atul Tulshibagwale on the subject of Identity Web Services standards and specifications. Atul gives a good high level overview of SAML, Liberty and WS-Federation. One interesting comparison he draws is between the technology-consumer focus of Liberty and the vendor-centric approach of WS-* – I guess SAML falls somewhere in the middle. Having participated in Liberty’s Technical Expert Group, the presence of tech-consumer companies such as AOL and France Telecom (just the first two names that spring to mind) provides an essential counterbalance to the likes of ourselves and IBM. For me, this is what gives the Liberty Alliance Project its unique relevance.