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.

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!

Sun Java System Federation Manager

UPDATE – ‘touched’ publication time to send this to the top – new stories and links

Stories about our new Federation Manager:

I’ll update the above list as more come in.
So what, exactly, is Federation Manager? Well, it’s the SAML and Liberty technology that has been in Access Manager for the past two or three years, built into a new product specifically designed for the service provider. Doesn’t Access Manager already support service providers? Well, yes, it does, and it will continue to do so. FM trades-off some of Access Manager’s more advanced features in favour of ease of use when federation-enabling service providers.
More information to come over the next few days…

Participation in Web Single Sign-On Interoperability Specification Process

Mark Wahl left a comment asking how interested parties can comment on and contribute to the recently released web single sign-on interoperability specifications. Well, Sun and Microsoft have established a Yahoo group for this purpose at You will have to fill out a participation agreement to sign up to the workshop group – IP stuff I guess – I can’t comment on that right now as I haven’t seen the agreement.

One-time Federation

I had a question today from a Sun contractor in Europe. He was asking how Liberty provides for federation where the user does not have an account at the service provider – the ‘SAML 1.1’ case. The answer is one-time federation, described in section 1.2 of Liberty ID-FF Protocols and Schema Specification. The spec says “service providers can […] request a non-persistent, one-time only, anonymous name identifier for the Principal.” You can search that PDF for ‘onetime’ to find out more.
While googling for this information (I find Google is the quickest way to find stuff hidden away in PDFs) I found a very useful document at Entrust – Liberty Example Scenario – Anonymous B2B – that does a great job of explaining exactly this scenario, including how the service provider can obtain more than just the one-time name identifier by using ID-WSF to request attributes or by pre-arranging for attributes to be present in the ID-FF assertion. Three cheers to Entrust for a very lucid description of one-time federation.

Location, Location, Location

Location as an attribute – sorry, ‘claim’, – of identity has been buzzing around the identity blogosphere these past few days. This comment by Bob Blakley (I’m guessing this is the right Bob Blakley – somebody please correct me if I’m wrong!) on Kim Cameron’s Identity Blog is particularly interesting:

The ISO 10181-3 Access Control framework was very clear about this, so there’s really no need to be unclear. 10181-3 divided authorization attributes into categories: (1) subject attributes, (2) target attributes, (3) request attributes, (4) context attributes. The POLICY took all these attributes into account when making a decision. Identity claims are subject attributes. Location claims, because they are not unique to a subject and because a subject’s location may change (and because the protocols carrying requests usually do not natively support location) are context attributes. Trying to make location an identity (=subject) attribute will greatly complicate the storage and management of identity information, with no gain in functionality over what is already gained by treating location (properly) as a context attribute. Time, as you point out, Mark, is also a context attribute, as is “client device capability”.

It struck me tonight that the answer to the question of whether location is a subject attribute or a context attribute is (as usual) “it depends”. In applications where a policy requires that a subject’s location meet some criterion to gain access to a resource, location is indeed a context attribute. However, it isn’t quite that simple.
Consider a simple weather service for cellphone users. The user sends the word ‘forecast’ as an SMS message to the service. The service responds with an SMS message containing the day’s forecast (and probably also an ad targeted at your current location). As far as the weather service is concerned, your only identity is your location. It doesn’t care who you really are, or even if you are the same you that requested a forecast from a different location yesterday. I would contend that, in this context, location is a subject attribute.

UPDATE: See commentsAlan Nichols clears this up with the concept of the anonymous user.

Speaking at JavaOne 2005 this month

I will be co-presenting 2 sessions at JavaOne later this month. Here is the relevant information (edited from the session catalog at the JavaOne website):

Session ID: TS-3556
Session Title: Multiple Platforms, Single Identity: Interoperable identity
Session Abstract: Single sign-on between an enterprise’s web-based resources, such as applications based on Java™ 2 Platform, Enterprise Edition (J2EE™ platform) and .NET, has existed in proprietary form for some time. The need to allow access across enterprise boundaries prompted the development of standards, such as SAML and Liberty ID-FF for identity federation, providing capabilities such as single sign-on and account linking across enterprise boundaries.
This session provides a brief overview of the standards for identity federation, shows how to integrate SAML and Liberty ID-FF with J2EE platform Security, and explains how Java technology-based access management products, such as Sun Java System Access Manager, can provide interfaces even into a .NET infrastructure such as Active Directory.
Session Topic: Interoperability (Java™ Technology and .NET)
Session Type: Advanced How-Tos
Speaker/s & Speaker/s Company: Eve Maler, Sun Microsystems, Inc.; Pat Patterson, Sun Microsystems, Inc.
Date: Wednesday June 29 2005
Time: 1:30pm
Location: Yerba Buena

Session ID: TS-3269
Session Title: Developing and Deploying Secure Identity Web Services in a Federated Environment
Session Abstract: The Liberty Alliance Project (LAP) defines specifications to address cross business web single sign-on (ID-FF) and provides a framework for building web services (ID-WSF). These specifications are by far the most comprehensive security framework available today to build secure identity-enabled web services. ID-WSF addresses the need to build interoperable, identity-based, identity-consuming, and standard web services.
This session focuses on developing client- and server-side components of a secure identity web service based on Liberty ID-WSF specifications and deploying them in a Liberty-enabled environment. This session covers several Java™ standard technologies: Java 2 Platform, Enterprise Edition (J2EE™ platform), XML parsing, JAX-RPC, XML digital signing and encryption, and others, such as Liberty Java APIs built on top of SAML and WS-Security.
Session Topic: Core Enterprise (J2EE™ Technology)
Session Type: Advanced How-Tos
Speaker/s & Speaker/s Company: Srividhya Narayanan, Sun Microsystems, Inc.; Malla Simhachalam, Sun Microsystems, Inc.; Pat Patterson, Sun Microsystems, Inc.
Date: Thursday June 30 2005
Time: 12:00pm
Location: Hall E134

So – come along and find out the latest about getting your J2EE infrastructure interoperating with AD and .NET, and implementing ID-WSF web service providers and consumers in Java.

Fixed RSS feeds in Planet Identity

Planet Identity‘s RSS feeds have been broken since I created it last week. The problem was that certain elements containing URIs were not being escaped properly – the parse would break on any ‘?’s and ‘&’s. I finally sat down this morning and spent 20 minutes googling for the answer – and it’s really simple – you just edit the RSS feed templates and specify that URIs such as the link element and the url attribute of the source element should be HTML escaped and all is well.