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.
A couple of months back, I advocated killing your password policies and applying some other techniques instead to make existing use of passwords more effective (including my hobby horse: take the user-experience sting out of rotating ordinary static passwords by pushing them out to users on an alternate channel, à la activation codes and other OTPs). But adding factors is still a great idea, and the barriers to doing so are falling fast.
Protocol gut check. That's how someone recently described some research I've got under way for a report we're calling the "TechRadar™ for Security Pros: Zero Trust Identity Standards," wherein we'll assess the business value-add of more than a dozen identity-related standards and open protocols. But it's also a great name for an episode of angst that recently hit the IAM blogging world, beginning with Eran Hammer's public declaration that OAuth 2.0 -- for which he served as a spec editor -- is "bad."
As you might imagine, our TechRadar examination will include OAuth; I take a lot of inquiries and briefings in which it figures prominently, and I've been bullish on it for a long time. In this post, I'd like to share some thoughts on this episode with respect to OAuth 2.0's value to security and risk pros. As always, if you have further thoughts, please share them with me in the comments or on Twitter.
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:
If anything exemplifies the extended enterprise, it's the notion of the "API economy": Unlocking value in your organization's unique data and services by publishing open APIs (application programming interfaces) for access by third parties. As Laura Koetzle notes, business leaders today are prioritizing growth above all -- and fostering a third-party developer ecosystem is becoming a great way to boost revenue. Best Buy, eBay, and USA Today are examples of companies with APIs and external developer communities.
But, but, but...just how secure is an open API? Especially if you, the security professional, can't fully control these external developers' actions? This is where it gets exciting, because security and identity-based access control are enablers of these new business opportunities. After all, an API of this sort is essentially a digital product whose use must be metered.
Many organizations in this position are turning to the OAuth technology to solve a host of security challenges that arise from opening up APIs. I'm excited to be bringing the latest in OAuth business cases, adoption news, and recommendations to my Forrester Security Forum track session on "Securing And Identity-Enabling Monster Mashups." Hope to see you at the Forum November 9-10 in Miami!
(Got a great API security story, or maybe some questions? Don't wait till November; feel free to share in a comment here, or ping me on Twitter using the #FSF11 hashtag.)
“There is no enterprise — the work we do is a collection of people that dynamically changes through a mix of organization control.” That’s what I heard from one venerable old construction company while working on my new research report, Protecting Enterprise APIs With A Light Touch. I wanted to investigate how enterprises are using and securing lightweight RESTful web services, and in particular to figure out the problems for which OAuth is well suited. (You might recall my request for feedback in a prior post.)
What I found was that forward-thinking enterprises of many types – not just hip-happenin’ Web 2.0 companies – are pushing service security and access management to the limit in environments that can truly be called “Zero Trust,” to use John Kindervag’s excellent formulation. This particular firm dynamically manipulates authorizations to control access to a variety of innovative lightweight APIs on which the whole company is being run, not actually distinguishing between “internal” and “external” users. They’ve kind of turned themselves inside-out.
Many IT security pros are moving toward disruptive new authentication and authorization practices to integrate securely with cloud apps at scale. If you’re considering such a move yourself, check out my new report, The “Venn” of Federated Identity. It describes the potential cost, risk, efficiency, and agility benefits when users can travel around to different apps, reusing the same identity for login.
Aggregate sources of identities are large enough now to attract significant relying-party application “customers” – but the common currency for identity data exchange varies depending on whether the source is an enterprise representing its (current or even former) workforce, a large Web player representing millions of users, or other types of identity providers. These days, the SAML, OAuth, and OpenID technologies are the hard currencies you’ll need to use when you participate in these identity markets. You can use this report to start matching what’s out there to your business scenarios, so you can get going with confidence.
Two years ago, the OAuth API protection mechanism was a fairly well-kept secret. It actually won an award at the 2009 European Identity Conference for "best new/improved standard," but most people didn't seem to have figured out what it was good for yet; I felt like I was the only one even talking about it.
Fast forward a bit, when Facebook started using an early draft of OAuth 2.0 in its Open Graph-based platform, and then a bit more, when Twitter started requiring OAuth 1.0a use by third-party developers (known amusingly as the OAuthcalypse), turning off the HTTP Basic authentication option. And now we're in a world where cloud developers talk casually about the "open API economy" and the ease of getting work done by building RESTful apps, and OAuth is making star appearances in recent gatherings of influential software architects and developers I've attended, such as The Experts Conference and the Internet Identity Workshop.
Microsoft announced during last week's RSA conference that it would not be shipping Windows CardSpace 2.0. A lot of design imperatives weighed on that one deliverable: security, privacy, usability, bridging the enterprise and consumer identity worlds – and being the standard-bearer of the "identity metasystem" and the "laws of identity" to boot. Something had to give. What are the implications for security and risk professionals?
The CardSpace model had nice phishing resistance properties that cloud-based identity selectors will find hard to replicate, alas. But without wide adoption on the open Web, that wasn't going to make a dent anyway. We'll have to look for other native-app solutions over time for that.