I’ve decided to start a series of posts on my beloved product, Passport (aka Windows Live ID). I’ve talked in the past about the breadth and depth of work our team is doing for Microsoft, much of it behind the scenes to help partners like Messenger and Xbox realize their scenarios.
A recurring topic that has come up since the inception of Passport surrounds the sign-in user interface (UI). Signing into MSN, Microsoft and Windows Live services is a hot topic and sign-in is often perceived to be a barrier. To kick this this series of posts off, I’ll start off with the most common gripe:
Q: Why do you keep asking me to sign in over and over again even though I’ve checked “automatically sign me in”? What don’t you understand about “automatic”?!
One of the biggest problems with see in the network of MSN, Windows Live and Microsoft sites is that Passport sign-in is seen way too often by users. It appears as if we are disregarding your choice of “automatically sign me in” and randomly asking you to sign in when we want with no rhyme or reason.
In order to explain why this is happening and get down to the source of the problem (and ultimate solution) i’ll briefly discuss the way Passport sign in works. (Note: I will purposely be a little “handy wavy” and vague for simplicity of discussion).
Passport / Live ID sign-in 101
Passport sign in is based on cookies. Because HTTP is stateless, we have only 2 ways of persisting information across requests — the first being to carry it on the query string, and second via HTTP cookies. The first method (query string) isn’t useful across browser sessions (open IE, close it, and re-open), which leaves us only option 2 (cookies). Cookies are the mainstay of modern web sites, and allows very powerful personalization and state management. Passport leverages this to provide the world’s largest web authentication (aka sign-in) system in the world.
For those more technically inclined and familiar with sign-in systems, Passport utilizes a protocol very similar to Kerberos with:
-Passport sign-in server acting as the Key Distribution Center (KDC)
-Passport.com cookies domain acting as the Ticket Grant Ticket (TGT) (also known as a magic cookie)
-cookies in each partner domain (eg. msn.com) acting as service ticket
-Partner sites (eg. www.live.com) acting as the Service Server (SS)
After you sign into one partner site in the “passport network”, users can freely go to subsequent partner sites and sign in. This is where the magic of Passport comes into play and single sign-on is achieved. When you visit another partner site, and click “sign in” you are redirected to Passport servers. Because you already authenticated once to Passport (represented through your passport.com cookies), we don’t need to validate your credentials again and can issue a service ticket for this new partner website.
But Trevin, you just said that “because you already authenticated once to Passport <snip>, we don’t need to validate you credentials again…“. That clearly isn’t the case since I seem to keep getting asked for my password!
In the last section, especially the last paragraph, I purposely left out some detail for simplicity. We can dive into more detail now that you have a better high-level understanding of the flow of passport sign-in.
In order to have a secure single sign-on system, you simply cannot have one prompt for a login then be able to access any site. It sounds counter-intuitive, since that’s what “single sign-on” seems to imply. This would only be possible if every single website you accessed had the same level of security and data sensitivity. We all know that this is not the case, and instead, sites vary in the level of security needed to protect it.
On the lower end of the spectrum (least sensitive), we have sites like www.live.com, which is merely personalization. In the middle, have sites like Live Mail, which has personal information such as email from your friends. On the extreme end of the scale (most senstitive) we have sites like Microsoft Billing which contains your credit card information. Because of this varying levels of data sensitivity, each site in the Passport network configures what we’ll call their “security policy” which tells passport parameters to enforce during sign in which is supposed to be directly related to their data sensitivity — the more sensitive the information therein, the “tighter” the security policy.
What exactly does a “tight” security policy mean? For this discussion, we’ll restrict it to “time window”, which is the length of time since you last entered your password. So a time window of 5 mins, means that you must have entered your password within the last 5 mins, otherwise you will be forced to sign in again.
Trevin, you’ve written the longest blog post in the history of your blog. What’s the point of all this?
Relax, I’m getting there 🙂 On each redirect to Passport that a partner website makes, they indicate what their security policy is (usually on the query string). Passport, as the authentication broker, simply enforces that policy. So the reason you often get asked to sign in over and over again, is not because Passport is “broken”, but rather because we’re obligated to honor the security policy (time window) that we’ve been told to enforce.
All our partner websites currently have a mis-matched set of security policies, each set at their own discretion of their team’s security champ. It’s because of the inconsistent security plicies, you keep getting asked for your password over and over.
Wow, so this sounds like a tough problem to solve. How are you going to fix this?
Our team is absolutely committed to make the sign in experience the best on the internet. To fix this specific problem, our team is moving to a centralized definition of security policies. What does this mean? Instead of each partner website telling us the specific parameters of the security policy (such as time window), they instead will tell us an ID of a security policy to enforce, whose definition will be on the Passport sign-in servers. This means, that by offering a limited set of security policies we limit the mistakes partner websites can make, and we will inherently have more consistency across the entire network for sign in. Additionally, it gives us more agility to tweak both the user experience and security of the network since Passport is in total control of the parameters.
Over and out
Albeit lengthy, I hope this long explanattion helps to give you some insight into the Passport single sign-on system as well as why certain behaviors you experience are happening. In subsequent posts over the next few weeks, I will be addressing other parts of Passport sign-in in order to shed some light of what’s going on under the covers and tell you where we’re going in the future.
Our team is committed to improving the sign-in experience, so please drop a comment if you have questions or any feedback for our team.