C'est la vie !

Keeping our promise made a few months ago Java is now Open Source !

That’s great news and I think it will help drive adoption in the FSF/GPL world . The choice of the GPLv2 (with the so-called classpath exception to be precise) as opposed to CDDL is also a good one in my opinion as I know that many people were reluctant to use software based on anything else than GPL. At an open source project meeting I attended I also heard people hesitant of using J2EE or J2SE because it wasn’t open source and performance was an issue... Well now people will be able to go and improve the thing wherever they can/want.

My understanding is that the open-sourcing of Java will not change anything with regards to JCP. That’s good because there are many great projects currently going on there, in particular one I’m involved in: JSR279 (more on it in a subsequent post).

For more information, there is a one-stopper you should check (great video and FAQs).

As discussed in a previous posting, Sun Learning has come up with a great Federation bootcamp. I’ve received many inquiries for additional information and I’m happy to report that there is now an official email address fm-bootcamp-AT-sun-DOT-com you can contact (remember, this for Sun’s employees & partners for now).

Below is the “official” description of what’s on the menu for 5 great days...

 

COURSE DESCRIPTION

 

The Federation Boot Camp course provides students with an opportunity to

learn about identity federation. Students learn about federation

concepts and specifications, then use Sun Java(TM) System Federation

Manager (Federation Manager) and Sun Java(TM) System Access Manager

(Access Manager) as a platform for demonstrating the concepts.

 

Topics include federation concepts, federation specifications and standards,

implementing federation frameworks, web services, programming and

customization, privacy, security, and high availability.

 

This course does not cover Lightweight Directory Access Protocol (LDAP),

Sun Java System Directory Server (Directory Server) concepts, and Sun

Java System Web Server (Web Server) concepts.

 

Students spend the majority of class time gaining hands-on experience

performing a variety of tasks typical of a federation deployment. Students

are quizzed at the end of each lecture and tested at the end of the boot camp.

 

 

WHO CAN BENEFIT

 

Students who can benefit from this course are consultants, architects,

systems engineers, technical support personnel, and systems administrators

specializing in designing and deploying federation services using

Federation Manager and Access Manager software.

 

 

PREREQUISITES

 

To succeed fully in this course, students should be able to:

 

* Demonstrate proficiency with the Solaris(TM) Operating System

  (Solaris OS)

* Demonstrate proficiency with XML and interpret Document Type

  Definition (DTD) files

* Demonstrate familiarity with Hypertext Markup Language (HTML)

* Demonstrate familiarity with Java programming and JavaServer

  Pages(TM) [JSP(TM) pages]        

* Demonstrate familiarity with secure sockets layer (SSL), LDAP, and

  load balancers

 

SKILLS GAINED

 

Upon completion of this course, students should be able to:

 

1. Describe identity federation and identify problems that

   identity federation solves

2. Describe the Security Assertion Markup Language (SAML) 1, SAML 2,

   and Liberty federation frameworks, and deploy and configure Federation

   Manager to support those frameworks

3. Configure Federation Manager to support Liberty web services

4. Customize federation deployments

5. Identify security and privacy issues in a federation deployment

6. Configure Federation Manager to use Directory Server repositories

7. Deploy Federation Manager in a highly available configuration

 

 

RELATED COURSES

 

Before:

 

* AM-3480: Sun Java(TM) System Access Manager: Configuration and

  Customization

* WZT-AM-3481: Sun Java(TM) System Federation Manager: Getting Started

 

 

COURSE OUTLINE

 

Preparation Lab 1 - Federation Manager Installation

 

* Install Federation Manager

 

Preparation Lab 2 - SAML 1.1 Single Sign-on

 

* Configure and deploy SAML 1.1 single sign-on

 

Preparation Lab 3 - Liberty Circle of Trust

 

* Configure and deploy a Liberty circle of trust

 

Preparation Lab 4 - SAML 2 Circle of Trust

 

* Configure and deploy a SAML 2 circle of trust  

 

Module 1 - Identity Federation Concepts

 

* Describe identity federation principles

* Describe problems that identity federation attempts to solve

* Use identity federation terminology

 

Module 2 - Standards and Specifications

 

