Skip to content
PlainID
← Back to all integrations
Spring Cloud Gateway logo

Spring Cloud Gateway

Enforce centralized, contextual access policies at Spring Cloud Gateway.

About PlainID + Spring Cloud Gateway

API access control is a crucial aspect of ensuring the overall security of your APIs including the data and functionality they provide. Central to this is the need to be aware of the business context of the API usage, which includes the end-user on behalf of the request is made, and what function and data it is asked to provide.
For example, in a commercial banking application, this will mean making a decision based on the bank teller who's trying to access the bank account, which branch he is part of, what is his title, etc. And the actual bank account he is asking to access, the type or status of the account, and more.
The decision can’t be based just on the service account that is using that specific API. Though API Gateways do have access control capabilities, usually they are unaware of the context (i.e. will make a decision to determine if a call for a service can be made, and not based on the specific context of the call), and whatever identity-awareness they might have is limited and hard to manage.
Without contextual and identity-aware measures in place, there are significant risks associated with unauthorized access to the data through APIs.
PlainID Authorizer for Spring Cloud Gateway provides the API gateway with context awareness, of the identity and the assets the identity is trying to access.

Technical Information

The PlainID MuleSoft Authorizer runs as a sidecar next to each instance of MuleSoft. It can be deployed as a sidecar container within the Pod, or run as a service. When a request hits the MuleSoft APIGateway, it triggers the PlainID Authorizer which reaches out to the PlainID runtime for an authorization decision. PlainID delivers the Authorization decision based on the policies configured in the Policy Administration Point (PAP).
The PlainID MuleSoft Authorizer can provide two types of responses:
1. Permit / Deny - allow to or block the request as-is

Architectures

  1. The end user accesses the application.
  2. The user is redirected to complete the authentication process on the Identity Provider (IdP).
  3. The API call is intercepted by MuleSoft API GW.
  4. The PlainID Authorizer requests an access decision from the PlainID PDP which responds with a dynamically calculated access decision based on the policies configured within the PlainID Authorization Platform. Access Decisions is enforced at the API GW. Request can be denied, permitted as-is, or permitted with PlainID enriching the access token with further Authorization instructions.
  5. The API call is passed on to the service layer

Technology

  • API Gateways

Capabilities

  • Manage
  • Enforce

Auth Patterns

  • API Authorization

Need help integrating?

Our experts can help you architect the perfect authorization strategy for your stack.

Contact Support

Better Together

Connect Context. Centralize Policy. Enforce Everywhere.