Export (0) Print
Expand All
Expand Minimize
This topic has not yet been rated - Rate this topic

A Sense of Identity

As of December 2011, this topic has been archived. As a result, it is no longer actively maintained. For more information, see Archived Content. For information, recommendations, and guidance regarding the current version of Internet Explorer, see Internet Explorer Developer Center.

Robert Hess
Microsoft Corporation

July 23, 2001


Authentication vs. Authorization
Authentication and HailStorm
Single Sign-In
Passport and HailStorm
Until Next Month

Who am I?

No, who am I—really—? Am I Robert, RobertH, RobertHess, HessRobert, H_Robert, RBH_1329? Or any one of another of the different user names I've had over the years. With all of the Web sites that have required me to create accounts for them, I often don't recall what combination of username and password I used for them when I first created my account. I'd of course just love to be able to use "Robert" as my user name on all of these sites, but we all know how futile that is. Just as I have to carry around more than a single key on my key ring, I need to remember multiple account names in order to utilize the various services that I've subscribed to on the Web.

For many years, businesses, operating systems, and applications have focused on the notion of a single sign-in process, where a user logs on to their workstation, and then as they execute various applications, or access servers and databases, they won't have to re-authenticate themselves. While each of these individual services might have a different authorization scheme, they share or trust a common authentication agent.

Authentication vs. Authorization

