The Case for Federation and SSO

To date, the vast majority of real-world federation roll-outs have been internal or enterprise type deployments. Things like an enterprise authenticating its users out to an outsourced provider (such as a Fidelity 401K, or AOL's Radio Service). Yes there are many exceptions to this general statement (you can see many of them on Liberty's Adoption Page), but that is the general view of the industry and I certainly don't knowingly use federation in any cross-provider operations.

The time has come for federation and Single-Sign-On to be adopted in a more general fashion. I say this for many reasons and hope that the various vendors and providers out there will not be stubborn and/or resistant about it. I think this is valuable to parties that will wish to assert identity. I think this is valuable to the people who will accept identity federations and I think this is valuable to the users themselves.

When I say it is valuable to the user, I don't mean the often quoted "that way you can reduce the number of passwords you need to remember" -- though I still think that is a reasonable benefit. The real value for the user is that they will be able to share their data across multiple providers without the need to give their credentials to the other party.

Examples that already exist today include:

• On LinkedIn, if I want them to pull my contact information from my contact book in several mail services (e.g. GoogleMail, HotMa il, etc.) I have to provide LinkedIn with my username and password on the mail service. LinkedIn logs in as me (either through their web interface and does screen scraping, or directly via an exposed web service) and extracts my contacts. Since I gave them my login information, I'm hoping that they don't do anything wrong with the data (like expose it), and that they don't mis-use the access to my account (e.g. sending spam in my name).
• On Etrade, when I want to setup a new bank account for transferring funds from my Etrade account, one of the options provided is for ETrade to be provided with my username and password for online access to my bank account so that they can verify that I have control of the account and that it is in my name. Like LinkedIn, I'm hoping that they don't do anything wrong with the credentials while they have them (and in the case of ETrade, hoping that they do not store them like they claim they won't do).

I could go on with this list, but you get the idea. The user is already federating their data together across different providers. It's just in a very broken way that can lead to cascading security failures as any security failure at one site can lead to security failures at other sites.

With federation, I wouldn't need to give my credentials to LinkedIn. My mail provider could also differentiate the access provided (letting LinkedIn see the set of contacts that I chose to share with LinkedIn without being able to send mail in my name or being able to change contacts). LinkedIn could maintain that federation so that they could periodically check for updates. A break-in at LinkedIn would mean that someone could perform the same operations that I've already OK'd for LinkedIn -- get the data that LinkedIn already has -- so no additional exposure.

Why would GMail, HotMail, or even my bank, want to do this? First off, they are already doing it in an insecure way (I can always give my login credentials to the other party) and with the expanded access at their service. This would be a much better solution from a security and least priviledge point of view.

Another issue that might be raised with regards to the service providers is why would they want to expose a web service with this data. In many cases that's a new thing for them to do. But I think it's worth it becuase today, when they don't expose such an interface, theh other parties just walk though their standard user web interface and do screen scraping of the data -- I'm sure that data via a web page is more costly than exposing it through a programmatic web service.

Of course, LinkedIn would want to do this as they already do, but within the restricted capabilities of today that open them to some liability as well (should my data be misued at their site).

While I spoke heavily about LinkedIn in this post, this clearly applies to any and all cases where I want to do things across sites -- this is becomming more and more important in the Web2.0 world more interesting applications join togetether information from various parties. I can see how Dopplr would want to access my LinkedIn account to get my list of friends to pre-populate my traveling buddies rather than me having to establish new connections. I can also see how Dopplr would want to get access to my United Airlines itineraries so that they could auto-populate my trips.

The list goes on and on and it's a win-win-win for everyone, users and providers.

You might then have the decision as to what token format one should use for the federation and what web services structure one should use for the service access. I, of course, would recommend SAML and Liberty's Identity based Web Services Framework (ID-WSF), respectively, but that isn't as much the issue as is getting this up and running for the users.

You might notice that in this case, I haven't been advocating a large Circle of trust with centralized IdPs. Most of the examples I gave were point to point federations where, essentially, the relying parties and the IdPs were the same entity. The advantage with this model is that you have no need for extended business agreements so it's much easier to roll out. I do think that as more and more people start adopting and using this, it will be a natural evolution to environments where there are separated IdPs and Relying Parties, but we don't need to start there.

Tags : identity / federation / linked-in / ETrade / UAL / United Airlines / SAML / Liberty / Liberty Alliance / ID-WSF

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

Dick and Conor

Today, at the European Identity Conference, Dick Hardt and I (as well as several others) participated in a panel on user centric identity in the enterprise. As I had suspected it was a fun session with lots of back and forth and a very interested audience.

What amazed most people who know us was that we actually agreed on several issues and Dick was quoted at least twice as saying something along the lines of "As amazing as it seems, I agree with Conor on this" and we even shook hands once (luckily no one in the audience had their camera ready for the historic moment).

The kinds of things we agreed on included:

• Users should be able to control the use and dissemination of their data.
• Users should be able to allow an agent (local or perhaps in the cloud) that can interact on their behalf in between authoritative issuers of attributes and relying parties.
• Users should be able to allow direct access from some relying parties to some issuing authorities (specific example discussed was around someone accessing my calendar service to add an appointment).
• Strong authentication is separate and distinct from strong identification.

We only had an hour on the panel and could have easily gone on for another hour or two with a very participatory audience.

Tags : identity / user centric / federation / eic2007 / enterprise

Federated Authorization #3

In my previous article on Federated Authorization, I wrote:

In any case, I think there are problems with the basic premise of federated authorization. If you look closely at the various posts in regards to this question, they all talk about how you can do remote or delegated authorization. This is typically done in a model where an enterprise or service company will have some central authorization service that maintains the set of rights that their customers have.

This isn't a federated solution in that the decision as to the rights afforded the user is not delegated to a foreign entity. Even in the shibboleth model, where a student at university A is granted access to a resource at university B, the authorization decision is made by university B (yes, it's based upon the federated data that the student is a student at university A, but the authorization decision is made by university B).

