Mistaken Identity

In a case of mistaken identity (of a place rather than a person) my United flight to Portland last night was delayed and had to re-connect the jetway and switch passengers.

As we were getting ready to push back, one of the passengers got up and talked to the flight attendant in the front of the plane. They talked, she talked to the pilot, they talked some more. All I could here was "I'm really sorry" coming from the passenger.

The jetway re-connected and the guy got off the plane (while another passenger, who had been denied boarding because the plane was oversold, got on -- lucky him).

Apparently, the departing passenger had booked the tickets, checked in, and boarded the plan without realizing that he hat ticketed himself to go to Portland, OR, rather than Portland ME. I would have thought that the 5 hour flight time would have given him a hint, but perhaps the fact that the 3 hour time difference made the apparent time difference (if you didn't pay attention to timezones) appear to be just 2 hours.

Anyway, luckily we hadn't gone far and he didn't have any checked baggage (nor, from what I could see, much carry-on luggage -- just a small laptop case). So after the quick switch we were on our way.

Tags : travel / ual

Advanced Client Take 2

The second draft of the Liberty Advanced Client Technologies set of specifications has been published on the Liberty Alliance web site.

For those who aren't aware, the Advanced Client Technologies work is the 3rd generation of client technologies coming out of Liberty. The first generation was work that enabled a Liberty-aware client and/or proxy to participate in the SSO transactions (similar to what Cardspace does today). The second generation enabled active clients to act as WSC's in identity transactions (such as a radio or mail client authenticating with an IdP, discovering and accessing a service provider).

This third generation enables clients acting as an extension of network providers such as an IdP, and addresses the issues related to hosting full-fledged service providers (such as my own IdP, or my own Contact Book Service) on my personal client.

So, this is your chance to nail me to the wall and point out how many stupid things I've done in there (though I'm not the only contributor, I'm sure that if something stupid is in there it is my doing). Please take a look-see and let us know of any interesting things you find in there (even pointing out the many, I'm sure, English mistakes would be helpful).

Go for it!

Tags : identity / Liberty / Liberty Alliance / Advanced Client

Portals and IdP Discovery

I recently received a comment on my SAML Bashing blog entry. "Jeremy" (not sure which Jeremy as he was otherwise anonymous in his comment -- I wonder if it's really James in disguise -- this seems the kind of comment James would leave, but James is usually quite blatant about it, not hiding behind an identity pseudonym) asked:

Kim stated "The question of how the relying party knows which identity provider URL to use is open ended. In a portal scenario, the address might be hard wired, pointing to the portal’s identity provider. ". What are your thoughts on that?

In the early days of Liberty ID-FF, we paid a good amount of attention to what solutions would fit into the various portal solutions. Must of this has to do with the configuration and structure of the portal. We saw different portals using different solutions including:

• Push SSO
  
  

  In "push SSO" the portal, when creating links to the various components that make up the portal, generate redirection links that send the user directly to the IdP with some additional information causing the IdP to initiate an SSO to the third party.

  This is a common solution used in enterprise portals when the user selects a link provided by an outsourced third party (such as Fidelity providing 401K or stock purchase account management for employees).

• Well-known IdP
  
  

  This is the solution mentioned in your quote of Kim. The members of the portal know which entity provides IdP services for the portal and can send the user to the IdP to get them authenticated. This is how most portals work today (e.g. Yahoo's IdP is known as the IdP for all Yahoo services at the Yahoo portal, so when I go to Yahoo Games, I get authenticated by the Yahoo IdP).

• Affiliations
  
  

  Affiliations are a technical structure used to represent provider membership in a group (such as a portal, but can also be other business groups). When the user "federates" to an affiliation, the members of the affiliation are able to treat the user a a common user providing synchronized services and precluding a multitude of consents and idp interactions.

  The concept of Affiliations was introduced in the ID-FF specifications and was incorporated into SAML 2.0 during the convergence of SAML 1, ID-FF and Shibboleth.

Tags : identity / IdP Discovery / Liberty / Liberty Alliance / affiliations / SAML / Yahoo / Fidelity