So let's back up a little bit and clarify the difference between authentication and authorization. When you stop and think about each of these, the differences are fairly obvious, but it can sometimes get confusing.

  • au·then·ti·ca·tion [aw·thént·káysh'n] noun:
    The verification of the identity of a person or process.
  • au·thor·i·za·tion [áwthr·záysh'n ] noun:
    To give somebody permission to do something or be somewhere.

Authentication simply implies the trusted recognition of who and individual is, while authorization is the act of categorizing what they have access to, and what they don't. A driver's license or passport, for example, is a form of authentication; it provides a mechanism by which you can associate an individual with additional tangible information that you can use to assist in some form of transaction. While a driver's license or passport doesn't identify if an individual can legally drink, it does list their birth date, and from that the business that is checking the authentication of an individual can then decide if they want to authorize them to order a drink. It is possible to authenticate somebody without any implied authorization, but it is difficult to conceive the notion of authorizing somebody for some purpose without also providing some form of authentication. Even simply wearing a CREW badge is a form of authentication.

The use of my username to log on to a Web site is a form of authentication, which in turn is almost immediately used to authorize my access to information on that site that is, perhaps, simply used to personalize the Web site based on my geographical location, or perhaps to allow me to order products based on credit card information that they have stored for me. To facilitate the authorization process, each Web site builds their own authentication service. Often, this takes the form of a database that stores a unique username and password that the user must provide in order to indicate that they are who they say they are. Since these usernames have to be unique, and since each Web site creates their own individual database, you have to make sure that you create your account as early on as possible so that nobody else has a chance to use your username before you do if you want to use the same username for all sites.

Let's map this scenario back to the drinking authorization example we used earlier. Imagine for a moment that every bar instituted its own authentication system. For every bar you wanted to go to, you would have to create an account so that on subsequent visits they could look up your account, verify the picture of you that they had on record, and then authorize you to have a drink. To look up your account, they assigned you a "name," which you would have to tell them the next time you visited. And since they had a fairly limited system, everybody had to have a unique name. The problem here is fairly obvious. Suddenly you would have to remember all these different names for every bar you visited. Thankfully bars accept a driver's license as an authentication mechanism!

Mapping the notion of a driver's license or a passport onto Web sites really isn't that difficult. There are multiple approaches for doing this, and there are several different companies that are already providing this type of service. Microsoft has been running a service for a while now that provides this sort of capability. It is called Microsoft® Passport Single Sign-In (www.passport.com), or just Passport for short. The name, of course, refers to the fact that it's like an identification passport that you can show at various places that you go in order to assure people that you are who you say you are. Specifically, it allows people to create a single username/password that will allow them to easily log in to any site that supports Passport authentication. The purpose of this article is not to describe the benefits of Passport, but instead, I want to help you understand the important role that Passport will be playing within the larger "HailStorm" set of services. (Remember that HailStorm is just a codename for an as-of-yet unnamed technology and service that is still under development.)

Authentication and HailStorm

As I discussed in a previous article, HailStorm will provide a set of personal information services that will allow you to store various bits of useful information that you can then access from virtually any Internet-connected device. Your calendar, address book, documents, and so on will all be easily read and updated. Obviously, since this information is of a personal nature, authorization of who can access it, how, and when, is very important. For example, you might want to allow your dentist to temporarily see your free/busy time on your schedule so that they can recommend the best time for you to come in for a checkup. Or you might want to allow your wife to have full access to your calendar, but perhaps not be able to see the appointment to pick up diamond ring at jewelers on your schedule next week. And of course you wouldn't want door-to-door salesman to see your free/busy schedule in order to know when to interrupt you at home to try to sell you something.

All of this has to do with both authentication and authorization. Core to the concept of HailStorm is who you are. Without being able to identify individuals, there won't be any way to allow the user to locate, much less unlock their own information. This makes it pretty obvious that just like any computer system or Web site that wants to coordinate a user with their information, there needs to be some form of user account database. HailStorm, however, is not a Web site, nor is it just some computer system that the user is accessing. It is an Information System that provides a searchable, scaleable, hierarchical, methodology for allowing a user to store, categorize, retrieve, and share a wide variety of information. This last point, share, is one of the critical elements behind HailStorm that is of particular interest, and also ties into the overall notion of single sign-in that we've been discussing.

For you to store and access your calendar, contacts, or other information within the HailStorm data model, you clearly need authentication to connect you to your data. This last Christmas, I ran into a Web site that allowed me to create my own personalized cards and have them sent out to all of my friends. Obviously, there needed to be some mechanism to allow this Web site to know the names and addresses of where I wanted to send these cards. Fortunately, they provided a way for me to export my address book into a CSV file, and then import that into their Web site. But first I had to manually filter down the CSV in Excel so it would reflect only those on my "Christmas Card List," and then once imported, there were a few addresses that didn't quite get read in properly, and this ended up in a few cards being sent out to wrong addresses. It would have been far easier if I was storing all of my contacts out in HailStorm and I could assign authorization to allow this Web site to be able to use my contacts for sending out my Christmas cards.

One issue in providing a three-party coordination of this nature is that the Web site that sends out my Christmas cards would need to be able to tell HailStorm who I am (and who they are) so that HailStorm would know whose data they wanted to see (and if I had authorized that access). The easiest way to provide this level of coordination would be through single sign-in process.

Single Sign-In

As we mentioned earlier, a single sign-in process is the notion that a user provides identification once to the computer, and from that point on any other system or application that needs to authenticate the user is able to do so by checking the existing authentication ticket.

One important concept here is that all of these other applications aren't seeing the users password, and in fact they aren't even seeing the user's sign-in username (username and password are often referred to singularly as credentials). Instead, they are evaluating an encrypted ticket that is part of the computer session. This ticket was created by a trusted authentication service, and by performing a secondary negotiation with this same trusted authentication service, the application is able to receive a unique Personal User ID (PUID) that it can use for identifying the user within their data stores. For the HailStorm services, this user PUID is used in combination with an applications own encrypted ID in order for HailStorm to not only know whose data is being requested, but also to know who is requesting the data. The application ID is important because the user is the one that is in full control over exactly who has access to the data, and to what degree.

Depending on the user's personal settings, they might want to be prompted for sign in as they navigate from site to site (or application to application). What happens in this scenario is that every time that the users go to a new site, the authentication service kicks in, and again, without the target application seeing the user's credentials, the user's credentials are requested over a secure channel. Then once the user is authenticated, they are allowed whatever access is appropriate by the Web site. The important aspect here is that the user isn't entering different credentials for each site, but instead is using the same credentials, thus removing the need for remembering a litany of user names and passwords.

Another benefit of a single sign-in process as implemented by an authentication service is that it makes it possible for the authentication service to layer on richer and stronger security measures, and the Web sites that use their service will automatically utilize these new measures without having to perform any upgrades. Let's imagine for example that some form of thumbprint or retinal scanning device becomes a mechanism that the authentication service wants to offer. They simply add the necessary code on their end, mark the participating users accounts as needing to be authenticated using one of these "bio-metric" devices, and from that point on, any Web site that was using this authentication service will automatically support that for sign in.

Passport and HailStorm

Today, Passport provides for single sign-in authentication. Moving forward, it will evolve into providing this process for HailStorm as well. Web sites that need to expose some form of user authentication can sign up today to integrate Passport into their architecture. The primary benefit that this provides today is that the user is able to retain a single username/password that they can securely use on multiple Web sites, and the Web site can use this for providing personalization and account storage. Passport itself is simply an authentication service. It isn't doing anything to indicate back to the Web site what information this particular user might be authorized to access; that is something that the Web site itself would be responsible for setting up. When HailStorm becomes available, it will also use Passport as the authentication service, and then HailStorm will implement its own authorization schema on top of this in order to provide the user with security over their data.

For HailStorm, Passport will be providing a very important triangulation point. It will form the gateway through which all information access will be funneled in order to provide a consistent and unique identifier that all participating applications can use for coordinating their information. Without this form of singular authentication scheme, the process of providing a unified method across the Internet for both identifying and securing individual information stores would require a level of complexity that would make it difficult for a wide variety of services to utilize.

I personally am looking forward to a time when Web sites and applications will be utilizing a single sign-in process for user authentication. I can't count the number of times I've forgotten what account name I've used for signing into a service and have then needed to re-create my account, and thus loose all previous information they were storing.

A note on security

I'm sure that there are several of you reading this article that are interested in hearing about the security infrastructure that is currently in place on Passport, and will be in place when it is supplying HailStorm with its single sign-in process, and also about the important security concerns that would surround the storage and retrieval of personal information in something like HailStorm. Not only would such a discussion require several articles of its own, but I am also not the right person to speak with the necessary level of authority on it. There will definitely be additional articles and technical papers provided by others who are more qualified to help you understand these issues and to determine if they meet your needs.

Until Next Month

That's it for July. If you want to learn more about HailStorm, check out the HailStorm episode of the NET Show.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft. All rights reserved.