It has been some time since I have had a chance to write anything for my blog. This doesn’t mean that I haven’t been keeping an eye on the odd posting on a number of my favourite work-related blogs, and I couldn’t help notice the sudden spate of comments in response to a series of posts by Ashraf Motiwala

There have been many intelligent responses to this post, and for the most part I had no intention to get into the debate. That was until I noticed a post titled “why cache and virtual directories???” by Tim Paul. In this post, Tim argues that using a cache can help reduce a significant amount of lag that he believes could potentially result from using a VDS in front of a backend data repository. Tim’s argument is a mathematical one that seems very logical. However, what his argument really brings to light, is his own lack of experience and understanding of how these systems work.

Let’s first look at how Tim presents his argument.

• I have a directory that performs at 5000 q/sec, roughly equivalent to .2 milliseconds per query
• The VDS will add, at least, a 2 millisecond “overhead”
• Each query will now take 2.2 milliseconds to complete
• Now instead of 5000 q/sec when I access my directory I get only 455 q/sec
• Therefore, to remove the 2 millisecond overhead and to return to optimal performance it is necessary to implement a cache.

At first glance Tim seems to have presented a thoroughly convincing argument for using a cache. Tim argues that queries will be resolved 11 times slower than if they were handled by the data source directly. If making use of a VDS results in such a dramatic performance hit, it stands to reason that using a cache is the only way out of the doldrums.

What Tim has failed to include in his reasoning, is that all of these systems process queries asynchronously. By calculating the speed of each query at 0.2ms (a ridiculously low figure for any TCP transaction) based on the 5000q/sec figure, Tim is assuming that the queries are treated synchronously, which is never the case. Tim goes on to add the 2ms latency for the VDS system to each query. This assumes that the VDS, along with the backend, is treating each query synchronously, resulting in a massive performance hit. Of course, this scenario is somewhat absurd, and if this were the case then caching would seem to make a whole lot of sense. However as all of these systems work asynchronously, the math of Tim’s argument does not hold any water at all.

Tim goes on to argue about the freshness of data in a fairly flippant manner, suggesting that most organizations will not have a problem if identity data is not up to date within their applications as a result of the cache. Bizarrely, Tim suggests that having incorrect data for anywhere between a few minutes or hours should be acceptable to most organizations. After his scatheing and somewhat misguided attack on the performance hit resulting from the use of a VDS, it seems odd to suggest that it is somehow acceptable for data to be wrong for significant lengths of time. I know that when designing an application I would like to know that even if it took a slight performance hit, it was always working with the correct data. In Tim’s world, it seems okay that things are wrong sometimes, and perhaps this is the same approach he applies to his math.

Perhaps in this post I have shot across the bows and made some fairly hard statements, but in reality the sort of misinformation that, all too often, gets circulated on these sorts of topics is damaging to a genuine understanding of how these systems work and what they are capable of doing.

In my last post, I promised that I would have a look into OpenID as an alternative means of setting up and Identity Federation. While this is a small adventure away from my usual home among the more established specs, OpenID is not so distant that I haven’t already been sucked in by the hype and made use of it already. So is OpenID a real alternative that can be used in the enterprise as a means of achieving SSO and of provisioning user data across a federation in a secure manner?

The answer to this question is a little convoluted, so I’ll start out by quoting Andy Dale, who says: “In my bitchier moments I have been heard to say… “OpenID; brought to you by people who didn’t want to read the SAML spec””. And in many ways I agree with him. OpenID has burst onto the internet like a wild horse, and is rapidly gaining popularity. Certainly, it has wide adoption as everyone from Google to Facebook attempts to fight out the battle to become worldwide identity silos. But realistically, OpenID is a relatively immature approach to identity management and as such, many of its specifications are under revision. As Andy points out, it is likely that over time the OpenID spec will evolve into something that is fully SAML compliant.

Part of OpenID’s success has been that it is built around an “easy-to-setup, easy-to-use” framework. From an end-user perspective it is ridiculously easy to set up an OpenID URI and get busy logging onto any site that accepts OpenID as a means to authenticate. Administrators and developers find it exceedingly simple to build their own OpenID systems, and certainly there are a number of ready-to-use systems already out there, that can be fired up on any webserver and be home to your OpenID users.

Of course, there are a number of downsides to all of this promiscuity. As Paul Madsen, one of the Liberty Alliance architects, has pointed out on his blog, as Service Providers require more security in their transactions with an IdP, they will become more discerning or selective in their choice of IdP. This means that to login to your favourite blog, it is unlikely that there will be too much selectivity over your choice of IdP. However, your bank is more likely to be deeply concerned about which IdP you make use of, and will limit your selection to those that it has approved.

And this is largely where the split between OpenID and SAML lies. OpenID provides a quick and easy method of achieving SSO. SAML is more complicated, but it is built around a robust security model that can be trusted by large enterprises.

In more simplistic terms, SAML is more applicable for handling identities within organizations that need to maintain control over user data, and which have security concerns. In essence, the organization needs to be able to determine who it trusts within its identity framework. SAML makes more sense in these environments, especially when coupled with other specifications such as those provided by Liberty Alliance, as it facilitates secure data transactions beyond the scope of SSO.

OpenID is more applicable to users outside of an organization who wish to achieve SSO within less security specific environments. These users want to be able to choose their own Identity Providers and have more control over their own data. Essentially, as Stefan Brands writes in his scorching critique of OpenID at The Identity Corner: “OpenID was designed as a lightweight solution for “trivial” use cases in identity management: its primary goal is to enable Internet surfers to replace self-generated usernames and passwords by a single login credential, without needing more than their browser.”

This is not to say that OpenID does not have a space in the world of Federated Identity, only that it caters to a different market. Perhaps it is best to think of OpenID in exactly the terms that the group behind it presents the technology: OpenID is a lightweight method of identifying individuals that uses the same technology framework that is used to identify websites.

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.

Just 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.

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.

Hi

I’m a technology enthusiast with a wide variety of interests. I have recently started working for Symlabs as a technical author, although I guess I wear a variety of hats. My first experiences on the Internet date back to around 1990, before the World Wide Web had become what it is today. Since then, my life seems to have revolved around technology in some way or another, and I have become increasingly passionate about it.

I have created this blog for a number of reasons. Firstly, I just wanted somewhere to put down any random thoughts that I have about technology in general, since I do seem to spend a fair amount of time thinking about it. More importantly, with the work that I am currently involved in, I feel the need to share some of the new technologies that I am being exposed to. I’m also inclined to try to find a way to present difficult technical ideas in ways that are more accessible to the average person on the net. A lot of the information that I deal with is very obtuse and even I find myself nodding off trying to wade through some of it. It is usually heavily jargonized and exceedingly complicated to read. Maybe the odd geek can really get excited about a new set of specifications or an RFC, but most people seem to glaze over just hearing the word ’specification’. I’d like to try to bridge the gap that I think exists between uber-geeks and the rest of the world, mostly because I find myself somewhere in the middle.

So, on one hand, this blog will simply be a place for me to comment on things that interest me, while on the other hand, I will also try to turn it into a high-level resource where you might find explanations of certain new technologies. Finally, I’m an honest person. I’m proud of the company that I work for and the products that we are developing, so I’m sure to plug Symlabs wherever I can. Of course, this is a personal blog, so anything I write is not vetted and may not express the company’s opinion in any way, but hopefully my upfront honesty and the articles that I write will help to convince you that this isn’t just another chunk of mindless marketing. I genuinely have things to share, and I want to share them in a genuine way.

Please come back and visit soon. I hope to put up a new article as often as possible.