* Describe the principal identity federation standardization efforts

* Describe the SAML and Liberty federation frameworks

* Analyze federation use cases and apply federation techniques to

  real-life scenarios

 

Module 3 - Federation Product Introduction

 

* Describe the federation features in Federation Manager and Access Manager

* Describe when to deploy Access Manager and when to deploy Federation Manager

 

Module 4 - Implementing Federation Frameworks

 

* Implement single sign-on (SSO) with Federation Manager and SAML 1.0  

  or SAML 1.1

* Implement a Liberty Identity Federation Framework (ID-FF)

* Implement a SAML 2 federation framework

 

Module 5 - Liberty Web Services Framework

 

* Describe the Liberty Identity Web Services Framework (ID-WSF)

  specification

* Understand the Federation Manager Liberty web services implementation

 

Module 6 - Programming and Customization

 

* Describe the nuts and bolts details of federation

* Configure Federation Manager with metadata, a circle of trust, and a SAML2

  authentication module

* Integrate JSP pages and the SAML2 API into a web application for federation

* Demonstrate a federated web application

 

Module 7 - Privacy

 

* Describe privacy in the context of federated identity

* Describe examples of existing privacy laws and organization

* Describe how the Liberty Alliance guidelines protect a principal's privacy

* Describe which product features implement or violate privacy protection

 

Module 8 - Security

 

* Describe vulnerabilities and risks associated with federated identity, and

  describe mitigation strategies

* Describe how the Sun Systemic Security program and how its security

  principles can drive a secure federated identity implementation

* Deploy a secure federation using Federation Manager

 

Module 9 - LDAP Back end for Federation Manager

 

* Configure Federation Manager to use an LDAP back end for configuration data

* Configure Federation Manager to use an LDAP back end for user profiles

* Configure Federation Manager to use an LDAP back end for user

  authentication information

 

Module 10 - High Availability

 

* List basic high availability concepts

* Deploy Federation Manager in a high availability configuration

* Describe implementation challenges and limitations

Hurray!
As promised, our engineering team has just posted the source code of Federation Manager in our OpenSSO project.

The source code, labeled openfm, can be found HERE . If you’re interested in identity management and want to understand how Federation Manager implements the Liberty Alliance federation model this is it!

Enjoy!

In my previous post I talked about a bootcamp I attended that focuses on identity federation. In this entry I will discuss what identity federation is and what its purpose is. To do so I will be describing the scenario that forms the basis for all the labs the students of the bootcamp go through. I will also borrow some of the excellent illustrations they have in their material.

First, let’s describe the situation that is mostly prevalent today, that is when no federation exists. Every time a user (John Doe) visits a new web site ( we call them Service Providers - SP) and wants to do business with it he must create a local account at the SP. Because all these online applications have their own policy when it comes to user account creation (security etc.), the resulting situation is that John has (almost) as many different accounts as Service Providers. Later on, he will have to enter his account information (usually username and password) every time he visits one of those SP as described in the figure below:

The situation might be slightly better in the enterprise world where common authentication (single sign-on) can be achieved using LDAP (and other mechanisms) but I have yet to hear of a (big) company where employees don’t have several accounts to deal with.

I know some people might say: why is it a bad thing to have all those accounts? Well there are several issues with that:

1. The user’s online experience is bad as his surfing experience is constantly interrupted by authentication procedures.

2. The user needs to remember all those accounts ; the 2 most widely ways of achieving this is either to use the same username/password combination (though not always possible) or write down all that information on a post-it and stick it on the side of your screen. Obviously not ideal security-wise.

3. Each Service Provider needs to perform authentication at a satisfying level - this represents additional cost for the SP.

4. There is no possibility of sharing attributes between Service Providers: John will have to enter the same personal information (e.g. his shipping address) at every single SP that may need it. The problem is that it then becomes painful for the user to update those scattered bits of information. Also there’s a higher chance the info a SP hosts is no up-to-date.

