Main Deployment Patterns

Policy Administration Point (PAP)

Provides a user interface for managing the life-cycle of policies. That typically includes policy authoring, managing, testing, analyzing, and version control.

Policy Decision Point (PDP)

The policy decision point is responsible to calculate the required access decision, based on the collection of attributes that are sent in the authorization request, pulled from external repositories and environmental attributes. The decision is calculated based on the policies that are associated with the requesting party.
The PlainID PDP, is designed to support different access patterns that provide both flexibility for the application and consistency with the defined policies.
The PDP is built for large scales and high performance and can be deployed in a distributed architecture.

Policy Enforcement Point (PEP)

The PEP enforces policy decisions in response to an access request. The PEP can be implemented within the application or as an external component that stands before the application or data.
Please see the detailed deployment patterns for enforcement options.

Policy Information Point (PIP)

The policy information points are the sources of attributes used by the policy decision, to address the authorization requests based on the defined policies.
The policy information points in PlainID, are mapped by a virtualization layer, that enables usage of multiple sources at the same time, including virtual and API based sources.

Problem

The main challenges with authorizations for the service mesh are as follows:

• Resilient
• Scalability
• Security
• Performance
• Decision enrichment
• Management and distribution

Opportunity

A seamless authorization solution for your service mesh in the form of a sidecar service. With the flexibility and independent deploy-ability of services, the Policy Manager sidecar provides a stable and abstracted capability to control authorization of your microservices and the functionality and data they expose, providing a lightweight and simplified access control solution.

• High performance
  In the microservices framework, access decisions are expected to be efficient and fast. The decision whether an action can or can’t be performed should be taken in a matter of microseconds or less. Therefor the authorization decision should be as close as possible to the service, within the same pod, to reduce any communication latency, which is common in other types of architectures.
• Tight security
  Having the decision within proximity to the service, within the same pod, addresses an important security concern. The service doesn’t have to reach out to the network in order to know whether access is permitted or denied.
• Reduce development efforts
  Development of microservices, is typically lean and focused on the relevant functionality of the microservice. Supporting authorization enforcement in this type of architecture, reduces the workload from the developer, since access decisions are made and enforced outside of the service.
• Central control
  In a distributed architecture central control is crucial, to enable consistency in the access decisions across all components, and full visibility to who has access to what.

Architecture Flow:

1. Incoming transaction is intercepted by the envoy gate way.
2. The request is directed to the policy manager PDP, which then makes a decision:
   • Either enable or block this transaction.
   • Or, enrich the request header with authorization data.
3. The approved transaction proceeds to the application service.

Problem

In most cases, access decisions are embedded within the webapps or the portal code. Making it difficult to make changes and additions, in addition to lack of visibility into who can access what.

Opportunity

Externalizing Authorizations enables:

• Flexibility – managing access decisions outside from the code.
• Low maintenance – changing and adding to the access decisions does not required recoding of the app.
• Visibility – access of users to application resources is visible outside of the application code, enabling business owners and auditors to gain better insights to access.

PlainID supports portal access through two patterns; through a Web App that provides the enforcement of the authorization (PEP) or through a Web Access Management

Architecture Flow:

1. An authenticated user requests access to areas within the portal.
2. The portal uses the relevant web apps to address the user’s request.
3. The web apps approach the decision engine, asking for list of web assets/controls approved for the user, based on which proceed with the request. The authorization response is calculated based on the user attributes, assets attributes and environmental attributes at the time of access.
4. The web apps proceed to retrieve related data based on the request and the approved assets and functions.
5. The response is then returned to the portal interface.

Best Practices:

PlainID best practices, recommend using the “user access token”, that provides a list of security controls for the portal to act on for the duration of the user session. Combing that with the policy resolution end point, provides in addition control over data that the portal enables access to.

Problem

Most applications embed access decisions within the code, which makes it very complicated to change those decisions, resulting in high maintenance, and lack of visibility into what users can access.

Opportunity

Externalizing Authorizations enables:

• Flexibility – managing access decisions outside from the code.
• Low maintenance – changing and adding to the access decisions does not required recoding of the app.
• Visibility – access of users to application resources is visible outside of the application code, enabling business owners and auditors to gain better insights to access.
• The flexible data module, supported by the policy, enable customization of both the assets and the actions associated with them, so basically any app can define its own language for authorization enforcement.

Architecture Flow:

