Wednesday Dec 20, 2006

Now that WS-Federation 1.1 is out...

[WS-Federation 1.1], when are thought leaders at vendors like Sun going to come clean and mention this in their blogs. Their silence is suspicious! This is clearly going to become the industry standard for federated single sign-on, despite anything those bozos at OASIS say.

gratuitous irrelevant picture

With credit and apologies to James McGovern for stealing his format Smile!

Tuesday Dec 12, 2006

More on Federated Authorization

Conor and Paul both recently responded to James' questions on federated authorization. Conor quite rightly pointed out that I managed to describe two common scenarios involving federation and authorization without explicitly answering the question - "Does Federated Identity sometimes require Federated Authorization?". As much as it pains me, I have to agree with Conor here - federated identity per se does not require federated authorization - rather, the resource owner might require it. It all depends on the use case that you're implementing.

James also alerted me this morning to a very interesting post from Shekhar Jha. I'll have to take the time to read the SecPAL paper properly, and, even then, there are people far better qualified than me to comment on this, but it does look interesting - particularly the fact that there is a natural language-like, non-XML syntax.

Shekhar goes on to discuss relationships in the identity domain. I refer Shekhar to the excellent work done by Paul on the People Service - FAQ, white paper [PDF], specification [PDF]. This seems to map neatly onto what Shekhar is saying.

Friday Dec 08, 2006

Federated Authorization

In a comment to a previous blog entry here, James McGovern asks

Does Federated Identity sometimes require Federated Authorization? If so, how come this isn't ever discussed. Maybe you could address in future blog entry...

There are two models here. In the first model, a given user has a profile (set of attributes) stored at an attribute provider (which may or may not be the same as that user's identity provider). The user goes to a service provider, the service provider receives a SAML 2.0 Assertion containing some set of attributes, and the service provider acts as both the policy decision point (PDP), deciding, on the basis of the user's identity (including the attributes), which resources the user may access, and the policy enforcement point (PEP), restricting the user's access appropriately. Here's a real example in the enterprise space...

Sun has deployed federated single sign-on with BIPAC - BIPAC is 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.

When I go to the BIPAC site, it redirects me to Sun, I log in with my Sun employee number and password and I'm redirected back to BIPAC with a SAML assertion containing a number of attributes - iirc, whether I'm a US citizen, whether I'm a member of a 'restricted class' of employees and my zip code. Note that the assertion does not identify me personally - it only tells BIPAC that I am a Sun employee with these attributes. Now the BIPAC site can act as the PDP, deciding what I can access, based on those attributes, and as the PEP, constraining my access to the BIPAC site according to those decisions.

In the second model (which is what I think James means by 'federated authorization'), the service provider is still a policy enforcement point, but the policy decision point is elsewhere. In our BIPAC example, the BIPAC site would still redirect me to Sun for authentication, but need not receive any attributes in the SAML assertion - just a pseudonym (SAML Name Identifier) that it can use to refer to me; again, BIPAC doesn't know who I am - the pseudonym can be a one-time identifier - used in this interaction, but never re-used - so I can't be tracked across visits. Now the BIPAC site can make an authorization request of a PDP at Sun, including my pseudonym and a reference to the resource I want to access. The PDP evaluates policy, essentially doing the same thing as the BIPAC PDP did in the previous example, and returns a response to BIPAC that indicates whether access to the resource should be allowed or denied.

Having these two models allows us to factor out authorization and put it where it makes sense. It may well be that it is the service provider that is responsible for policy, based on information provided by an attribute provider (model 1), or, alternatively, the service provider may simply request an authorization decision from a PDP, without being party to the data underlying the decision (model 2).

In terms of specs, both SAML and WS-Federation enable model 1 - passing attributes in assertions which are themselves carried in authentication responses. XACML is the basis for model 2, and is profiled for use with SAML by the SAML 2.0 profile of XACML v2.0 [PDF]. I'm not aware of any commercial products that implement this specification today (perhaps that's why no vendors are talking about it?), but OpenSSO is a good place to go to talk about requirements and implementation - you can sign up to the 'users' mailing list here.

