More about Federated Identity

In my last post about federated identity, I mentioned that one of the biggest problems facing any implementation of an identity federation is that all of the participants need to be using the same standards and protocols to achieve federation. Unfortunately, as time has progressed a number of different standards have emerged. This is not a big issue if you’re starting out from scratch and all of the applications that are being developed are being built in-house. As long as all of the participants within the federation can agree on a standard, integration issues are unlikely to arise. However, this imposes serious limitations on future scalability. It denies members the opportunity of integrating with applications developed around a separate standard. It also means that all entities, wishing to join the federation in the future, will have to conform to the same standard. With this in mind, you either want to choose a standard that is widely used, or you need a means to integrate across standards. So what are your options?

To start out, it is worth mentioning that as federated identity matures as a concept, many applications are capable of supporting the plethora of standards that have already emerged. Furthermore, there is already a convergence trend that is emerging where standards are slowly being redefined to be more ineroperable with each other. And this is largely down to the work of the OASIS group, with the SAML specifications; and Liberty Alliance, who have developed the ID-FF specifications along with ID-WSF. These separate standards have become increasingly intertwined with each other and the distinctions between them are slowly fading into history.

On the other hand, WS-Federation, a standard originally backed by Microsoft, still stands apart and provides its own specifications on how federation should be achieved. So, in effect, the choices between standards is now really about choosing between the SAML/Liberty specifications or the WS-Federation specification. Either way, more and more applications are trying to overcome these splits by simply offering support for all of the options out there.

Certainly, the Symlabs Federated Identity Suite has catered to support all of the major standards so that integration with new federation members and their associated web applications no longer requires that you come to terms with the differences between the specifications. But Symlabs is not alone in this move, and other vendors such as Ping Identity with their PingFederate product are also focussed on providing these sorts of integration options.

So, when it comes down to developing your federation infrastructure, you have a number of options available to you:

• Develop a proprietary solution from scratch, ignoring all of the standards and specifications that have already been created. This clearly has a load of pitfalls and your integration options are going to be few and far between.
• Use a set of open source libraries built around one of the standards to develop a federation architecture from the ground up. Not only is this likely to be very time consuming, but you are likely to find that many of the open source options are still heavily under development and you’re going to lack much of the functionality that is available in the specifications. Furthermore, you’re going to have to work out which specification you wish to support.
• Use a standards-based Federation suite to implement your core architecture. There are a number of commercially available suites that provide you with everything that you need to build a standards compliant federation that supports all of the major standards. Most of these suites will provide a range of functionality that can be used right out of the box.

Okay. So, it sounds like I’m trying to sell Federation Suites. Yes, and no. In relative terms, Identity Federation is still very young. There are a lot of options out there that make it very difficult to move forward confidently. So, in many ways, making use of a commercially available suite is not a bad option. And from my perspective each of the major players in this market have different things to offer. I know that Symlabs, with its involvement with Liberty Alliance, has a strong focus on implementing a wide range of built-in functionality by taking advantage of the Liberty WSF specifications. Other vendors may cut back on functionality to focus on usability. It is well worth researching any product thoroughly before committing your entire infrastructure to it.

But for the little-guy out there, forking out large amounts of cash to simply achieve SSO might not be a possibility. Is OpenID an option? How does it differ from the other specifications? Can I get the benefits of a true federation using OpenID? These are questions worth exploring. The sudden clamour around OpenID is bound to bring change to the identity management market, and it cannot be ignored. I will try to look at OpenID in more depth in my next post.

Introducing Federated Identity

I guess I should just dive in at the deep end and start writing about something that I have been working on for a little while recently, so in this post I want to talk a little about federated identity. The other day, I wrote a tutorial for Symlabs Federated Identity Suite. Instead of launching into a practical demonstration of the product, we decided that we should present an overview of what federated identity actually is. I’m quite proud of the tutorial, largely because I got a complete non-techie to sit down and read it and then to explain to me what she thought federated identity was all about. When my friend had finished, she was able to get into a pretty in-depth discussion about identities, federation and the problems that federation seeks to overcome. But the thing that really got me excited was that she was actually interested in what we were talking about, and without realising it, she was coming up with a multitude of questions about security in general. For somebody who battles to use a mobile phone, let alone a computer, to be interested and conversant about the topic was truly inspiring. And in part, motivated me to sit down and create this blog.

The more I work on documentation revolving around identity management, the more I become aware of how little there is for the average person on the street to grasp. There is a multitude of protocols, standards, acronyms and jargon words that fill every document out there. But when it comes to high-level documents with illustrations and use-case scenarios, it often feels like you hit a brick wall. I don’t think that’s because the technology is so difficult to understand, but more because the people developing the technology aren’t aware of how confusing their documentation can be to the average lay-person.

I’m going to try to summarise things here as simply as possible, and in future posts I will try to get a little more detailed about things as we move along. So lets start out with what Federated Identity is all about.

Most technology is about solving problems. We make things to make things easier. Federated Identity has developed as a technology for precisely this reason. There are a whole set of problems that are associated with online identity data as it stands today. Here are a few examples:

• You have at least twenty login credentials that you need to use to access various websites and services online. In my case, I think I have a few hundred.
• Because you have so many accounts in different places, you often use the same username and password combination to keep things simple. And often you use easy to remember combinations that are not always secure.
• For each service that you make use of you store a whole bunch of redundant data. You’re constantly entering your Name, Address, Phone number, Email Address, etc etc. If you move house or change email address or phone number, it is an almost impossible task to update this data on every site that you access.
• You enter your credit card details into multiple sites, and you cannot be sure that this data is being stored in a secure manner.
• You often have very little control over who has access to your data or how it is used. This leads to problems like spam, and even to identity fraud.

