Back in July, I wrote about a new RESTful API that cloud providers and provisioning vendors are working on for doing identity provisioning and synching: Simple Cloud Identity Management, or SCIM (like the milk). At last week's Internet Identity Workshop -- only five months after this draft spec made its formal debut! -- I had a chance to see the SCIM developers' live interop session in action. The interop saw successful participation by the likes of Cisco, Ping Identity, Sailpoint, salesforce.com, Technology Nexus, and UnboundID, with user accounts being securely created and torn down rapid-fire over the ether.
What's more, in talking with a more traditional on-premises identity vendor later in the week, I discovered that they loved how SCIM was shaping up, and planned to check it out ASAP as a way they could expose their own provisioning functionality.
In this Zero Trust world, with perimeters melting all over the place, I'm seeing signs that this lightweight API trend for IdM functionality is only going to accelerate. What do you think? If you're coming to Forrester Security Forum in a couple of weeks, I hope you'll grab me for a conversation about how this trend impacts your plans.
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.
A decade after launching the SAML standard and seeing its, shall we say, stately pace of adoption, it’s wild to see real single sign-on and federated attribute sharing starting to take off for social networking, retail sites, online gaming, and more — not to mention seeing the US government starting to consume private-sector identities on citizen-facing websites.
Last week, we published a report on Outsourcing Identity Assurance. In it, I examine this “Government 2.0” effort, including the National Strategy for Trusted Identities in Cyberspace (NSTIC), and its innovations around identity assurance, and the confidence you can have in the real-world verification of the identity you’ve been given by an identity provider. We’re predicting you’ll see new Web 2.0-ish ways to outsource identity verification in the coming three years, driven by use cases like e-prescribing, high-value eCommerce, and even online dating.
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.
If you're a security and risk professional in charge of protecting consumer-facing applications, you may have heard that OpenID is a “toy,” or it's an insecure protocol, or other critiques. And then here comes the recent news by former early adopter 37signals to drop its OpenID login support, which has occasioned some soul-searching in the Web 2.0 identity community. Check out commentary from Scott Gilbertson of Wired's WebMonkey, Dare Obasanjo, and reaction from “social login” vendor JanRain
When OpenID appeared on the scene, more robust solutions based on SAML were well under way for many years and seeing adoption, but only in scenarios involving limited circles of trust — typically point-to-point enterprise outsourcing scenarios and specialized higher-education communities — rather than in broad-based consumer populations.