Microservices are becoming a favorite architectural choice to build and deploy applications as groups of modular, composable services. This progress is reinforced with the rise of the container technology Docker, which offers a lightweight form of virtualization, making applications easily portable across a variety of infrastructures. This growing popularity is illustrated in recent surveys of business and technology professionals, such as the 2015 NGINX survey of 1,800 IT professionals. In that report, 44% of respondents said they’re using microservices in development or in production and nearly 70% of organizations are either using microservices or actively investigating them. Microservices allow developers to create elegant, dynamic applications, capable of operating at extremely high scale.
These architectures create some unique challenges, though. Applications and services, more than ever before, are performing actions with other services on behalf of users. This service-to-service communication often suffers from the so-called “confused deputy” problem, a type of privilege escalation that can cause, well, confusion, and create serious security vulnerabilities.
For an innocuous example, imagine a request coming in to a widget-store API for widget #1. The widget-store needs to make a secondary call to the widget-stock API to see if widget #1 is in stock. In a typical flow, the widget-stock API wouldn’t know the user’s identity, just that the request is coming from the widget-store API. But maybe the widget-stock API should return a regional-specific stock level. How can it do that if it doesn’t know the identity of the original requestor?
In another sample, but much more serious example, a system could be performing an action on behalf of a user – writing to a file, for example. But the scope of what the user can write to and what the service can write to are vastly different, so how do you enforce the right level of control?
The ‘confused deputy’ problem is solved by using identity propagation. An access token issued on behalf of a user is presented by the calling party (the widget-store API in the first example) and is subsequently validated by the resource service (the widget-stock API) before access is granted. But to do this in an architecturally appropriate way, you really want a set of identity microservices to work as a component of your complete system.
This is why we’re introducing ForgeRock Identity Microservices, a set of standards-based identity microservices, designed to provide a simple and easy way to increase application security by integrating identity into service to service interactions. With ForgeRock Identity Microservices, developers will be able to ensure that the transactions between microservices, users, things, and other entities are secure by validating the identity of the caller and checking for proper authorization.
ForgeRock Identity Microservices will be a subset of the ForgeRock Identity Platform and will be able to run as simple self-contained microservices in a stateless mode. This functionality will help microservices developers provide identity services in their applications, independent of the platform technology used. Container friendly, the ForgeRock Identity Microservices are supported on Docker, Kubernetes and CloudFoundry.
Four self-contained ForgeRock Identity Microservices are under development:
ForgeRock Authentication Microservice
This microservice will authenticate other microservices to ensure they are legitimate services. Further, it will provide OAuth2-based authorization tokens with limited set of scopes bound to the calling service.
ForgeRock Token Validation Microservice
This microservice will offer a token introspection endpoint and be able to validate authentication tokens issued by the ForgeRock Authentication Microservice as well as ForgeRock Access Management.
ForgeRock Token Exchange Microservice
This microservice will validate the identity of a user and a service that is trying to call another service on behalf of a user. It will ensure that other microservices in your environment can talk to each other only if they are authorized to do that and with the minimum authorization necessary.
ForgeRock Authorization Microservice
This microservice will be able to provide local declarative validation of policies as well as proxy over external policy decision points (PDPs). It is designed to use external policy decision points such as ForgeRock Access Management only when needed.
Javed Shah is a Product Management Director at ForgeRock.