A few months ago at the Cloud Identity Summit (CIS) in London, I gave a presentation on the emerging standards that enable secure access to cloud APIs. The collection of protocols that form the neosecurity stack that I talked about are Simple Cloud Identity Management (SCIM), SAML, OpenID Connect, OAuth 2, and the JSON-based Identity Protocol Suite (JOSE and JWT). These security protocols are quite new (save SAML), and many attendees had not heard of some of them. They are very important for those implementing APIs and SaaS applications though, so I wanted to explain them in a bit more detail.
These two protocols are a really big deal. Together, they provide authentication and delegated access to APIs, respectively.
OpenID Connect is essentially the third version of OpenID. It is a complete rewrite of the protocol and is not compatible with previous versions. It is an HTTP-based protocol that allows apps to authenticate users in foreign security realms. In this way, it provides SSO. Unlike other protocols like SAML and WS-Federation that solve the same problem, OpenID Connect provides the following unique benefits and features:
For more info on OpenID Connect, see the OpenID Foundation's Web site. We'll be blogging about the importance and benefits of OAuth 2 in some of our upcoming posts. Connect on Twitter if you are curious before then.
More and more organizations are adopting cloud computing due to economic pressures, increasingly mobile workforces which require data access from anywhere, and other well known reasons. As AMD recently pointed out in their global study on the matter, the primary concerns adopters have is around security, as they depicted in a handy infographic. Security for the cloud has been the major critique since its inception. Due to the many successful uses of this new computing paradigm, even the skeptics are starting to change their tune.
As Richard Walters pointed out in his recent article on The Data Chain, "Extending security policy enforcement, access control and auditing is the best route to enabling BYOD and SaaS." I completely agree that organizations need to extend existing IAM procedures and infrastructure to encompass new cloud services in order to secure them. I presented on this very idea over a year ago for one of our partners, Ping Identity. As I said then, an important prerequisite to being able to expand entitlement management and audit solutions to the cloud is the extension of the other key components of identity management, namely authentication, federation, and provisioning. The combined use of all aspects of Identity and Access Management (IAM) help address many of the security issues w/ cloud computing and mobile computing.
To see how this cocoon can be spun around the cloud, let me describe how existing IAM capabilities can be used within this new form of computing.
As organizations begin using and deploying cloud applications, some of their services are left on-premises (for various reasons), resulting in a hybrid architecture. In such deployments, the on-prem services sometimes need to be invoked securely from the cloud. When doing so, an STS can be used to broker trust from the cloud into the organization. Unfortunately, the token issued by the IdP when authenticating end users isn't always available to the cloud-based caller due to restrictions/limitations of the cloud platform. In such cases, the on-prem STS can't be given a token asserted by a trusted issuer that it can validate and transform. As a result, the on-prem services do not have all the data needed to make authorization decisions, enforce licensing agreements, etc. One possible solution to this problem is to allow the cloud-based caller to specify in the message sent to the STS certain end-user-related data that should be put in the token that is minted. This will then be passed along to the on-prem services in a token asserted by the local STS. This idea is shown in the following figure: