Access Control Services Overview

About Access Control Services

Access Control Services (ACS) are security services provided on predix platform for application developers to add granular authorization mechanisms to access web applications and services without having to add complex authorization logic to their code. ACS works in conjunction with the User Account and Authentication (UAA) security service.

Access Control Services provide the following benefits:

  • Ability to maintain access-decision data as policies and attributes.
  • Exclusive security for multiple clients using the service, since the ACS services are tenant-aware.
  • Support for fine-grained authorization policies.

Additional Information

Exploring Access Control Service - ACS Guides

ACS Deployment Architecture

The following diagram shows how ACS services are deployed in cloud foundry.

In this flow:

  1. An administrator sets up policies and user privileges using ACS.
  2. An application user requests data using a browser.
  3. The web application sends the authentication request to UAA. If the user is set up in UAA, the authentication request is approved, the user is authenticated, and the token is issued to the web application. If the data request already contains a valid token, this step is not required.
  4. The web application passes the data request and JWT token to the web services.
  5. The web services use ACS REST APIs to authorize a user based on a policy evaluation.
  6. Once the user is authorized, the data is returned to the web application.

Access Control Services Architecture

Access Control Services consist of the following primary services:

  • The Policy Management service provides CRUD operations for application policies.

  • The Attribute Management service provides CRUD operations for user and resource attributes.

  • The Policy Evaluation service processes policy evaluation (such as access control) requests for an OAuth client.

The following diagram shows the Access Control Services architecture.

Attribute Management Service

The Attribute Management service allows you to create attributes for users and resources.

Attributes are characteristics of a user or resource that can be used to make access-control decisions. An attribute is identified by an issuer, the entity that asserts the attribute, and a name that describes the attribute. Some example of user and resource attributes include the organization, site, and group to which a resource belongs. Attributes are used in conjunction with access-control policies for user authorization.

Policy Management Service

The Policy Management service allows you (with required privileges) to create, read, update, and delete access-control policies.

An access control policy contains a set of rules that determine the required permissions for the specified users and resources. The rules can take into consideration the user attributes, the action the user wants to perform, the resource URI, and any resource attributes that further describe the resource.

Policy Evaluation Service

The Policy Evaluation service evaluates access-control policies based on web service requests for authorization.

A web service request consists of the following components:

  • Resource information: Relative URI path of the request.

  • Subject information: The Policy Evaluation service extracts this information from the JSON Web Token (JWT) used to authenticate with the web service.

  • Action information: HTTP method used for the request.

The Policy Evaluation service leverages the centralized identity management feature offered by the User Account and Authentication (UAA) service. Once a user is set up in UAA, the JSON Web Token (JWT) issued to the user can be passed with a resource request to the Policy Evaluation service for authentication and authorization. Conditions defined in access-control policies are used to evaluate a resource request and return access control decision.

If a policy condition returns true, access control decision defined in this policy is returned. Decision could be DENY or PERMIT. In addition, the access control decision includes:
  • Subject’s attributes
  • Requested resource’s attribute
  • Resources that matched the policy evaluation request's resource identifier based on the attribute URI templates defined in the policy.

If a policy conditions return false, the policy does not apply to the request and the evaluation continues to the next policy in the policy set. If none of the policies apply to the request, the overall state of the access control decision is NOT_APPLICABLE.

ACS Attribute Connector Architecture

Extend Access Control Services to provide authorization from external attribute sources.

ACS support for external attribute sources provides the following benefits:

  • Allow ACS policies to reference attributes of a protected resource from an external source (such as Predix Asset service).

  • Allow ACS policies to reference attributes of a currently authenticated user from an external source (such as federated identity management):
    • Removes the need to store user attributes in the Attribute Management Service.
    • Attributes that are available in a Security Assertion Markup Language (SAML) assertion or OpenID Connector (OIDC) provider can be part of the ACS evaluation request that is pushed with the UAA validation token.
Access Control Services implements support for external attribute sources with the following functions:
  • A custom ACS attribute adapter that pulls resource or subject attributes from a specific external attribute source. If an adapter is configured and is active, it will be used as the source for attributes instead of the built-in attribute store managed by the Attribute Management Service (see acs-overview.html#concept_tjm_4p3_mr).
  • A common ACS attribute connector that configures the endpoint and credentials for the ACS attribute adapter used when performing policy evaluations.

The following diagram shows the ACS attribute connector architecture.

There is a separate service call required to access external attributes for policy evaluation (see acs-using-access-control-services.html#reference_b1026668-eae3-4f64-909c-2ffaa5a843cf for more information). Connectors should be used only when the additional cost is justified. For example:
  • The system of record for attributes is an external resource that is not related to the business data store.
  • It is not feasible for the resource service to get external attributes from the attribute data store.