Cloudentity ACP authorization policies

Description of ACP authorization policies

Policy concept

As the core of Authorization Control Plane (ACP), authorization policies introduce the multilevel authorization as the response to modern access control requirements.

Authorization validators

Authorization policies are built around the authorization validators concept, which covers a vast range of authorization control mechanisms, including:

  • Current user attributes and roles,
  • Device context (for example, location, known/unknown status, attributes),
  • Application attributes,
  • Current request context,
  • User authentication (MFA) checks,
  • User permissions,
  • Privacy and consent (PII),
  • Custom-built validators,
  • Conditional (allowing to build a complex validation logic),
  • Embedded policy (allowing the reuse of policies),
  • Others.

Policy editor

ACP comes with a user-friendly policy editor UI, which can be used by non-developers to quickly understand and create their own policies with no need to understand or read code or configuration.

CI/CD

ACP authorization policies are easy to integrate into your CI/CD pipeline. Policies can be written in a user-friendly YAML format and imported easily.

Authorization recovery

Policies introduce the concept of the policy recovery, which allows returning an additional information on the validation failure to the requesting client. The policy recovery enables user-friendly flows and rich client-api integration workflows.

Applying policies

OAuth scope request

When an OAuth client requests authorization, it sends a list of scopes to be granted by the user. Each scope can have an authorization policy assigned. Such a policy gets validated when a consent screen is displayed to the user. If the policy does not authorize the current user and/or the client to get a specific scope, the scope is not granted to the client.

OAuth token issuing

When an OAuth client requests authorization, a policy is validated even before a consent page is displayed to the user. If the policy does not authorize the requesting client, the token is not issued.

OAuth client creation

Policy per client

When a developer creates an OAuth client, a policy is validated to verify if this client can be created by this specific developer. It allows to limit the number of developers who can create a client connected to a particular authorization server.

Policy per scope

While creating an OAuth client, a developer can request scopes to be asked for during authorization. Each scope can have a specific authorization policy assigned. This policy gets validated when a developer lists available scopes in the development portal UI and during the actual client creation request. It allows to limit scopes that a particular client can request.

Note

Cloudentity MicroPerimeter Security can enforce authorization policies during the API access.

Sample Policy

Multilayer policy governance

ACP policies are evaluated in a cascading way when multiple authorization policies apply to the same user. There are two separate policy evaluation streams:

  • Flows that involve the user interaction (user policies)

  • Flows that involve the machine identity outside the context of the user (machine policies), for example, client credentials flow.

There are the following policy evaluation levels in both kinds of streams:

  1. Workspace level

    All requests that happen in the context of the workspace have this policy evaluated first. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, ACP responds with the 403 error to a token request.

  2. Application level

    If a policy is assigned to a client application that requests a token, the policy is evaluated as a part of the OAuth authorization and authentication process. To learn more this process, see OAuth documentation. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, ACP responds with the 403 error to a token request.

  3. OAuth scope / service level

    If an application requests a specific scope with a policy assigned to it, the policy is evaluated. If the policy passes, the execution proceeds to the next step of the policy evaluation process. If the policy fails, ACP still returns a token to the application, but the token does not include the scopes for which the policy evaluation ends with a failure.

  4. API layer level

    API layer is evaluated if you use the authorizers as an API enforcement layer. API policies evaluate the context of the request and context of the client or the user that is included in the access token. If the policy passes, the authorizer allows this API request. If it fails, the API request is blocked. If you are using Istio Authorizer, you can add a layer of policy orchestration using the native Istio policy and describe the conditions under which the ACP authorization needs to be evaluated.