This is part 2 of a 3 part blog series. You can read part 1 here. For more information on DHARMA and API access control for microservices, download a free copy of the O'Reilly eBook "Securing Microservice APIs."
Microservices may be a relatively new trend in software architecture, but distributed applications have a sufficient history to present consistent patterns. For API access control-or more generally the security controls put on communication between components in a distributed software system-there is a binary pattern that results from the practical need to optimize runtime performance. API communication in such systems typically follows either a fast path for messages that are deemed to be trusted, or falls back to a slower path that requires more thorough authentication and authorization. This simple access duality lays the foundation for Domain Hierarchy Access Regulation for Microservice Architecture, a model I'll mercifully refer to henceforth as DHARMA.
Before getting into the details of DHARMA, it helps to survey the microservice API landscape. The following table provides consistent terminology for key concepts and components:
| TERM | DEFINITION |
|---|---|
| Service (AKA microservice) | A logical component that provides functionality through an interface |
| Service Instance | A runtime instantiation of a service, often a set of containers |
| API (AKA web API) | A programmatic interface designed to be consumed via HTTP |
| API Endpoint | A network-addressable location within a runtime environment where an API can be accessed |
| API Request | A message sent to an API endpoint that triggers a service?s execution |
| API Response | A message sent to communicate the result of a service?s execution |
| API Consumer | A service that sends API requests and receives API responses |
| API Provider | A service that receives API requests and sends API responses; a single service can play both the API consumer and API provider role |
| API Intermediary | A component that sits in the API request path from API consumer to API provider; API gateways and service proxies are common API intermediaries |
The terms listed above are the primitives in the microservice API landscape. Service expose APIs, and services communicate with each other-acting as API consumers and providers-by sending API requests and responses to API endpoints through API intermediaries.
With DHARMA, we apply the dual pattern mentioned above to this landscape. Services that communicate in a trusted way are grouped into domains if they use a consistent trust mechanism, such as a token type or isolated network. Services outside a domain may still talk to a service within the domain by using an access mechanism, such as authentication credentials or a digital certificate. To facilitate this communication, a single API may publish separate endpoints for their trusted and untrusted communication: interior endpoints for trusted communication, and boundary endpoints for untrusted. Individual services can participate in multiple domains. Notably, domains can be nested within other domains, creating a domain hierarchy. In a domain hierarchy, the trust mechanism for communication within the outer domain is the same as the access mechanism for services inside the inner domains. The following diagram is a sample DHARMA depiction of some services and APIs:
So why is this DHARMA model useful? First of all, DHARMA helps to abstract complex systems of microservices based on access control concepts, and allows that abstraction to be applied at any level of the system. Secondly, DHARMA can be used to think through how API security should be designed within such a system of microservices. Lastly, DHARMA can be used to implement practical, multi-platform solutions to microservice API security that tie back to popular tools and technologies. This blog post covered the first reason. For details on value points two and three, stay tuned for Part 3 in this blog series coming out soon.