The idea of federation is to alleviate all these issues by enabling the sharing of a user’s authentication status (and beyond that of attributes). Of course the adopted architecture must preserve both the user’s privacy (no unsolicited correlation between SPs, prior user consent to exchange of information...) as well as the security and confidentiality of the Service Provider’s relation with that user. The now predominant SAML 2.0 offers an elegant architecture that does meet those requirements and many more (note: Liberty’s ID-FF does too since it constitutes the basis of what SAML 2.0 is).

The overarching concept behind identity federation is that each SP establishes a relationship with a particular service provider we call identity provider (IdP). The IdP will be the one authenticating the user (local account for John at the IdP) and asserting that authentication (or the lack of it) to the requesting SP. To make sure the SP does not give up information about his customers to the IdP both the SP and the IdP agree to use a nonce (a random and unique number) that has no meaning except in the context of this federation. A typical IdP would be a service provider both you and SPs that will federate with can trust (more on that later), something like your bank online service or your ISP.

The result is a hub-and-spoke architecture with 1-to-1 relationships between the SPs and the IdP. See the figure below:

That’s it for today, more on federation to come soon!

If you work for Sun or you’re a Sun partner, here’s something really cool available to you...

Last week I had the chance to attend a new bootcamp Sun Learning has just released: the Federation Bootcamp . It’s everything one will ever needs to know about identity federation and Sun’s Federation Manager (FM). And believe me, there is a LOT to cover. Here’s the list of the modules covered in this bootcamp:

1. Identity Federation Concepts

2. Standards & Specifications

3. Federation Product Intro

4. Implementation Federation Frameworks

5. Liberty ID-WSF

6. Programming & Customization

7. Security

8. Privacy

9. LDAP back end for FM

10. High Availability (i.e. load balancing etc.)

All these modules have 2 components: a lecture that will teach you the fundamentals and prepare you for the second part: the lab. The labs were really what I was looking for since I’m well aware of the theory part (I guess participating to all the Liberty Alliance meetings does help ). The labs are really hands-on, lots of installation, configuration and messing up with FM. Here are some examples of what you learn to do:

11. Deploying FM - setting up security

12. Adding & configuring the SAML2 plugin

13. Deploying LDAP with FM

14. Setting up load balancing etc.

So again if you’re at Sun or if you’re a Sun employee and you’re interested in federated identity you have to take this bootcamp (drop me an email and I’ll forward the contact people).

In the next blog entries I will describe in more details some of the key points this Federation Bootcamp touched upon.

Stay tuned!

I just watched a program with Jacques Pépin on public television (KQED). He was presenting a French recipe called lobster Fricassée (see here and search for lobster ) and as a preliminary explained what is the fastest way (thus least painful) to actually kill the beast. Quite interesting and surprising at the same time; I would not have expected to see him actually perform the execution on TV. But as he puts it, it’s either the fishmonger or you but someone has to kill it. At least his method was definitely very quick.

Very refreshing to watch that on American TV after reading articles about some stores that decided to stop selling live lobsters or stories about the ban on foie gras in Chicago and elsewhere.

In this video on our SDN (Sun Developer Network) channel, Aravindan (architect in the Access Manager team) demonstrates how one can easily secure both ends of a web services transaction: the web service consumer (aka. WSC) and the web service provider (aka. WSP).

It’s all standards based (Oasis’ SAML , Liberty Alliance’s ID-WSF ) and pretty much all is done within Netbeans with a few clicks to select the appropriate security mechanisms. An excellent integration job IMHO.

And if you’re one of those that really wants to understand how identity management is implemented in our Access Manager product you should definitely go check our new OpenSSO project!

Reading Gudge's blog I came across this very funny crypto rap piece. It definitely reminds me of the numerous Alice and Bob discussions we've in the Technology Expert Group of Liberty Alliance

Following my last entry on a taxonomy around the user-centric identity term, Paul and I discussed about the features I highlight and how they are relevant to our 3 terms: user centric, user controlled and consent. The table below is a stab at it:

Two things to note there:

1. While the ID-WSF’s Interaction Service may not initially put the user between the requester and the provider it enables the provider to bring the user on the front row so it can ask for consent. It’s a PPEP (personal PEP) as Paul puts it.

2. There nothing in the user consent column (for now). I need to think a bit more about it.

Like I said, a work in progress...

All thoughts welcome!