And James McGovern commented with a question:

I posted in subsequent postings real scenarios where authorization is federated. Shekhar Jha had also chimed in on those which provided a good perspective. Did you get an opportunity to check out the scenarios I posted?

Referring, I think, to these articles:

Consumer Perspectives on Federated Authorization, Federated Authorization and Relationship, and Even More thoughts on Federated Authorization...

These all bring out good examples of some form of delegated authorization (and in the consumer use cases, what I would call federated authorization since you are likely crossing security domains).

While I think that many, if not all, of these use cases are interesting, I think that the model has some issues that prevent its widespread adoptions including:

• The range of settings for permissions at any one resource controller are vastly different from one instance of that type of resource to another, thus substantially raising the complexity of any centralized management infrastructure.
  

  For example, given the "authorize my lawyer to pay my insurance bill" scenario, I not only have to authorize him access to my bank account, but to extract money for a particular purpose and probably with some limits on the amount. How also do I differentiate between paying a bill and paying a co-payment or deductable?.

• The complexity for a good user understandable interface for interacting with such settings. I just don't think that we're even close in the realm of computer/human interfaces to provide a generic mechanism that will allow a central server to have the knowledge and understanding to walk the average technologist through the process. less alone my mother.
• There are a lot of privacy considerations around a centralized authorization entity (much more so than a centralized identity entity). This one entity will not only control all of my authorizations, but will also have the knowledge of what authorizations I have made. In the early days of the Liberty Alliance work, much thought and energy went into minimizing the knowledge of central parties -- that's why we have segregated service instances into groups of related data (rather than one know-all service provider), that's why we don't have the IdP involved in every message from a Web Service Consumer (WSC) to a Web Service Provider (WSP)(yes, through the Discovery Service (DS), the IdP can know that WSC wanted to talk to a particular WSP, but whether or not they spoke and what they spoke about is not visible to the DS nor the IdP.
• Doing authorization remotely can have a significant negative performance impact. This comes from the messages necessary to obtain the Authorization information, the caching of said information (without some form of caching, you're really in the dog house of performance) and the parsing of said information on each access. An internal authorization solution can be optimized for the resources being accessed and even tied to said resources within the internal database of the application. Such tight coupling is very hard to do, if not impossible, when receiving authorization statements from remote parties.

Shekhar also pointed out the "Authorization Push" model which has the same issues plus the issue of somehow figuring out at push time, the policies that the recipient will be interested in. I tend to favor push models when the information necessary at the recipient is easily known in advance. With complex authorization policies, the only way to support push would be to push the entire policy -- something that can be very expensive from a bandwidth and processing overhead point of view.

Another problem with the push model is that it assumes a single identity in the interaction. However, when I go to access Paul's photo service, its his service that needs to get the authorizations from his authorization pool, not from mine. I don't think push works in that environment

I'm not normally the pessimist... I just think that in this case, a distributed authorization model is a much better solution. Tight, application specific authorizations (such as "can James add a comment to this article on my blog") are kept with the resources being authorized. Loose, granular, cross-application authorizations (such as "can James see my blog") are more suitable for some level of centralization.

Tags : identity / federation / authorization / liberty+alliance / liberty / rbac / xacml / id-wsf

Federated Authorization

Last week, James McGovern posted comments on a number of blogs trying to stir up some conversation around the concept of federated authorization. There were several responses including one from Pat, Paul, Pat again, Gerald, and myself.

The comment was simply:

Does Federated Identity sometimes require Federated Authorization? Would be a great topic for your next blog entry...

A seemingly simple question. James followed up with his own post making it look like we were responding to some article he wrote on his blog and claiming he already new the answer to that question, but what he really meant was:

The perspective that I was actually seeking wasn't the architecture viewpoint but more of why industry thought leaders aren't talking about authorization and the over-abuse of the term identity management as a catch-all term and how these two problem spaces should become coupled in terms of the conversation.

I'm not sure how anybody could have gotten that out of the question above.

In any case, I think there are problems with the basic premise of federated authorization. If you look closely at the various posts in regards to this question, they all talk about how you can do remote or delegated authorization. This is typically done in a model where an enterprise or service company will have some central authorization service that maintains the set of rights that their customers have.

This isn't a federated solution in that the decision as to the rights afforded the user is not delegated to a foreign entity. Even in the shibboleth model, where a student at university A is granted access to a resource at university B, the authorization decision is made by university B (yes, it's based upon the federated data that the student is a student at university A, but the authorization decision is made by university B).

