Friday, August 24, 2007

Relatinships and authorization

James McGovern writes about how relationships must include authorization:

Anyway, the notion of relationship is something that belongs to the identity provider and entities such as the Liberty Alliance are defining standards around it. Check out their notion of the people service. The key though is that relationships sometimes require authorization. For example, just because my son can order an insurance card from Amica doesn't mean he is also allowed to cancel the policy for the entire family. Relationship needs authorization especially in domains having to do with medical interactions.

While I like his good words about the Liberty Alliance, I take exception with some of his conclusions.

First off, I don't think that relationships should or must belong to the Identity Provider. This is especially important in a world where my relationships cross the boundaries to many different Identity Providers. Within Liberty's People Service, we took great pains to ensure that the protocols support both a) the People Service be able to be provided by a party other than an IdP (just as LinkedIn provides this type of service to their customers) and b) the relationships contained within a user's People Service must be able to cross identity domains while still protecting the privacy of the users. The latter requirement lead to some rather complex protocol sequence requirements when establishing a connection.

Secondly, I look at authorization as being associated with the object being accessed (where the input parameters may include individuals and/or group memberships) and not with the relationship itself. So in the example provided by James, James would introduce his son to Amica (using the People Service) and then set the associated rights at Amica, not within the People Service. The primary driver for this is that only Amica understands the objects available to Jim and the associated access permissions that may be possible for those objects.

The one place where I see the People Service (and/or any other relationship tracking service) getting involved in authorization is where the user controls what another may do with his relationship (e.g. I can allow Paul to see my relationships (and the fact that I long ago had a coolness link to the ever-cool Joni)).

Tags : / / / / / /

Friday, August 03, 2007

Sniffing Cookies

In Tools to sniff and clone cookies Stephan Brands writes about a scene at a recent Black Hat Security conference where a presenter was able to steal live sessions by sniffing cookies on open internet connections and concludes:

The message for those working on digital identity solutions, in particular “lightweight” identity solutions and plain-vanilla browser identity federation a la ID-FF, should be clear: unless asymmetric cryptographic protection is made an integral part of a solution, users are highly vulnerable to theft of IdP login credentials as well as of identity claims that are issued to them.

First off, to be very clear, there was absolutely *NO* stealing of login credentials. What was actually stolen in that particular case was a session cookie that would enable the hacker to use an existing session for the length of the session. The stolen cookie could not be used to establish new login sessions (as login credentials would allow).

Secondly, in a Liberty ID-FF and/or SAML scenario the authentication protocols are required to take place within an SSL session and we strongly encourage that SSL be used to protect the authenticated session afterwards.

The real example that was shown is that services that do not use SSL to protect communications from the browser to the server are liable to be monitored, recorded, and even hijacked -- regardless of how well the user was authenticated.

Moral of the story: Use SSL to protect communications of sensitive information.

Tags : / / / / /