Category Archives: Federation

Plaxo and OpenID (Problem 2)

Posted on by

Plaxo upgraded their OpenID libraries a while ago and this gave some issues. Those are fixed now, thank you Plaxo.

Now that I am blogging about Plaxo’s OpenID support, let me start the second problem I have. Each time I receive an invitation to connect to someone I know at Plaxo, Plaxo shows a different URL to identify itself at my OpenID provider (MyOpenID). We are talking long and complex URL’s containing numerous GET parameters.

The result is that the list of known URL’s at my OpenID provider is getting longer and longer every day and Plaxo is already taking up over 60% of that list. The screenshot below shows a subset of this list:

Plaxo OpenID URLs

I don’t know if this is by (OpenID) design or not. What I do know is that when I have to accept a site, identified by a long and complex url, requesting my information, I don’t really know if I should accept or not. This makes phishing a little easier to do, just throw a complex URL at the user, he can’t validate it anyway. To make matters worse, MyOpenID layout does not even show the entire URL to me, it clips of in the initial screen where I can “Allow Always”, “Allow Once” or “Deny” and in the list of sites I took action on.

OpenSSO Identity Services

Posted on by

OpenSSO (Sun’s attempt at open sourcing some of there access management solutions) has published a first draft of some Identity Services. It’s a four part article with the first two parts already published: authentication and authorization.

When I first saw this announcement, I was very interested and almost rushed over to those articles. After a first read however I was somehow disappointed. The interface definitions are very simple, a little too simple. The authentication API merely allows you to send over a username and password and it’ll return you some kind of subject identifier. The authorization API suffers from the same faith: feed it a URI, an action and a subject identifier and it will tell you if that subject is allowed in or not.

Everyone who knows something about the specifications and standards surrounding Identity Services, know that there is more to it. A lot more. You can leave stuff out to make things simpler, but I have this feeling OpenSSO has left out too much. Some of the things I feel are missing or not that good:

  • Abstraction from authentication methods, it’s just username and password now. Aren’t we all working very hard to get rid of those? What about SAML, WS-Trust tokens …
  • Proper countermeasures for obvious threats like replay, message insertion, message modification, message deletion … Please, don’t answer “oh, we’ll just apply SSL to the transport”, that gives you only part of the solution. You do need controls at the message and API level as well.
  • The ability to tie authentication to a certain context (just returning a subject identifier leaves that aspect to the calling party). What if I would like to bind a positive authentication to a particular resource? The subject identifier might contain that information, but their specification is very silent on that aspect. For the moment, that identifier is an opaque handler.
  • The returned subject identifier is currently used to bind all services together, but the specification doesn’t say how it is protected and how I can verify it’s validity. If these services are placed on the Internet, I see a lot of security holes.
  • What about time windows for the validity of the authentication?

And finally, I wonder why these Identity Services from OpenSSO don’t attempt to place a higher level API around what we already have from OASIS (SAML, WS-Security, WS-Trust, WS-SecureConversation …) and Liberty Alliance (ID-FF, ID-WSF …).

Re: Never Say Never

Posted on by

Paul Madsen replied on my blog “Never get lost again while federating“:

I don’t have quite the same amount of faith as Bavo De Ridder does in Liberty Alliance’s new intro to our specification set.

I know I’ve heard ‘recalculating’ countless times from another system that makes the same claim.

Liberty Alliance’s new representation of their specifications may not be perfect (and it surely isn’t) but at least it is a step up from the previous list of PDF files and will hopefully make it more clear to some people.

In the last few weeks I had to explain several times to people what federation was and what it isn’t and how the different specifications relate. At the same time, some people caught me on some errors and corrected me. People familiar with federation probably know there is a lot of misinformation out there, not in the least from vendors and in particular their sales-force. For the moment federation seems to be the magical bullet that will solve everything costly identity management suites apparently are not capable to.

Simple graphical representations, like the one Liberty Alliance has placed on their site, surely help in clarifying some of the misunderstandings out there. It is however only a (very) small part of the overall picture, a picture that is getting more complicated by the day and therefore harder to grasp. Graphical representations are not that magical bullet either, you still need to understand each of the blocks individually.

But all this still leaves my question standing:

Is there anyone out there brave enough to take all existing identity work and show their relationship in one graphic?

Never get lost again while federating

Posted on by

I was reading through the blogs of Paul Madsen and I came across this posting about an update to the site of the Liberty Alliance. One very nice addition is this Flash animated navigator for all the Liberty Alliance specifications.

This reminds me of the famous graphics showing all the XML specifications known at that time.

Such graphical representations sure help people to stay up to date with the multitude of emerging specifications and their relationships. Is there anyone out there brave enough to take all existing identity work and show their relationship in one graphic?

Address-based identities versus Card-based identities

Posted on by

I was reading this blog entry about address-based identities versus card-based identities. I am still thinking about the contents and will post some more thoughts about that blog in the next few days. There was however one example in the blog I would like to comment on right away:

Whatsmore, both address-based identity and card-based identity can be further classified in some very helpful ways:

  • Address-based identities can be broken into resolvable and non-resolvable. While an address-based identity is always unique in the address space in which it is assigned, that doesn’t necessarily mean it can be resolved, i.e., dereferenced via a mechanism or protocol that provides further discover or communications with a digital subject. An email address is a good example of the former; a browser cookie a good example of the latter.
  • Card-based identities can be broken into addressable and non-addressable. This means that some card-based identities may contain an address-based identity and some may not. A business card is the classic example of an addressible card-based identity; in fact the primary purpose of most business cards is to share address-based identities. On the other hand a coffee-shop loyalty card is a good example of a non-addressable card-based identity: while it describes identity-related attributes of its owner (how many cups of coffee they have purchased), it may not contain any address-based identity whatsoever (not even your real-world name).

In the second bullet a coffee-shop loyalty card is used as an example of a card-based identity. That confuses me. Assuming, from the example, that the card does not contain any personal information like name or address, how can it be seen as a card-based identity? The only connection this loyalty card has with a person (identity) is that it is carried around by one. But that would make a lot of items suddenly card-based identities. The card cannot be used to identify or authenticate a person and has only value to the person carrying it around but it is in no way connected to that person. Following this reasoning, the 10 EURO note I am carrying around also is a card-based identity.