Monday Aug 14, 2006

Nice To Be Considered an 'Industry Expert' on Federated Identity...

...even if it's qualified by 'so-called' and my cluefulness is called into question

James McGovern asks

when was the last time he [Pat Patterson of Sun] asked members of Project Liberty to start sharing pain points outside of the Project Liberty forum for others to consume and learn from?

Well - that's precisely what many members of Project Liberty recently did in the recent Identity Open Space in Vancouver. As its name suggests, this event was open to all-comers and jointly produced by the Liberty Alliance Project and some of the leading participants in the Internet Identity Workshop. We had some fascinating discussions, mostly documented (to greater or lesser extent) in the wiki.

Another interesting aspect of this event was that (as I blogged previously) IOS attendees were able to also attend Liberty's plenary sessions (under NDA), observing and even contributing to the discussion. My understanding (and no warranty, express or implied, is attached to this statement) is that the Liberty folks were very happy with the way this all turned out and keen to repeat it regularly in the future.

In the meantime, there will be another IOS next month in Santa Clara. Although this IOS is in association with the Digital ID World Conference, I wouldn't be surprised to see many of the Liberty folks there.

See you there, James?

Tuesday Jun 20, 2006

Liberty and WS-Federation

James McGovern directed this question to me in a recent blog entry:

Pat Patterson, what would it take for you to get Liberty Alliance to embrace the WS-Federation specification? Having federation capabilities built directly into an operating system is liberating...

I'm not sure what James means, exactly, by 'embrace', but here is an answer to a more precise question - could you mix-and-match WS-Federation with the Liberty Alliance Project's Identity Web Services Framework (ID-WSF)?

Well, Liberty got out of the SSO business some time ago, contributing ID-FF to OASIS for inclusion in SAML 2.0. Liberty's technical focus is now on Web services, strong authentication and such.

ID-WSF is independent of the actual SSO mechanism - the dependency is on the token, or, more precisely, the token carrying specific information. ID-WSF 1.1 can use SAML 1.1 tokens, ID-WSF 2.0 will be able to use both SAML 2.0 and SAML 1.1 tokens.

WS-Federation's USP is that it abstracts the token away from the SSO mechanism - a WS-Federation SSO can carry any token you like - SAML 1.1, SAML 2.0, Kerberos, whatever.

So, you can bootstrap from WS-Federation to ID-WSF if you obtain a suitable SAML token via WS-Fed SSO. Section 4 of the draft ID-WSF 2.0 Discovery Service specification defines SAML 2.0 and SAML 1.x Attributes that carry the Discovery Service endpoint reference (EPR). For example, here is a SAML 2.0 <AttributeStatement> containing a Discovery Service EPR:

<AttributeStatement
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
  <Attribute Name="urn:liberty:disco:2005-11:DiscoveryEPR" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
    <AttributeValue>
      <wsa:EndpointReference>
        <wsa:Address>https://example.com/disco/</wsa:Address>
        <wsa:Metadata>
          <Abstract>
            The Principal’s Discovery Service Resource
          </Abstract>
          <ServiceType>urn:liberty:disco:2005-11</ServiceType>
          <ProviderID>http://example.com/</ProviderID>
          <SecurityContext>
            <SecurityMechID>urn:liberty:security:2005-02:TLS:bearer</SecurityMechID>
            <sec:Token ref="..." usage="urn:liberty:security:tokenusage:2005-11:SecurityToken" />
          </SecurityContext>
        </wsa:Metadata>
      </wsa:EndpointReference>
    </AttributeValue>
  </Attribute>
</AttributeStatement>

There are some minor syntactic differences in the SAML 1.x version:

<AttributeStatement
xmlns="urn:oasis:names:tc:SAML:1.0:assertion">
  <Subject>
    <NameIdentifier Format="urn:liberty:iff:nameid:federated">
      d0CQF8elJTDLmzE0
    </NameIdentifier>
  </Subject>
  <Attribute AttributeName="DiscoveryEPR" AttributeNamespace="urn:liberty:disco:2005-11">
    <AttributeValue>
      <wsa:EndpointReference>
        <wsa:Address>https://example.com/disco/</wsa:Address>
        <wsa:Metadata>
          <Abstract>
            The Principal’s Discovery Service Resource
          </Abstract>
          <ServiceType>urn:liberty:disco:2005-11</ServiceType>
          <ProviderID>http://example.com/</ProviderID>
          <SecurityContext>
            <SecurityMechID>urn:liberty:security:2005-02:TLS:bearer</SecurityMechID>
            <sec:Token ref="..." usage="urn:liberty:security:tokenusage:2005-11:SecurityToken" />
          </SecurityContext>
        </wsa:Metadata>
      </wsa:EndpointReference>
    </AttributeValue>
  </Attribute>
</AttributeStatement>