Since Microsoft announced their work on InfoCard (or I guess I should say CardSpace now...) the term user-centric identity has been on many people’s blogs and as often happens with popular new terms the spectrum of its interpretations has widen. My esteemed Liberty partners Paul and Eve have blogged about a taxonomy that I think gives an excellent view on what we believe user-centric identity is and how it relates to the important notions of consent and control.

Not too long ago I gave a webcast on user-centric identity (along with John , see his excellent presentation on LECP ) and a prototype we have built that shows how Liberty‘s ID-WSF protocol do support user-centrism. Here is a first list of the technical aspects that supports this:

1. User consent ( SAML2.0 request)

2. Authentication context ( ID-FF , SAML2.0 )

3. Liberty Enabled Client/Proxy (aka. LECP - ID-FF )

4. Interaction Service ( ID-WSF2.0 )

5. People Service ( ID-WSF )

I’ll ad more to it as I think of them.

 

Last summer Eve and I made some presentations for an internal workshop on Identity Management. One of the presentation I thought people were the most interested in was about SAML v2.0.

SAML (aka the universal solvent for identity) is a powerful combination of a token format (assertions that can be about authentication, attribute or authentication) and a set of protocols. It is a foundation for Liberty's work.

If you are interested in identity management and want to learn more about SAML this presentation is a MUST (in all modesty ).

OK I'll admit the title is a bit catchy but I can back it up!

In my previous entry I explained how the demo I worked on (many thanks to Lauren, Emily, Marc and Rajeev!) demonstrate a possible user-centric approach for Identity Management using the Liberty specifcations. I guess with all the buzz on InfoCard or more recently on the project Higgins we were right on target.

Although the pdf file I posted is explicit enough I leveraged my good friend Pat's expertise to create a really cool flash version of the demo. So seat back, relax and enjoy the show!

I watched online the presentation Bill Gates gave at RSA this week and I thought the InfoCard demo was interesting. First off it was the first time I saw an actual demonstration of the identity selector on Vista - quite interesting, nice UI I have to say. It is certainly a very user-friendly approach to solve the identity management nightmare we all face as online consumers. I really think it is to Microsoft’s credit to have raised awareness on the need for a more user-centric approach of identity management.

That said, I read on this recent article of the Seattle P-I that (some) people at Microsoft believe that InfoCard and the Liberty Alliance approach “address different parts of the digital identity problem”... Now I beg to differ on that one.

To me Liberty’s web services framework (ID-WSF) proposes a framework that is generic  enough to support all kinds of identity-based scenarios including the most user-centric ones. It is true that in most of its PR so far the Alliance has not emphasized the user-centric aspect of identity management hence the impression for some people that Liberty’s specifications are focused on the enterprise. For that I think Microsoft’s InfoCard is a great reminder that we (at Liberty) should also explain how our specifications can be used to support a user-centric approach.

At Sun we happened to have recently looked at that issue and we’ve come up with a demonstrator (very early stage) that shows how, using Liberty’s ID-WSF protocols, we can create a module that greatly helps the user in dealing with his digital identities. You can find a series of screenshots that are accompanied with explanations there (I’ll be polishing a flash file soon). Hopefully the comments are self-sufficient but just in case here’s a short summary of what the demo actually shows:

The user is visiting an online wine merchant where he purchases a few bottles (Bordeaux of course ). Upon checkout the wine site will need some identity data about the customer (like his age or his shipping address). A Java applet is fired off the html page of the site with the name of the attributes (i.e. the identity data) required by the site. For instance the first step is to verify the customer is actually entitled to purchase wine. Using this information the applet (that speaks ID-WSF) is able to identify what are the relevant attribute providers (I believe they are called Identity providers in InfoCard’s terminology). The end result is that the applet is able to present to the customer a set of providers to choose from (very much akin to the card concept with InfoCard’s identity selector). Since it is an applet running no information is transfered to the wine merchant until the customer actually clicks on one of the provider.

So the idea of this demo is to illustrate the flexibility of Liberty Alliance’s specifications. Not only they support the enterprise use cases but they also do enable a great user-centric experience and guess what?  it’s platform independent

As Eve put it, it’s InfoCard, Liberated!!