Does this answer your question, James?

UPDATE - perspectives on this from

And responses from James -

Wednesday Nov 08, 2006

Big in Japan

Sun Enterprise News is covering the recent Liberty Alliance Day in Tokyo. Hmmm - perhaps the orange Liberty Alliance soccer shirt wasn't the most flattering thing I could have worn...

Tuesday Nov 07, 2006

Federation Boot Camp

You might have read Hubert's recent blog entry on the Federation Boot Camp - an intensive week-long course covering advanced Federation Manager topics. Hubert has more news on the Boot Camp today - hop on over there for the course description, and email <script type="text/javascript" language="javascript"> </script> for more information.

Monday Oct 16, 2006

Federation - Italian Style

Somehow, this passed me by back in March/April, but a presentation at Sun's Customer Engineering Conference last month brought it back into focus - Italy's Ministry of Transportation has deployed a new Motorist Portal, providing services such as online payment of vehicle registration fees and traffic tickets.

What's interesting here is that drivers log in to the Motorist Portal to view their driving record, vehicle registration etc, but make payments via another government agency, Poste Italiane. The Motorist Portal acts as a SAML identity provider, with Sun Java System Access Manager authenticating users and providing single sign-on to Poste Italiene's service provider for 40 million Italian drivers - possibly one of the biggest live SAML deployments in the world.

You can find out more in this short SunTV presentation and the Italian press release (English translation via Google).

Wednesday Oct 11, 2006

CSO Article - The Truth About Federated Identity Management

I just finished reading The Truth About Federated Identity Management by Sarah D. Scalet at CSO. It's a good read, focussing on the importance of the business case in deploying federated identity and the fact that 80% of the work in any federation deployment is on the business side. The technology, by comparison, pretty much "just works". Make sure you hit the sidebar too: Thinking of Doing Federated Identity Management?.

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 May 10, 2006

JavaOne 2006 San Francisco - TS-6673 - Federated Web Services With Mobile Devices

Rajeev Angal and I will be presenting 'Federated Web Services With Mobile Devices' next week at JavaOne 2006 in San Francisco. Here's the blurb from the session catalog at the JavaOne website:

Session ID: TS-6673

Session Title: Federated Web Services With Mobile Devices

Session Abstract: JSR 172, the Java™ Platform, Micro Edition (Java ME) Web Services Specification, is a key Java ME specification that defines APIs enabling mobile devices to invoke web services.

Mobile devices are becoming an ever more popular means of transacting business; at the same time carriers and service providers are looking to differentiate themselves from their competition and cater to the ever increasing demand to provide more services to their consumers. This session describes a means of securely providing access to web resources and web services using open standards such as OASIS SAML V2.0 and Liberty ID-WSF from a Java ME enabled mobile device.

Wireless carriers act as Identity Providers (IdPs) in business alliances known as 'Circles of Trust' (CoTs), authenticating customers and providing them secure access to a range of Service Providers (SPs). This federated model gives customers a seamless experience that is much more than the sum of its parts. For example, a wireless carrier could form a CoT with itself as IdP and SPs providing services such as email, calendar, mapping, weather, hotel reservations, travel information and ringtones. A customer authenticates at the wireless carrier - the carrier then provides secure single sign-on to each SP via signed assertions of the customer's identity.

As we move from simple single sign-on to identity web services, this federated environment forms the basis for providing a portfolio of services to the customer. For instance, the wireless carrier could host a location service enabling SPs to provide value-added services such as weather and hotel reservations based on the customer's current location.

The Liberty ID-WSF and OASIS SAML V2.0 standards provide the necessary security characteristics such as privacy, confidentiality, user consent and non-repudiation to make such interactions work in a federated environment. This session will show developers how a Java ME enabled mobile device can use JSR 172 to leverage ID-WSF and SAML V2.0 in accessing federated services and providing real value to customers.

