This could be a nightmare: another ReadWriteWeb story about “Facebook login.” Actually, we’re being serious: The way security is ensured in any modern operating system is by authenticating the user, and certifying that processes are only run by certified sources. If cloud services are to play the role of application servers, then every online transaction will need to be certified. And we are far from that point.
The real problem is not that there are too many claims-based identity token formats for developers to keep track of. The problem is that there are more than 20 identity federation protocols, each of whose intention is to serve as the mediator between all the formats. This week at Build 2011 in Anaheim, Microsoft threw in a curious little demonstration in the midst of its Windows 8 “Metro-style apps” news: It showed the simple act of logging onto a remote app. It showed it once.
It was a key moment linking both ends of the Windows scale, small apps with big iron: A feature called the Access Control Service, running on Windows Azure, was enabling a Web app to authenticate a Windows 8 tablet user once, and then retain that authentication for other apps, some of which use different identity services.
“When I log in here, one of the things that I see is a list of identity providers that this app will accept,” said Microsoft identity engineer John Shewchuk, holding one of the developers’ preview tablets during the Day 2 keynote at Build 2011 on Wednesday. The demo was for a fictitious travel agency looking up flight deals for the user. “That list actually came down from the cloud where the Windows Azure Access Control Service had been configured to support these identity providers. This represents a great opportunity for ‘Marquis Travel.’ They can dynamically adjust a collection of identity providers that they want to use, by just going up to Azure and configuring the project without all of those Web sites and those different applications.”
Shewchuk showed off the Password Broker in Windows 8 to log into an app requiring OAuth identity to let him log on using Facebook. It actually didn’t look like anything at all… which was exactly the point. Once the user logs on once, it’s not supposed to look like anything.
The basic principle is like this: On the Azure side of the equation is the Access Control Service (ACS), which the Web app contacts to authenticate the user. On the Windows 8 tablet side is the Password Broker. As we learned from a technical session on the subject this week, the Password Broker’s login screen obtains a token that can be used to authenticate the same user on multiple other services, by handling the logon process for those other services in the background when necessary.
Microsoft identity engineer Vittorio Bertocci – another favorite of these conferences – explained the process of authenticating the user for rich client applications – the new class of apps that include Metro apps in Windows 8. Such an app does not have the luxury of relying on the browser to manage the session and handle cookies, because there is no browser here.
When a Web app places a call to a Web service, Bertocci explained to an audience of enterprise developers on Thursday (with his characteristic flare for gesticulations and even live doodle-drawing on PowerPoint), whether that service is SOAP or REST, that service expects the correct credentials. It’s not going to give any help if it doesn’t; it’ll simply respond with a 404, and that’s the end. The problem there is, authentication services expect the requester to be a browser with a full array of resources, not a Web app that may be managing the session on its own.
“Most of those identity providers will allow users to authenticate exclusively through the use of the browser,” said Bertocci. As a result, Web apps end up launching the Web browser anyway just to lead the user through the logon process. The result is a disconnect, he says, between the way you expect to write a rich Web application and the way authentication services expect them to ask for identity tokens.
“Once you get that token, you had better hold it dearly so that you ask the user as little as possible (but not less) to authenticate.” Cookies that retain identity tokens are usually managed by the operating system and/or the browser. But all the token formats are different from one another. The danger is the proliferation of more active tokens than there are active users.
Here’s where Bertocci introduces the Password Vault. When you sign onto Windows 8 using a Windows Live ID account (some Windows 7 users can do this too), the operating system can authenticate the user through the Live ID service. The service returns an identity token that’s placed in the Password Vault. The Vault utilizes a database of authentication URLs that may be used for the same user, with a handful of other services including Facebook, Yahoo, and Google. Now when a Web app needs to authenticate the same user in a different way, it can look to the Vault first to see if an authentication URL request may be placed in the background.
Some authentication services in particular, the Microsoft engineer went on, actually have to be led to believe the user is authenticating by way of a browser. So Windows 8 kind of, well, forges one, in a nice way.
“Facebook wants users to authenticate using a browser. But I’m not using a browser. Well, in Windows 8, since we’re aware of the problem, we created one specific tool that you can use for showing the browser a Web surface when you need it.”
In other words, the Web Authentication Broker – a new component of WinRT – actually pulls up Facebook’s authentication layout as though it were in a browser. That code had to be scaled down, Bertocci said, so the logon process didn’t trigger the user’s Facebook wall to be displayed.
The ACS will get a big scaling up this week with the release of Version 2 of the Windows Azure Service Bus. Microsoft Senior Vice President for Windows Azure Scott Guthrie explained to RWW the significance of this announcement in an interview on Wednesday: “If you want to build a simple app, or you have a Web role or a back-end worker role processing data – say, an e-commerce site – every time someone places an order, they send a message to the service bus, do an orders queue, and a back-end processor processes it. It’s a very simple messaging scenario. You can do that with a whole bunch of different messaging stacks. One of the things that interesting with the Service Bus is, it’s fully managed in Azure, so the TCO is really, really low. But also, the way we do authentication… is through a federated identity system.”
With such a system, Guthrie explained, a token that authenticates one app may create a chain of trust that’s utilized by other providers that attach services to that app. This way, partners can handle part of the order processing, for instance, without the user having to log on yet again.
“The beauty is, I didn’t need to redesign my app,” remarked Guthrie. “I started with something small and simple, and it could steadily get richer and more involved. I like to say, can we lead people into the pit of success, as opposed to the pit of failure? By baking in federated identity at the base, it’s not a [case of], ‘Oh, my gosh, we just spent a year rewriting our app.’ It’s, ‘Oh wow, we could actually spend a few hours and bring online this new scenario in a really easy way.’ We’ve gently guided people to build their apps in such a way that they’re elastic by default.”