ForgeRock Service Broker 2.0 - Powerful, Centralized Security for Microservices and Applications on Cloud Foundry

Today we announced general availability of the ForgeRock Service Broker 2.0 for Cloud Foundry. This update to our Cloud Foundry integration capabilities will make it easier for developers to identity-enable their Cloud Foundry applications. The new service broker takes advantage of Cloud Foundry Route Services. In their documentation, Cloud Foundry describes Route Services as “a kind of Marketplace Service that developers can use to apply various transformations to application requests by binding an application’s route to a service instance.” Route Services, combined with the ForgeRock Service Broker 2.0 for Cloud Foundry, allows developers to use the ForgeRock Identity Platform to handle authentication and authorization for their microservices and applications.

What this means is that instead of writing and rewriting identity capabilities into each application and service running on Cloud Foundry, developers can instead use the full power of the ForgeRock Identity Platform–things like push authentication, fine-grained authorization, our adaptive risk engine, extremely high performance and scale, and more– as a centralized Identity solution across all of their apps. This keeps microservices “micro,” not bloated with multiple homegrown identity solutions, and centralizes security by reducing the number of places where Identity is handled to a single, unified platform.

The new ForgeRock Service Broker 2.0 for Cloud Foundry leverages Route Services and ForgeRock Identity Gateway 5.0 to make it easy for developers to add this external authentication and authorization to their microservices and apps running on Cloud Foundry.

All client access to an application bound to a Route Service will be routed to the ForgeRock Identity Gateway by Cloud Foundry's CF Router. ForgeRock Identity Gateway can then, for instance, enforce authentication based on OpenID Connect via ForgeRock Access Management. Or, it can also handle authorization via the central authorization framework in ForgeRock Access Management. And upon successful processing by ForgeRock Identity Gateway, the request is routed back to the CF Router with the appropriate header attributes set. Based on those header attributes, the CF Router judges whether to allow the request through to the application or not.

As outlined in the Service Broker 2.0 User Guide, if a request contains a X-CF-Forwarded-Url header, the ForgeRock Identity Gateway, operating as a Cloud Foundry Route Service, dispatches via a DispatchHandler the request to the chain called CloudFoundryProxy. A ScriptableFilter, the CloudFoundryRequestRebaser, in the CloudFoundryProxy filter chain returns the request to the original URI for processing.

Once the route service is properly set up, ForgeRock Identity Gateway provides a rich set of capabilities for security enforcement. These can be unlocked by adding filters to the CloudFoundryProxy chain of filters. For instance :

As more deployment architectures leverage services like Cloud Foundry for rich, dynamic applications, the need for a centralized identity approach becomes greater. With ForgeRock Service Broker 2.0 for Cloud Foundry developers can spend their time making their applications and microservices provide great functionality, not trying to figure out over and over again how to protect them.

The Service Broker 2.0 is also available for download on the Pivotal Partner Network.

Resources :

Joachim Andres is a Technical Product Management Director at ForgeRock.