A New Venn Of Access Control For The API Economy

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:

Can You Join The API Economy While Maintaining Top-Notch Security?

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.)

In Cloud-Friendly Web Services Security, "There Is No Enterprise." Wait. What?

"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.

No more chewy centers, indeed. And OAuth is playing an increasing role in a variety of business scenarios, from B2B to identity federation to variants on classic SOA security, wherever light weight and agility are prized. I hope you'll get a chance to check out the report to see my recommendations for using OAuth effectively in whisper-light app environments, and weigh in here with your thoughts.

Participating In Markets For Portable Identities In The Cloud: What’s The Coin Of Your Realm?

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.

Protecting Internal APIs — Is OAuth Ready For Its Closeup?

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.

CardSpace Is Dead. Long Live Back-Channel Access.

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.