What’s Up in the Cloud? ForgeRock’s New Cloud Foundry OpenAM Service Broker
With the Cloud Foundry Summit underway in Santa Clara this week, we thought it would be a good time to announce our preview version of a new identity service broker for the Cloud Foundry platform. An extension of the OpenAM project, the new service broker will allow externally deployed ForgeRock solutions to protect applications and microservices running on any iteration of Cloud Foundry. In short, the service broker will enable developers to create persistent identities that are portable across clouds. ForgeRock identity solutions have been implemented as cloud deployments previously – notably European telecom giant Swisscom has offered identity as a service built on the ForgeRock Identity Platform for some time now. But this service broker project marks the first time that a cloud offering is universally available through the open source OpenAM project. We’re throwing around a lot of terms here that might not be immediately recognizable to everyone in the identity community, so let’s clarify a bit
What exactly is Cloud Foundry?
Cloud Foundry is an open source cloud computing platform as a service (PaaS) that is available as freeware, and also as commercial offerings from Pivotal Software, IBM Bluemix, Swisscom, HP and several other vendors. All of these iterations of Cloud Foundry offer a collection of platform elements that enable developers to create and host production versions of online services and applications. These platform elements include features for monitoring, logging, messaging, authentication, traffic routing and other tasks. One of the core concepts of the Cloud Foundry project is the service broker.
What exactly is a service broker?
A service broker is code that enables an application in the cloud to invoke or “point to” a needed service for that application to run. So in our case, an application on the cloud – let’s imagine the application is a smart car onboard navigation and information system – could point to the ForgeRock service broker to invoke identity and access management when a driver “logs in” by starting up their car. The advantage of using OpenAM as the authentication server for the Cloud Foundry platform is that it offers very rich capabilities, including authentication, authorization, adaptive risk and multifactor authentication. For instance, in the smart car scenario there could be different levels of identity required for different drivers – so for instance, parents could set certain restrictions for their teen drivers.
What are microservices?
Well-known software industry observer Martin Fowler, describes microservices thusly: “In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.” Speaking last week to my colleague David Ferriera (cloud technology director here at ForgeRock and the exec who oversaw the development of our service broker project) he provided this overview of what microservices mean in the identity management context:
Microservices is a popular new architecture where monolithic applications are broken down into subcomponents that can then be used to scale independently. The promise of cloud is ubiquity, persistence and flexibility, and microservices are a natural fit in this kind of environment because they give developers more choices in how to approach technical and business challenges. Now, why is identity necessary in a cloud architecture? Identity and access management are key here because a single enduser request may result in many, many microservices requests, and you need identity to be consistent across all those requests. You need to make sure they’re all acting on the same person, and you need to make sure that each one of those microservices requests is authorized. And that’s what we released today - what the ForgeRock service broker does is it supports OAuth and allows you to extend OpenAM capabilities to secure those microservices.
What is OAuth?
OAuth is a standard for authorizing access to applications and data. It enables users to grant restricted access to resources they own—such as pictures residing on a site like Facebook—to a third‐party client like a photo printing site. Before OAuth, it wasn’t uncommon to find websites or online services asking users to share their username and password with the client, a deceptively simple request masking serious security risk. In contrast to this, OAuth promotes a least privilege model, allowing a user to grant limited access to their applications and data by issuing a token with limited capability. OAuth is beneficial because it hands the management of web delegation to the actual resource owner. The user connects the dots between their accounts on different Web applications without involvement from security administrators on the respective site. This relationship can be long‐lasting but can also be terminated at any time by the user. One of the great advancements OAuth brings to the Web community is formalizing the process of delegating identity mapping to users. OAuth originated through the OpenID project at Twitter, and became a standard with input from Google and other Internet companies. The OAuth 1.0 protocol was published as RFC 5849 in April 2010, and the OAuth 2.0 framework followed in 2012.
Final thoughts?
Daniel: The beauty of the cloud / service broker approach is that when a developer is coding an app, they can actually see the service and call out to it. They don’t have to think about deploying the service. If your developers are focused on code, and all they’re doing is pushing this stuff to where it needs to be deployed, and all that infrastructure – everything underneath it is taken care of – that’s gold.
David: That’s the point of the platform. If you’re a developer, you only need to worry about writing the business logic that you’re responsible for. You don’t have to become an expert in identity, deploying databases and all that other infrastructure stuff – it’s just write your code and get on with it.
Daniel: Yes, well there’s two things here, right? Why do developers care about a cloud identity service broker, and why do identity architects and security groups care about it? Because they can now plug into Cloud Foundry as well as their data center and have one single place to manage their security / identity processes. It’s beneficial for both, and that’s a powerful thing.
Where can I access the ForgeRock Cloud Foundry service broker?
The open source code for the service broker preview is accessible through GitHub, and ForgeRock welcomes feedback on the project. The service broker preview and IAM for cloud deployments will be discussed at ForgeRock’s upcoming UnSummit, taking place in San Francisco on June 1st. More information on the ForgeRock Identity Summit Series is accessible here.