1. An authenticated user approaches the app.
2. The app approach the decision engine (PDP), using one of the standard RESTful APIs interfaces, asking for list of assets approved for the user, based on which proceed with the request. The authorization response is calculated based on the user attributes, assets attributes and environmental attributes at the time of access
3. The app proceeds to enable access to authorized application objects and retrieve related data based on the request and the approved assets and functions.
   The response is then returned to the user.

Note:
Typically, application access would be based on the user access token, since it provides flexibility to the app and reduces the overall performance. However, any of the other Authorization End-points can also be easily used by the application where needed

Problem

Consistently protecting the same data assets across different databases is a challenge that many data owners struggle with. Often there is a lack of transparency around the authorizations that are enabled due to the different layers of permissions that can surround a database.

Opportunity

Policy manager for managing access to data will provide the following main benefits

• Unified Access Management
  Manage access to data objects using a unified interface, that can provide consistent access decisions.
• Fine-grained access solution
  Use an access solution that supports fine-grained access controls, both on row and column level.
• Central enforcement layer
  Implement a central enforcement layer for all data access.

Architecture Flow:

• Solution Pattern via Data Virtualization (JDBC access)
  1. Authenticated users access the application/service
  2. Applications and services uses the Data Virtualization platform in order to access the data
  3. The data virtualization platform request a “policy resolution” decision from the Policy Manager PDP at the time of access.
  4. The response is translated to a where clause and a list of authorized columns, this is used to modify the original SQL query.
  5. The data virtualization platform continues to the relevant repositories with the modified query.
     Required data, with the filtering based on the access controls, is send back to the application.
• Solution Pattern via API Gateway (API access)
  1. Authenticated users access the application/service
  2. Applications and services use data APIs to access the data.
  3. The request is directed through an API Gateway, where it’s intercepted by the “data interceptor”.
  4. The data interceptor request a “policy resolution” decision from the Policy Manager PDP at the time of access.
  5. The response is translated to a data filtering cluse and a list of authorized data elements, this is used to modify the original data query.
  6. The data API request continues to the relevant repositories with the modified query.
  7. Required data, with the filtering based on the access controls, is send back to the application.

Problem

Access management solutions typically relay on a persistent repository to retrieve users’ authorization, that leads to high maintenance that results in lack of flexibility and low granularity of the authorizations that can be provided.

Opportunity

Continues Authentication-Authorization process
PlainID will continue the Authentication process carried out by the access management solution, to provide the full adaptive access the user is entitled to.

• End-to-end IAM services for the application owner – Authentication and Authorization combined.
• Secure IAM process – What user can do integrated and based on who the user is.
• Policy Based Access control
• PlainID adds a Policy Layer on top of Identities & Roles, to better define and control the connection between identities and what identities can do and access.
• Enable business owners control of their access decisions.
• Reduce overall access decisions to manage.
• Run-Time authorizations
• PlainID extends the identity context, to be used at run time, enabling real time access decisions.
• Contextual & Fine-grained support: Enhance access management managed identities to enable dynamic entitlements and contextual & fine-grained resource access.
• Enable zero-trust/CARTA: Add the multi-layer decision approach to support zero-trust and CARTA framework.

Architecture Flow:

1. A user access an app
2. The user is then redirected to the access management solution for the authentication process.
3. The access management solution approach the decision engine (PDP), using a “user token” request. The authorization response is calculated based on the user attributes provided by the access management (OIDC, SAML, JWT), application and environmental attributes at the time of access.
4. The response in the form of “claim key, claim value” is embedded in the response token.
   The response token is then returned to the user to continue both the login and access process.

Problem

IAM/IGA solutions typically relay on usage of Roles to provide course-grained decisions. That typically results in explosion of roles and high maintenance.
In addition, those solution are limited to provisioning based enforcement, which is no longer the main method required by many of the modernized apps and platforms.

Opportunity

Policy Based Access control
PlainID adds a Policy Layer on top of Roles, to manage and control the explosion of Roles with PlainID dynamic policies. That in addition to enable business owners control of their policies, using a near native language way to state the business decisions and translate that to the relevant implementation within IAM/IGA platform.
Run-Time authorizations
PlainID extends the identity context, to be used at run time, enabling real time access decisions, and extending the IGA tool reach to areas it couldn’t cover before, such as microservices, APIs and Cloud.

Architecture Flow:

1. A joiner, mover or request event is triggered at the IAM/IGA platfrom
2. The IAM/IGA reaches to the decision engine (PDP), using a “user token” request. The authorization response is calculated based on the provided user attributes environmental attributes at the time of the request.
3. The response in the form of “list of roles/entitlements” is provided in the response token.
4. The IAM/IGA continues with the provisioning/deprovisioning process based on the response.