Monday, August 24, 2009


If you have a chance; check out this proposed session for SXSW: Have you noticed that when you search the internet you probably don't see results from the stuff that you pay for (subscriptions, stuff available through your local library, etc...)? this panel will discuss how we could fix that... If you think that would be useful.. go give it the thumbs up.

Monday, July 20, 2009


I have written about reputation in the past and continue to evolve my thinking on the subject. I had an interesting interaction last weekend with Lillie Coney of EPIC while on a panel together at ALA. Lillie described the legal frameworks that exist to both protect and circumvent our privacy as a lawyer and a privacy expert she described the steps necessary to strengthen our privacy position in the law. I found myself pushing back on Lillie; expressing that Reputation systems are just as important as systems of accountability for privacy as legal frameworks. If we had more time I think we might have had an interesting discussion on the subject.

Here's the summary I reached in my head: I do not deny that the legal system works to protect our privacy interests at certain levels. However, as an individual with a compaint against a large company I have very little recourse. For me to take action, personally, against a large corporation is prohibitavly time consuming and costly. I believe that robust reputation systems can help give me a way to have a voice.

We know that there are places that the legal system works. We know that there are places that reputation systems work. There is a gap between these 2 places where very little works. Lille was explaining how we fill that gap with legal framework. I propose that we can also fill that gap with well constructed reputation systems. I don't think this is an either-or situation; together these things can provide robust protection and accountability that is available to everyone.

My point is that while those of us who think about reputation recognize the importance of the legal frameworks, I'm not sure that the people who work on the legal frameworks recognize the importance of the reputation systems.

What do you think?

Friday, June 12, 2009

Is anybody out there

It's been a long time since I blogged :-( and even now I'm just asking a question...

Now that I am actually implementing SAML stuff, specifically Shibboleth (mainly web sso). What book would you recommend I buy?


Tuesday, March 03, 2009

What is SSO

One of the hottest issues in Identity Management is often referred to as SSO; Single Sign-On. However it is a horribly misunderstood and misused term. I will try to give a brief overview of what SSO is and isn't.

What most people mean when they say SSO is the user experience of accessing multiple services and systems but only having to 'log-in' once. On the face of it SSO sounds great but there are some pitfalls that we have to be wary of. If we aren't very careful, the 'ease' of SSO is bought at the cost of privacy.

The type of SSO that I am going to explore is the "HTTP Redirect" SSO mechanisms that are widely deployed for SSO on the web. This includes OpenID, Shibboleth (Web SSO), SAML (WebSSO), FaceBook, Yahoo! and Google, to name a few. These protocols differ in many details and have different strengths and weaknesses but they all share the same underlying HTTP Redirect mechanism. The basic pattern is this:

1. Jane navigates to a web-site and she wants to log-in using a username and password that support SSO.
2. Jane clicks on the 'login' button on the page.
3. Jane has to tell the web-site who her SSO service provider is. This is known as the Where Are You From problem, otherwise known as WAYF. More about WAYF in a moment.
4. Once Jane has told the web-site who her SSO service is; a HTTP Redirect is sent to the browser to send Jane off to her SSO service.
5. At her SSO service Jane is asked to provide her UserName and Password.
6. If Jane convinces the SSO service that she is, in fact, Jane, then she is returned (via HTTP Redirect) to the original web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
7. The web-site and SSO service communicate in such a way that the web-site can validate that this is really SSO service XYZ talking AND if it knows and trusts service XYZ it can go ahead and accept that this is Jane.
At this point we have performed 3rdParty Authentication or Federated Sign-On NOT SSO.

8. Having done what she came to do Jane now navigates to another web-site.
9. When Jane arrives at the second web-site she is NOT recognized as being logged in. This site has no knowledge who she is or that she has logged in somewhere else before. If Jane wants to access 'protected' resources at this web-site she is going to have to click on the log-in button.
10. Again Jane will be asked Where Are You From and she will select her SSO service provider.
11. The web-site will then send Jane off to her SSO provider asking... "Who is this?"
12. Because Jane logged into her SSO service just a few minutes earlier the SSO service doesn't ask Jane for a UserName and Password this time, it immediately returns back to the web-site with a 'token' that says "I am SSO service XYZ and I believe this is Jane"
13. The using the same trust validation as above the web-site can now believe that this is Jane

And Jane only logged in ONCE... that is SSO.

Jane still had to click on login twice and still had to provide her SSO service twice but she only Signed-On a Single time.

There are variations in this flow, OpenID nicely shortcuts the double SSO service provider selection BUT you have to type in your UserName twice.

The most common expectation of SSO that is not satisfied by the flow described is "why didn't the second site just 'know' that I had already logged in and who I was?" Apart from the fact that would be technically difficult the answer is actually that REALLY you wouldn't want that behavior... Once I explain why:

If SSO worked that way, when you logged in once, everywhere you went on the internet would know who you are. Not just an IP address, they would be getting a message "here's Jane". All of the web-sites on the web could talk to each other and work out EXACTLY which sites you visited and which ones you didn't. That is generally considered to be a terrible breach of privacy. In order to avoid this privacy leak clicking 'login' remains an explicit action that the user must take. The action no longer means: "I want to enter my username and password" but now means "I'm OK telling this site who I am."

There are ways for 'closely connected' sites to shortcut this experience. Handing a user from their Local Library System to the Consortia Meta-Search interface; a handoff that is between trusted parties; Janes identity CAN be passed from one service to the other providing the 'seamless' SSO that we would love to have. But you can't be sure that Jane was OK being identified at the second system unless you make the action explicit. As a service provider you have to make very careful choices between seamless SSO and user privacy.