I think that is a common model and I don't see companies giving up the rights to authorization to foreign entities.

That said, I do see the value and benefit of having support for an remote authorization service, especially in an environment where there are many customers with many different levels of authorization at many service endpoints. The diagram below is from a presentation I made in October of 2005 at a Liberty Alliance workshop in Tokyo, Japan.

The issues around setting this model up are non-trivial. Essentially you need to be able to, on a service-by-service basis, define a set of knobs controlling access rights to each service and the valid range for those knobs (for example, an internet radio service might have knobs controlling the number of stations that are available to the user, the quality of those stations, and the number of endpoints from which they may listen simultaneously).

This type of model allows separation of the package definition (a sales/marketing issue) from the implementation of the service access (a development issue). The sales team can change packages fairly easily without impacting the development team (unless, of course, they need a new knob). This does put a lot of onus on the design of the knobs such that they allow the sales team to develop the appropriate service packages, but it's a big win when done correctly.

In an enterprise, this solution will present the same set of issues that come up with any RBAC implementation - the multitude of roles that need to be managed and the individual approvals necessary to allow the addition of access rights to a particular service within the enterprise. I think it's still doable with the knobs/settings paradigm, but given the "need to know" controls necessary for the privacy of employees and the protection of corporate trade secrets, the result is a vast multitude of yes/no knobs.

Tags : identity / federation / authorization / liberty+alliance / liberty / rbac / xacml / id-wsf

Federated Identity and Federated Authorization

I guess James McGovern got his wish via his multi-posted this comment across a number of blogs (Paul, Pat and Eve's in addition to mine):

Does Federated Identity sometimes require Federated Authorization? Would be a great topic for your next blog entry...

At first I had thought I was the only such person (that I was special in some way) and I had started working on an article around this subject, but alas that wasn't the case - this was just a SPAM comment sent out in a shotgun approach probably to even more people than I mentioned above. However, it did raise an interesting question.

Pat first responded with a nice summary of two models for authorization.

Paul later responded with a nice article talking about the P*P entities (although I had thought it was XACML that had popularized the P*P, not SAML).

While I like both of their answers and don't disagree with their content, neither of them explicitly answered the question (I think they did implicitly, but not explicitly).

So, I'll jump in there and say that the short answer to the question posed is "No". Federated identity never requires Federated Authorization. A resource owner may require remote policy decisions (which is what I would call federated authorization and fits into Pat's 2nd model) or they may simply require federated attributes (sometimes just an identity handle for the user). It's all an implementation decision for the owner of the resource that's being accessed.

That said, I would say that the reverse is true: Federated authorization does require some level of federated identity (the authorization statement is a piece of identity that is passing across to the relying party).

Tags : identity / federation / authorization / saml / xacml