Every couple of weeks I start up Autoruns to see what new stuff has added itself to Windows startup and what not (screw you Adobe – you as a software company make me want to swear endlessly). Anyway, a few months ago around the time the latest version of Windows Live Messenger and it’s suite RTM’ed I poked around to see if anything new was added. Turns out there was:
A new credential provider was added!
Interesting.
Not only that, it turns out a couple Winsock providers were added too:
I started poking around the DLL’s and noticed that they don’t do much. Apparently you can use smart cards for WLID authentication. I suspect that’s what the credential provider and associated Winsock Provider is for, as well as part of WLID’s sign-on helper so credentials can be managed via the Credential Manager:
Ah well, nothing too exciting here.
Skip a few months and something occurred to me. Microsoft was able to solve part of the Claims puzzle. How do you bridge the gap between desktop application identities and web application identities? They did part of what CardSpace was unable to do because CardSpace as a whole didn’t really solve a problem people were facing. The problem Windows Live ran into was how do you share credentials between desktop and web applications without constantly asking for the credentials? I.e. how do you do Single Sign On…
This got me thinking.
What if I wanted to step this up a smidge and instead of logging into Windows Live Messenger with my credentials, why not log into Windows with my Windows Live Credentials?
Yes, Windows. I want to change this:
Question: What would this solve?
Answer: At present, nothing ground-breakingly new. For the sake of argument, lets look at how this would be done, and I’ll (hopefully) get to my point.
First off, we need to know how to modify the Windows logon screen. In older versions of Windows (versions older than 2003 R2) you had to do a lot of heavy lifting to make any changes to the screen. You had to write your own GINA which involved essentially creating your own UI. Talk about painful.
With the introduction of Vista, Microsoft changed the game when it came to custom credentials. Their reasoning was simple: they didn’t want you to muck up the basic look and feel. You had to follow their guidelines.
As a result we are left with something along the lines of these controls to play with:
The logon screen is now controlled by Credential Providers instead of the GINA. There are two providers built into Windows by default, one for Kerberos or NTLM authentication, and one for Smart Card authentication.
The architecture looks like:
When the Secure Attention Sequence (CTRL + ALT + DEL / SAS) is called, Winlogon switches to a different desktop and instantiates a new instance of LogonUI.exe. LogonUI enumerates all the credential provider DLL’s from registry and displays their controls on the desktop.
When I enter in my credentials they are serialized and supposed to be passed to the LSA.
Once the LSA has these credentials it can then do the authentication.
I say “supposed” to be passed to the LSA because there are two frames of thought here. The first frame is to handle authentication within the Credential Provider itself. This can cause problems later on down the road. I’ll explain why in the second frame.
The second frame of thought is when you need to use custom credentials, need to do some funky authentication, and then save save the associated identity token somewhere. This becomes important when other applications need your identity.
You can accomplish this via what’s called an Authentication Package.
When a custom authentication package is created, it has to be designed in such a way that applications cannot access stored credentials directly. The applications must go through the pre-canned MSV1_0 package to receive a token.
Earlier when I asked about using Windows Live for authentication we would need to develop two things: a Credential Provider, and a custom Authentication Package.
The logon process would work something like this:
- Select Live ID Credential Provider
- Type in Live ID and Password and submit
- Credential Provider passes serialized credential structure to Winlogon
- Winlogon passes credentials to LSA
- LSA passes credential to Custom Authentication Package
- Package connects to Live ID STS and requests a token with given credentials
- Token is returned
- Authentication Package validated token and saves it to local cache
- Package returns authentication result back up call stack to Winlogon
- Winlogon initializes user’s profile and desktop
I asked before: What would this solve?
This isn’t really a ground-breaking idea. I’ve just described a domain environment similar to what half a million companies have already done with Active Directory, except the credential store is Live ID.
On it’s own we’ve just simplified the authentication process for every home user out there. No more disparate accounts across multiple machines. Passwords are in sync, and identity information is always up to date.
What if Live ID sets up a new service that lets you create access groups for things like home and friends and you can create file shares as appropriate. Then you can extend the Windows 7 Homegroup sharing based on those access groups.
Wait, they already have something like that with Skydrive (sans Homegroup stuff anyway).
Maybe they want to use a different token service.
Imagine if the user was able to select the “Federated User” credential provider that would give you a drop down box listing a few Security Token Services. Azure ACS can hook you up.
Imagine if one of these STS’s was something everyone used *cough* Facebook *cough*.
Imagine the STS was one that a lot of sites on the internet use *cough* Facebook *cough*.
Imagine if the associated protocol used by the STS and websites were modified slightly to add a custom set of headers sent to the browser. Maybe it looked like this:
Relying-Party-Accepting-Token-Type: urn:sometokentype:www.somests.com
Relying-Party-Token-Reply-Url: https://login.myawesomesite.com/auth
Finally, imagine if your browser was smart enough to intercept those headers and look up the user’s token, check if they matched the header ”Relying-Party-Accepting-Token-Type” and then POST the token to the given reply URL.
Hmm. We’ve just made the internet SSO capable.
Now to just move everyone’s cheese to get this done.
Patent Pending. 
Homer Simpson was once quoted as saying “To alcohol! The cause of, and solution to, all of life's problems”. I can’t help but borrow from it and say that Claims-Based Authentication is the cause of, and solution to, most problems with identity consumption in applications.
When people first come across Claims-Based Authentication there are two extremes of responses:
- Total amazement at the architectural simplicity and brilliance
- Fear and hatred of the idea (don’t you dare take away my control of the passwords)
Each has a valid truth to them, but over time you realize all the problems sit somewhere between both extremes. It’s this middle ground where people run into the biggest problems.
Over the last few months there’s been quite a few people talking about the pains of OpenID/OpenAuth, which when you get right down to the principle of it, is CBA. There are some differences such as terminology and implementation, but both follow the Trusted Third Party Authentication model, and that’s really what CBA is all about.
Rob Conery wrote what some people now see as an infamous post on why he hates OpenID. He thinks it’s a nightmare for various reasons. The basic list is as follows:
- As a customer, since you can have multiple OpenID providers that the relying party doesn’t necessarily know about, how do you know which one you originally used to setup an account?
- If a customer logs in with the wrong OpenID, they can’t access whatever they’ve paid for. This pisses off said customer.
- If your customer used the wrong OpenID, how do you, as the business owner, fix that problem?
- Is it worth fixing?
- Is it worth the effort of writing code to make this a simpler process?
- “I'll save you the grumbling rant, but coding up Open ID stuff is utterly mind-numbing frustration”. This says it all.
- Since you don’t want to write the code, you get someone else to do it. You find a SaS provider. The provider WILL go down. Laws of averages, Murphy, and simple irony will cause it to go down.
- The standard is dying. Facebook, Google, Microsoft, Twitter, and Joe-Blow all have their own particular ways of implementing the standard. Do you really want to keep up with that?
- Dealing with all of this hassle means you aren’t spending your time creating content, which does nothing for the customer.
The end result is that he is looking to drop support, and bring back traditional authentication models. E.g. storing usernames and passwords in a database that you control.
Following the Conery kerfuffle, 37signals made an announcement that they were going to drop OpenID support for their products. They had a pretty succinct reason for doing so:
Fewer than 1% of all 37signals users are currently using OpenID. After consulting with a fair share of them, it seems that most were doing so only because that used to be the only way to get single sign-on for our applications.
I don’t know how many customers they have, but 1% is nowhere near a high enough number to justify keeping something alive in any case.
So we have a problem now, don’t we? On paper Claims-Based Authentication is awesome, but in practice it’s a pain in the neck. Well, I suppose that’s the case with most technologies.
I think one of problems with implementations of new technologies is the lack of guidance. Trusted-Third Party authentication isn’t really all that new. Kerberos does it, and Kerberos has been around for more than 30 years. OpenID, OpenAuth, and WS-Auth/WS-Federation on the other hand, haven't been around all that long. Given that, I have a bit of guidance that I’ve learned from the history of Kerberos.
First: Don’t trust random providers.
The biggest problem with OpenID is what’s known as the NASCAR problem. This is another way of referring to Rob’s first problem. How do you know which provider to use? Most people recognize logo’s, so show them a bunch of logo’s and hopefully they will pick the one that they used. Hoping your customer chooses the right one every time is like hoping you can hit a bullseye from 1000 yards, blindfolded. It could happen. It won’t. But it could.
The solution to this is simple: do not trust every provider. Have a select few providers you will accept, and have them sufficiently distinguishable. My bank as a provider is going to be WAY different than using Google as a provider. At least, I would hope that’s the case.
Second: Don’t let the user log in with the wrong account.
While you are at it, try moving the oceans using this shot glass. Seriously though, if you follow the first step, this one is a by product. Think about it. Would a customer be more likely to log into their ISP billing system with their Google account, or their bank’s account? That may be a bad example in practice because I would never use my bank as a provider, but it’s a great example of being sufficiently distinguishable. You will always have customers that choose wrong, but the harder you make it for them to choose the wrong thing, the closer you are to hitting that bullseye.
Third: Use Frameworks. Don’t roll your own.
One of the most important axioms in computer security is don’t roll your own [framework/authn/authz/crypto/etc]. Seriously. Stop it. You WILL do it wrong. I will too. Use a trusted OpenID/OpenAuth framework, or use WIF.
Forth: Choose a standard that won’t change on you at the whim of a vendor.
WS-Trust/Auth and SAML are great examples of standards that don’t change willy-nilly. OpenID/OpenAuth are not.
Fifth: Adopt a provider that already has a large user base, and then keep it simple.
This is an extension of the first rule. Pick a provider that has a massive number of users already. Live ID is a great example. Google Accounts is another. Stick to Twitter or Facebook. If you are going to choose which providers to accept, make sure you pick the ones that people actually use. This may seem obvious, but just remember it when you are presented with Joe’s Fish and Chips and Federated Online ID provider.
Finally: Perhaps the biggest thing I can recommend is to keep it simple. Start small. Know your providers, and trust your providers.
Keep in mind that everything I’ve said above does not pertain to any particular technology, but of any technology that uses a Trusted Third Party Authentication model.
It is really easy to get wide-eyed and believe you can develop a working system that accepts every form of identification under the sun, all the while keeping it manageable. Don’t. Keep it simple and start small.
I’ve always found Kerberos to be an interesting protocol. It works by way of a trusted third party which issues secured tickets based on an authentication or previous session. These tickets are used as proof of identity by asserting that the subject is who they claim to be. Claims authentication works on a similar principle, except instead of a ticket you have a token. There are some major differences in implementation, but the theory is the same. One of the reasons I find it interesting is that Kerberos was originally developed in 1983, and the underlying protocol called the Needham-Schroeder protocol, was originally published in 1978.
There have been major updates over the years, as well as a change to fix a man-in-the-middle attack in the Needham-Schroeder protocol in 1995, but the theory is still sound. Kerberos is the main protocol used in Windows networks to authenticate against Active Directory.
The reason I bring it up is because of a comment I made in a previous post. I made an assertion that we don’t necessarily abstract out the identity portion of our applications and services.
Well, It occurred to me that up until a certain period of time, we did. In many environments there was only one trusted authority for identity. Whether it was at a school, in a business, or within the government there was no concept of federation. The walls we created were for a very good reason. The applications and websites we created were siloed and the information didn’t need to be shared. As such, we created our own identity stores in databases and LDAP directories.
This isn’t necessarily a problem because we built these applications on top of a foundation that wasn’t designed for identity. The internet was for all intents and purposes designed for anonymity. But here is where the foundation became tricky: it boomed.
People wanted to share information between websites and applications, but the data couldn’t be correlated back to the user across applications. We are starting to catch up, but it’s a slow process.
So here is the question: we started with a relatively abstract process of authentication by way of the Kerberos third party, and then moved to siloed identity data. Why did we lose the abstraction? Or more precisely, during this boom, why did we allow our applications to lose this abstraction?
Food for thought on this early Monday.