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.
Posted by rowanp01 
Posted by rowanp01 
ID-DAP and ID-SIS
June 25, 2008Just a quick comment! I’m busy writing some documentation for the Symlabs Federated Identity Suite, and I came across a reference issue. Symlabs consistently used ID-DAP to refer to one of the ID-WSF specifications supported by the product. However, it seems that the Liberty Alliance group that has defined the specification refers to it as ID-SIS-DAP. To be fair, the specification is still relatively new, and the major contributors to the specification have been staff working for Symlabs.
However, it is worth bearing in mind that when searching online for references to the specification, you should probably search for both names.
To provide a little clarification on what I am referring to, the ID-DAP specification sets out a secure methodology for Web Service Clients (WSCs) to perform general data access operations within a Liberty Web Services Framework without having to reveal any of a user’s personal information. In essence ID-DAP standardizes the way in which WSCs can make data requests from WSPs. However, the WSP can use any protocol to retrieve data from the backend.
ID-DAP is useful for covering data requirements that fall outside of the rest of the ID-WSF services. Essentially, ID-DAP is an evolution of ID-WSF in that it can also be used as an alternative to most of the services as it allows for generic data access. That said, by adhering to the other ID-WSF service specifications you will find that it is easier to integrate applications that make use of services targeted to a specific concrete use, as you will be more able to predict the types of requests that these applications are likely to make. In general, the specific services defined in the ID-WSF specifications are easier to implement than ID-DAP precisely because they are less generic.