I’m sure I could come up with a longer list, but you should get the idea pretty quickly from the points above. The problem is really that in order to provision us with the various services we want access to, sites need access to data about us. As this data becomes more distributed it becomes increasingly difficult to manage, and it becomes more likely that this data may be used in an abusive manner.

Federated Identity seeks to solve a lot of these problems by providing a means to use one login account to authenticate at multiple sites. It seeks to eliminate the redundant storage of identity information by allowing members of a federation to access data within different repositories across the federation. And it seeks to allow users to have more control over the data and the way in which it can be used.

In order to get some perspective on this, lets talk a little about Single Sign-On. Within companies and organizations, there are usually a variety of systems that users may need access to. Managing the login accounts for each system separately would be a nightmare. So there is usually one central database where your username and password are stored. By centralising the storage of your username and password, you only ever need one username and password combination to access any system. If you update your password, it is updated on all the systems in the organization. That already makes your life a lot easier. But if you’re having to enter your username and password all day, accessing different systems, things start to get a little tedious. So, to make things a little easier, your organization may implement some form of Single Sign-On. I’ll try to explain this with an analogy.

Imagine that you are visiting an office, and at the front desk is a security control point. In order to enter the building, you are required to sign in. Now, because you are likely to be coming in and out of the building frequently, you are given a temporary security pass. So, you sign in at the front desk, and you are given your security token that you will now be able to use to access the building for the day. Single Sign-On works in a similar way. When you login for the first time, you recieve a token which will represent you for all of the systems within the organization. Instead of having to login repeatedly, you simply present the token, and the system that you require access to will check to see whether that token has already been authenticated. This way, you can login once and then make use of all of the systems within the organization without having to login again.

This is all very well if you’re talking about a single organization. But to return to our analogy, what if there are multiple buildings down the street that I require access to during the day? Identity Federation attempts to overcome this problem in the following way. Imagine that one or more of the buildings in the street provide an identity service. You can go into any of these buildings at the beginning of the day and sign-in. You recieve your security token and you can go on your way. At any of the buildings you need to enter, you simply tell the front-desk to check your token with the building that you signed in at. As long as you have your token and the identity service provider knows about you, you can enter any building on the street.

This opens up a range of possibilities to you. For instance, through your identity provider you can control which buildings you have access to at any point in time. You can control how much information any of the other buildings have access to about you. And you can cancel your access to all of the buildings in a single step.

Let’s leave the analogy behind for a second and get back to the real world. What are some of the real advantages of this when it comes to online or even offline interactions. And can it really offer improved security? I’d like to consider how this could be used by various interlinked governmental organizations in a way that could help to secure information about me and allow me to have a certain amount of control over who gets this information. Let’s assume that my government is in control of a National Health Service, an Inland Revenue Service (or disservice, if you dislike paying taxes as much as any person), and Drivers License and Vehicle Registration Services (e.g DVLA in the UK). For each of these services, I want only one set of particular information stored, such as my Name and Address etc. This way, when I move, I can update my details for all of these services at once. However, I do not wish for the organization that is responsible for my Drivers License to have access to health data about me. Nor do I wish for the Inland Revenue to have information about my Vehicle Registration. By federating these services, I automatically gain a number of advantages. Firstly, I am able to authenticate online for all of these services using Single Sign-On, and with a single username and password. But more importantly, only one of these organizations holds any identifying data about me. This adds a whole layer of security to my data. Lets assume that I choose to use the DVLA as my Identity Provider. If somebody at the National Health Service accesses my medical records, there is nothing that personally identifies me stored at the Health Service. Furthermore, if the Inland Revenue site is hacked, none of my personal details are stored there, either. Equally, if I discover that someone has somehow got hold of my username and password, I can contact the DVLA and prevent access to all governmental services as well as change my username and password for all sites at once. In a federated environment, it is less likely that crises such as the one that affected 25 million Britons last year, would happen.

Certainly, talking about governmental control over personal data is a touchy subject at the moment. But the concept can be applied to businesses that enter into partnership and want to share certain resources for their employees. Equally, certain businesses may want to be able to share resources for their customers. Imagine that you wish to buy a ringtone from a website that is in federation with your mobile phone provider. You login to you service provider’s website, browse over to the ringtone website, and without having to enter any personal details or even authenticate a second time over, you can purchase the ringtone in the knowledge that the ringtone provider does not have any personal data about you!

This might all sound a good idea in practice, and certainly it is easy to think up situations where organizations might like to enter into a federation. However the main hurdles aren’t necessarily about agreement between parties, but rather on the methodology that can be used to implement such a system. And this is where Federated Identity Management gets tricky.

Over time, numerous security issues and data exchange scenarios have been discussed and worked through by various different bodies dedicated toward coming up with feasible ways to achieve federated identity. One of the big problems that confront people who are considering federated identity, is that there are a number of different ways of achieving it now, but in order to get anywhere all of the participants need to choose the same method. Or there needs to be a way of integrating all of the methods to work within a single environment.

I’d like to get into this in more depth, but I will leave this for another article… I think I’ve done a fair amount to introduce the topic, and hopefully put it into a language that anyone can understand. Come back soon, and I promise I’ll get into some more detailed stuff soon. Meanwhile, if you have any comments, feel free to leave them below.

Au revoir

Hasta luego

Totsiens

and Goodbye.