Such an attribute gives you everything you need to invoke the Discovery Service on behalf of a principal - its location (https://example.com/disco/ in the examples above) and a token representing the principal - and it can be carried via WS-Federation just as easily as SAML.

It's up to vendors to make this work. If ADFS can be customized/extended to provide the above SAML attribute in a WS-Federation SSO then other vendors' products can consume it. No further specification or standardization is required, since, again, WS-Federation allows any token as its payload and ID-WSF doesn't care about the SSO mechanism as long as the token carries the Discovery Service EPR.

Which brings us round to the original question - "what would it take for you to get Liberty Alliance to embrace the WS-Federation specification". I believe this is moot, since, as I have shown, SSO is orthogonal to Liberty's current activities. SAML 2.0, WS-Federation, come one, come all.

Finally, yes, I agree - "having federation capabilities built directly into an operating system is liberating" - it would have been even more liberating had Microsoft adopted the federation standard agreed long ago by the rest of the industry and built SAML 2.0 into the operating system. However, we live in the real world and work to satisfy our customers' requirements. You will see WS-Federation support in future versions of our products - in fact, we've already done a PoC showing WS-Federation.

Wednesday Apr 26, 2006

Blogging Live from the Liberty Plenary Meeting, Washington, DC

I'm sitting here in Liberty's Technology Expert Group (TEG) wearing my I'm blogging this t-shirt. One of the TEG co-chairs actually asked if I really was blogging the meeting, given Liberty's rules on confidentiality (themselves freely available in the Liberty Membership Kit).

Well, yes, I am blogging the meeting

I can tell you that Liberty is welcoming a number of new members to their first Plenary meeting, including Fulvens (a small UK consultancy) and Credentica, with whom you may be familiar from earlier postings. We've covered a lot of ground over the past couple of days in TEG, syncing up with Liberty's Strong Auth Expert Group today for an interesting discussion on, uh, strong authentication.

Well - that's about all I can tell you for now. For more, go join Liberty and come meet with us in Vancouver in July.

Tuesday Apr 18, 2006

Project Liberty Adoption Newsletter #1

Following on from last months entry on Liberty Adoption, the good people at the Liberty Alliance Project have published the first in a quarterly series of newsletters on the topic: Liberty Alliance Project Global Adoption Newsletter, Edition One. It's actually a pretty good read, with John Butare and Michael Hatten of Intel's Information Services and Technology Group answering questions on their company's deployment of Liberty, a case study of BIPAC's use of federation (I've written about how BIPAC use Sun's identity management products and the fact that this is Sun's first Liberty deployment previously) and a detailed look at adoption in the eGovernment (e-government? egovernment?) sector. All this and not a telco (or car rental company!) in sight

Thursday Mar 23, 2006

Liberty User-Centric Identity Whitepaper and Webcast

There's a lot of buzz around 'user-centric identity' right now - the notion of involving users in the management of their personal information and its use, rather than leaving it to some enterprise or other organization. The folks at the Liberty Alliance have written a whitepaper entitled 'Personal Identity' that shows how Liberty's Identity Federation Framework (ID-FF) and its successor SAML 2.0 can be used to implement user-centric identity - for example, a user providing their own identity services via a Liberty-enabled device such as a cellphone. It's a good read - it starts from the basics, so you should be able to follow it even if you're new to Liberty and SAML.

On the same topic, John Kemp of Nokia and my esteemed colleague Hubert Le Van Gong will be presenting a webcast on April 12 2006 at 8am Pacific. PLEASE NOTE: Registration is required and limited to the first 100 respondents! The last webcast on the Liberty People Service 'sold out' very quickly, so get in there straight away if you're interested. If you're too late, don't despair - the webcast will be available in archive form after the event. I'll update this entry with the URL once it's online.

To register for the webcast, follow these steps.

  1. Go to http://projectliberty.webex.com
  2. Under the heading Attend a Meeting, click Register
  3. Search for centric
  4. Select User Centric Identity: Success Today and click on the Register Button. (Don't bother clicking on the link - it doesn't lead anywhere useful!)
  5. Fill out the required information and click Register Now at the bottom of the page.

Please email Tricia DeHart of the Liberty Alliance Project with any questions.

Tuesday Jan 24, 2006

Sun Eats Its Own Liberty Dog Food

One question that I'm often asked by customers is "How is Sun using the Liberty Alliance Project specifications?". Well, my stock answer is 'BIPAC'. The Business Industry Political Action Committee provides expert policy analysis, research and communications on campaigns and elections, and fosters business participation in the political process. Sun employees can access political information on the BIPAC website - who their elected representatives are, their voting record etc.

Now, this is obviously sensitive stuff, with huge implications for privacy. The 'old way' of accessing BIPAC would have involved a regular batch process to synchronize identity information from Sun to BIPAC; Sun employees would authenticate at BIPAC with their Sun ID and a BIPAC-specific password. In this old model, BIPAC would know exactly who I was and would be able to build a profile of my activity on the site. Not only that, I'd have another password to write on a post-it note and stick to my monitor remember.

The 'new way' of accessing BIPAC authenticates employees at Sun (using Sun Java System Access Manager) and uses Liberty ID-FF to give employees single sign-on to BIPAC. Now - here's the clever bit - no personal information is transmitted in the single sign-on process. BIPAC have no idea who I am - all they know is that I am an authenticated Sun employee. BIPAC can then use ID-WSF to retrieve a strictly limited set of attributes, including my zip code. So now, all Sun know is that I am a Sun employee in 90210 (well, I can dream). They have everything they need to tell me who my elected representatives are at every level up to Dubya, but no more. They don't know who I am, since they don't need to know who I am. This document gives some more detail on the deployment. Here I am demonstrating the system at a Liberty eGovernment Forum last year in Dublin:

Looking at the wider context, this was an ideal first deployment of Liberty for Sun. A real need for Liberty's privacy features combined with low risk - BIPAC is a valuable service, but not critical to Sun's core business. Watch this space for news as we roll Liberty and SAML out across Sun's other business partners, and, if you're at the RSA Conference next month, be sure to catch Sun's Yvonne Wilson at IMP-101 'Implementing Federated Identity: What Products Do You Need?'. Yvonne is an architect in Sun IT and will be covering our BIPAC integration in her presentation.

Sunday Nov 20, 2005

Demonstration of Identity Web Services

Following on from my recent posting of a Federation Manager demo showing Liberty ID-FF federated single sign-on, here is a demo of Access Manager and Federation Manager I showed at a Liberty 'eGovernment Forum' in Dublin back in April.

This demo shows an employee of the 'Department of Health and Children' logging into the department's portal, visiting another government department, the 'Stationery Office', to obtain an official report, and having the Stationery Office query their 'home' department for a mailing address via the Liberty Identity Web Services Framework (ID-WSF).

This is a very simple demo, but it demonstrates some key aspects of Liberty ID-WSF:

  • 'Bootstrap' from federated web single sign-on (ID-FF) to web services (ID-WSF).
  • Use of the Discovery Service to locate a web service for a given user. (This takes place 'under the covers' - the bootstrap provides the service provider, in this example the Stationery Office, with the location of the Discovery Service and a credential to use on behalf of the employee. The service provider queries the Discovery Service for the location of the Personal Profile service).
  • Use of the Personal Profile Service to retrieve a user's profile attributes.
  • Use of the RedirectRequest protocol (specified in the Liberty ID-WSF Interaction Service Specification) to allow the employee's 'home' department to prompt for confirmation that address information is to be released to the Stationery Office.

Just click the screenshot below to view the demo...


Click to view Flash presentation

UPDATED 11/21/2005 - corrected Interaction Service to RedirectRequest protocol - see comments

Monday Oct 10, 2005

Sun Federation Manager Demonstration

My previous job at Sun (until January 2005) was as technical product manager for Access Manager. The main reason I moved back to engineering to take a technical architect role was so that my business card didn't read like a tongue-twister :-). Anyway - I still dabble on the technical marketing side, helping out when things get busy over there, like last month's technical sales training boondoggle event in Las Vegas - two days of lectures and labs bringing together Sun's identity management marketing team and the Sun system engineers (=sales engineers) affiliated with identity management.
My contribution (no - I didn't get to go to Vegas!) was a new front end for the Federation Manager Liberty Identity Federation Framework (ID-FF) single sign-on (SSO) sample. This sample, shipped with Federation Manager, shows how to get Liberty ID-FF SSO working between an Identity Provider and a Service Provider. Out-of-the-box, this sample comprised a set of functional, yet plain, JSPs. I re-used some old demo layouts to give the sample a bit of pizazz so the SEs could take something away as the basis for a demo. I was going to just put up a few screenshots here to walk you, the reader, through a simple SSO scenario, but then I realised that it would actually be less work to use Qarbon's Viewletbuilder to whip up a flash presentation. So - here it is - just click on the screen below and discover the magic of federated single sign-on...

Click to view Flash presentation

Wednesday Jun 29, 2005

Sun/Turkcell Liberty ID-WSF Proof of Concept

Great news in my inbox today: Sun and Turkcell (English-language version of Turkcell site) have published a paper on a recent proof of concept. Turkcell used Liberty's ID-WSF to implement an SMS service fulfilling three key requirements:
  • Protect subscriber privacy - subscribers' cellphone numbers (referred to as MSISDNs in the document) must not be revealed to 3rd party service providers.
  • Leverage subscriber location, again, while protecting subscriber privacy.
  • Use standards and off-the-shelf products wherever possible.
Turkcell used Sun Java System Access Manager as their identity provider, with an early access release of Sun Java System Federation Manager at the service provider. According to the document, "[Turkcell] successfully conducted a PoC project that has resulted with the accomplishment of all pre-defined requirements." Also, "We have found that the Liberty Alliance Specifications are brilliantly matching our needs and even exceeding in some ways." 
In the use case scenario, a GSM user sends a service request via SMS to a service provider to discover restaurants near the user's location. The service provider leverages the wireless operator's geo-location service, customizes content, and returns a corresponding list of restaurants back to the user.
Go read the paper and discover exactly how Sun's federation products and Liberty ID-WSF met Turkcell's requirements, and then some.

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.

Friday Apr 01, 2005

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 CatsInBomberJackets.com.
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.

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.
About

superpat

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today