Thursday Sep 22, 2005

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 product !!! 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 :-)

Tuesday Jun 21, 2005

First Multi-Protocol Federated Identity Interoperability Demonstration

The Burton Group is organizing a demonstration of multi-protocol federated identity at its Catalyst conference in San Diego next month. We will be showing Access Manager acting as a multi-protocol identity provider hub. That is, Access Manager will be enabling single sign-on between a set of service providers, each of which will be supplied by a different vendor, supporting a different federation protocol:

To keep things simple in the diagram, I haven't shown any back-channels between the identity provider and the service providers.
So, no matter which provider the user visits first, he will be redirected to authenticate at the identity provider. Now the user can visit any of the service providers without further authentication, despite the fact that they are all using different federation protocols. Cool!

Saturday May 14, 2005

Sun/Microsoft Press Conference

Well - it's done. I've been involved in the web single sign-on interoperability work with Microsoft since the beginning of the year - four and a half months of painstaking specification work, designing a demo, going on vacation while the real engineers built the demo (BIG kudos to Emily for the protocol work and Lauren for the web pages on our side, Ryan on the MS side - the demo worked flawlessly and looked great!) then a final flurry of work on the demo script and rehearsals for the big day.
Watch the webcast - I'm presenting the demo with Don Schmidt of Microsoft. There's a press release (if that's your sort of thing) and a factsheet. The actual specs are online at Sun and Microsoft. I'm not going to repeat any of that here. I will say that it is somewhat nerve-wracking giving a live presentation just 6 feet from Steve Ballmer and Scott McNealy! AND - there is no truth in the rumour that I am Steve Ballmer's 'good twin'...
I've read blogs and comments that represent this as Sun moving from open to proprietary standards. This is emphatically not the case. The big news, as I see it, is that customers now have a way to implement SSO with the upcoming Active Directory Federation Services that would otherwise not exist. These specifications are published and will be submitted to a standards process, so other identity management vendors can implement them or not as they see fit.

Monday Apr 18, 2005

Live from Dublin at the Liberty eGovernment Forum

I'm in Dublin today at Liberty's eGovernment Forum, demonstrating Access Manager to government delegates from across Europe - so far I've spoken to one German, two French, a Finn, a smattering of Irish and even a Brit. Here is a very boring picture of the demo display - it's a small room with 6 vendors, so laptops all round.
Apologies for the poor picture quality - it was taken with my Sony Clie PDA (no flash) in quite low light. I'll post better pictures as they become available. The sign in the middle reads "Sun Microsystems - Live with Liberty".
Anyway, the machine on the right is showing a very interesting demo involving Liberty's ID-FF, ID-WSF and ID-SIS specifications. The scenario is that a civil servant in one government department can access resources across other departments without having to authenticate to each department in turn. Further, our civil servant's personal data (such as mailing address) is only stored in his 'home' department (the identity provider), so if another department wants to, say, send a copy of a report by mail, they use Liberty's Discovery Service to find the Personal Profile (PP) Service and query the PP service for the civil servant's mailing address. The Interaction Service allows the 'home' department to confirm the release of this data before responding.
Believe me, it is all much more seamless than it sounds. So much so that sometimes I have to back up and explain why this is clever and how you'd have to do it in the absence of Liberty - either syncing a bunch of data around all the govt departments or having our civil servant type his mailing address again and again.

Tuesday Mar 29, 2005

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.

Wednesday Mar 09, 2005

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.

Wednesday Feb 02, 2005

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.



« July 2016