Rather than going on now:- You can tune in later for "SSO using Pair-Wise Identifiers to protect your privacy", "How and Why OpenID is different from Shibboleth Web SSO" , "Why you MUST trust your SSO service provider because they know a lot about you"...

Please ask questions if I haven't been clear... Please let me know if you think I have said something misleading or wrong... I'm just trying to start a conversation here.

Tuesday, February 10, 2009

IDM 101

I am now blogging at I am going to be posting a series of posts that introduce basic Distributed Identity Management concepts, as I understand them.

I can't decide if I should double post those posts here as well:

reason to post here..

although it is all basic stuff I am interested how much my understanding and articulation of the basics aligns with your understanding.

reasons not to post here..

if you want to read the stuff over there... you can just get that feed too.

What should I do?

Monday, January 26, 2009

What's in a claim?

The use of infocards does not dictate a specific authorization pattern. There are at least 3 authentication patterns at play that I can see... Identification, Roles based and Claims based... We can, and do, use all three of these interchangeably and simultaneously. I will explain what I think these three patterns are:

Identification:- Provide a previously know ID that relying party can resolve to a user record that has all of the additional information needed to make permission decisions. In this case only one claim is ever needed... the ID as one assumes that ALL other information is in the user record. The major problem with this pattern is that sharing the same ID between different relying parties is often impractical and definitely bad from a privacy standpoint. Using pair-wise PPIDs does not really satisfy the Identification pattern as all you are enabling is the ability to say "this is the same person as logged in as before" but not get a lock on a user record (unless you do a mapping at each RP which is probably the BEST application of this pattern).

Roles Based:- (See: ). With Role Based Access Control (RBAC) you don't need to know who the 'Subject' is; you trust the IDP to enforce policy and assign the roles and the RP simply has to present the functionality and access based on the roles provided. The major, known, problem with classic RBAC is that it fails to address either resource or person specific access control. There is lots written about this failing so I will refrain from going into details :-).

Claims Based:- With this pattern all of the information that is needed for the RP to enforce policy is presented to the RP by the IDP. This includes not only the claim values but how the claim was established. Sometimes knowing that the IDP is willing to assert something to be true is enough to trust it, at other times you want to know that the 'Over 13 years old' claim was based on a more rigorous check than... "they checked a box that they are over 13". Claims based authorization becomes especially powerful, IMO, when you take claims from multiple claims providers so that you can do uniquely specific authorization and service delivery at each RP based on a Claims Network.

Classically websites have used 'Identification' to authorize users. A user logs in and the relevant record is found in the database. RBAC has been widely deployed in Enterprise type settings or in 'tight' federations; where the IDPs and the RPs can collude to agree on Role names and Role interpretation. Claims Based authorization is the solution that is growing to address the needs of a distributed authorization framework or 'lose' federations.

Roles are probably defined in the context of a 'vertical' (industry, community, academic practice, etc..). Claims are the raw data about the subject and 'tend to be' as objective as possible so that the consumer can apply its own policy.

I personally believe that Claims Based is a powerful way forward and should be embraced, however, we also need to be realistic and pragmatic. In cases where there is a known tight relationship between the IDPs and the RPs mixing these 3 patterns together seems expedient. There is no point going to great lengths to build zero-knowledge identifiers if you KNOW that each relying party is going to then require an email address (unless you are also confident that the users have mechanisms to deliver and manage zero-knowledge email addresses).

SO.... specifically....

* I think that the Library Community is homogeneous enough that we can define so mutually agreeable Roles, like the ones you suggested.
** Faculty (Academic libraries)
** Staff (all types of libraries)
** Student
** Adult
** Young Adult
** Juvenile

* Where needed, service providers can establish mappings between PPIDs delivered by the infocards and internal IDs for Identification.

* ILL and Electronic Resource Delivery (eBooks) will require Claims Based authorization to augment the Roles so that the systems know not just that the user is a patron, but that they should have access to 'this specific eBook' from 'this date to that date'.

So the delivery mechanism that we are using, ws-* / Information Cards, IS a Claims Based framework, BUT, we are using the framework to deliver claims to enable all 3 authorization patterns.

Do you agree?

Tuesday, January 20, 2009

The winner is:

As you know, I have been trying to decide how I think we should model the ‘roles’ claims for the ICF’s pilot Library Card project (see my last post: The Claim Game). I have talked, emailed and blogged with a bunch of people who have opinions on the subject and have come to the following conclusions.

Off the point for a moment: There seems to be some consensus that if the policy description and interpretation step that goes on between the relying party and the ‘selector’ was richer then we may have better options open to us. However, today the Information Card specification is what it is and I don’t recommend putting a hold on our project in the hope that it might change.

The options that we have are either to have a single ‘roles’ claim that contains a list of the roles that the user has been granted, or, to have separate claims for each role. The separated claims could be on different cards but I see that option as being basically the same as option 2.

Having thought about this a bunch I think that the better option is option 2, a separate claim for each role. This will force us to formalize and standardize the role names, which is not ideal, but, it provides the best privacy protection and ultimately the smoothest user experience. While the user experience may be a little more complicated on the face of it, I believe it is superior because it will be predictable.

With this option the presence of the claim indicates the assignment of the role. The value of the claim is basically ignored, as it is in the selectors’ card selection process. If a resource indicates a specific role or set of roles that must be present to gain access; only cards capable of satisfying the policy will be presented as selectable cards.

I look forward to hearing why I am wrong :-)