Session Topic: JAVA ME

Session Type: Advanced How-Tos

Speaker/s & Speaker/s Company: Rajeev Angal, Sun Microsystems, Inc.; Pat Patterson, Sun Microsystems, Inc.

Date: Friday May 19 2006

Time: 2:30pm

Location: Moscone Center Esplanade 301

Join Rajeev and I next Friday and discover how to implement your own mobile federated web services. Or federated mobile web services. Anyway - see you next Friday.

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.

Wednesday Apr 19, 2006

Multi-protocol User-centric Identity

Johannes Ernst replies to yesterday's post on Multi-protocol Identity Implementations:

Let's take this a step further. If user-centricity is really what we are after, it follows that I am my own identity provider in many circumstances, doesn't it? (Even if I let somebody else manage the server that runs the code and stores the data.) There seems to be a C2C model as well. What might the dynamics be there? That's the truly decentralized, peer-to-peer version of identity ...

Paul Madsen makes a similar point, commenting

Users acting either as their own Identity Providers or as direct identity consumers will present a different set of challenges of multi-protocol support for the sites with which they interact.

Assuming we are talking about widespread adoption, I think the user experience will be key here. Only a few hardy souls are going to tolerate managing several personal identity providers (PIPs). What we need is some higher level UI that might let us manage several credentials, each with their own protocol - perhaps a sort of 'metasystem' to make sense of it all?

Err...

Tuesday Apr 18, 2006

Multi-protocol Identity Implementations

Interesting to see the discussion over the past few days between Phil Windley and Johannes Ernst on multi-protocol identity implementation. I've been through a couple of iterations of this myself, with last year's Microsoft/Sun Web SSO specifications and the Burton Catalyst multi-protocol federation demo.

There is a complex dynamic between identity providers supporting many protocols to service a wide range of relying parties and the converse, relying parties supporting many protocols to allow users to authenticate at any one of a range of identity providers. In the B2C world, it seems likely that the role of identity provider will naturally gravitate towards the big guys - maintaining a secure identity infrastructure is expensive - scale provides natural economies. This would seem to indicate that identity providers will be able to dictate terms - "My way or the highway", but we haven't seen much evidence of that. On the contrary, identity providers seem to be the ones interested in multi-protocol support at their end - the multi-protocol identity provider hub model that we demonstrated with Access Manager at Catalyst.

The logic is that, once you have an infrastructure for storing identities and authenticating users, supporting 2, 3 or 4 protocols isn't much more difficult than supporting 1. The relying party is in a different position - their core business is the service they are providing - horoscopes, online gaming, a blogging platform, whatever. The relying party wants to pick a protocol, implement it with identity provider #1 and add identity providers over time without a bunch of extra expense and complexity.

On the other hand, in the B2B arena, the dynamics may turn out to be the reverse, as relying parties (service providers) such as 401(k) providers, health benefits providers and even political action committees implement federated SSO to allow company employees to leverage their enterprise login to access external resources. Here, the relying party may take the driving seat, implementing a range of protocols as they implement federation with a range of their customers. Enterprises are deploying federation internally first, hooking up divisions, so when a service provider offers federated SSO the identity provider is likely to have already selected a technology.

Caveat - this is a rapidly evolving market (who would have foretold the explosion in user-centric identity?) and the above is based on the observations of one guy talking to a random bunch of enterprises and organizations. I'm perfectly prepared for a bunch of incoming links over the next few weeks/months/years explaining just how wrong I was

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

Friday Mar 31, 2006

Infocard from Java

Kudos to Chuck for implementing an Infocard RP in Java - and not only an RP, but online Infocard generation as well. So - the next piece of the puzzle - what is that symmetric proof key in the SAML assertion for??? If you know, then please put us out of our misery, either here or at Chuck's post on the topic.

About

superpat

Search

Archives
« July 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
31
   
       
Today