Social sign-in has become a powerful force for marketers and consumers, validating the notion of federated identity in consumer-facing contexts. (Ironic that consumerization of IT is successfully tackling even the single sign-on problem that has bedeviled IT, showing how identity for the top line of the business can overcome resistance in ways that business-to-employee scenarios typically can't.)
But not all consumer-facing federated SSO is social. When I was with PayPal, our team worked on the underpinnings of what eventually turned into Log In with PayPal, which is strictly about federated identity flows for commercial purposes. And today Amazon has come out with Login with Amazon, a powerful statement of Amazon-as-identity-provider. They've been testing this with their own web properties Zappos and Woot; now they're enabling third-party merchants and other sites to use Amazon for authentication of people who already have active Amazon accounts, along with learning a few selected user attributes: name, email, and optionally the zip code of the default shipping addresses. No huge social graphs here, just data that partner eCommerce sites need to function (and make money).
Andras Cser probed a sore spot in IAM last week with his post, “XACML Is Dead.” It’s a necessary conversation (though I did see a glint in his eye at the Forrester BT Forum after he pressed Publish!). Our Q3 2012 Identity Standards TechRadar showed that XACML has already crested the peak of its moderate success trajectory, heading for decline. We haven’t seen its business value-add or ecosystem grow since then, despite the publication of XACML 3.0 and a few other bright spots, such as Axiomatics’ recent funding round.
It’s not that we don’t need an interoperable solution for finer-grained access control. But the world’s demands for loosely coupled identity and access systems have gotten...well, more demanding. The solution needs to be friendly to open web API security and management. It needs to be friendly to mobile developers. And it most certainly needs to be prepared to tackle the hard parts of integrating authorization with truly heterogeneous cloud services and applications, where business partners aren’t just enterprise clones, but may be tiny and resource-strapped. This admittedly gets into business rather than technical challenges, but every ounce of technical friction makes success in the business realm less likely.
Undoubtedly, most of you will have seen the amazing story about the developer who secretly outsourced his own role to China, investing 20% of his annual salary to free up almost all his work time. The ruse came to light when the firm, who were pushing forward with a more flexible working package, noticed anomalous VPN activity and called in their telecom provider to investigate. The logs indicated that their lead programmer, "Bob," was apparently regularly telecommuting from Shenyang despite being peacefully sat at his desk surfing the Internet for amusing cat videos.
It transpires that "Bob" had FedExed his SecurID token to China and was allowing the remote development company VPN access to his employer's network so that they could do his day job for him.
Irrespective of the terrible security implications here, and they are pretty horrid, "Bob" was delivering high-quality code to schedule. In fact, his performance review regularly identified him as the best developer they had! And what "Bob" did here was not difficult – many sites offer the services of dedicated professionals such as developers, designers, proofreaders, even lawyers, for a small price.
In a business environment where we encourage flexible working, allow personal devices, and seek to incentivize workers for innovation, excellence, and performance, "Bob" could be held up as a role model, but at what cost to the enterprise?
Cloud providers and many federated IAM practitioners are excited about OAuth, a new(ish) security technology on the scene. I’ve written about OAuth in Protecting Enterprise APIs With A Light Touch. The cheat-sheet list I keep of major OAuth product support announcements already includes items from Apigee, Covisint, Google, IBM, Layer 7, Microsoft, Ping Identity, and salesforce.com. (Did I miss yours? Let me know.)
OAuth specializes in securing API/web service access by a uniquely identified client app on behalf of a uniquely identified user. It has flows for letting the user explicitly consent to (authorize) this connection, but generally relies on authorizing the actions of the calling application itself through simple authentication. So does the auth part of the name stand for authentication, authorization, or what? Let’s go with “all of the above.”
However, OAuth is merely plumbing of a sort similar to the WS-Security standard (or, for that matter, HTTP Basic Authentication). It doesn’t solve every auth* problem known to humankind, not by a long shot. What other IAM solutions are popping up in the API-economy universe? Two standards communities are building solutions on top of OAuth to round out the picture: