This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Policy Decision Point (PDP) evaluates policies against access requests provided by Policy Enforcement Points (PEP). To provide the decisions, PDP may also need to query a Policy Information Point (PIP) to gather descriptive attributes about the user or any other missing attribute in the request. Policy Administration Point (PAP) is used to manage the PDP and PIP functionality.

XACML terminology

The XACML reference architecture illustrated above is comprised of the following four 'building blocks'.

  • Policy Enforcement Point (PEP): The system entity that performs access control by making decision requests and enforcing authorization decisions. Basically this is the entity that sends the XACML request to the Policy Decision Point (PDP) and receives an authorization decision.
  • Policy Decision Point (PDP): The system entity that evaluates an applicable policy and returns an authorization decision.
  • Policy Information Point (PIP): The system entity that acts as a source of attribute values. Basically if there are missing attributes in the XACML request that is sent by PEP, PIP would find them for the PDP to evaluate the policy.
  • Policy Administration Point (PAP): The system entity that creates a policy or policy set and manages them.

XACML engine architecture (PDP)

The WSO2 Identity Server is a major player in the XACML and open source world. The Identity Server supports XACML 3.0, which is based on Balana XACML implementation. As the source code, distribution and documentation are available for free, it is possible to analyze and understand the architecture behind it. This section provides some information regarding the architecture of the XACML engine (or the entitlement engine) of the WSO2 Identity Server.

The XACML engine of the WSO2 Identity Server has two major components, i.e., PAP and PDP. This section focuses on Policy Decision Policy (PDP) only.

The following diagram represents the component architecture of the PDP.

The following information provides more details on the various components available in the PDP architecture.

Entitlement Admin Service

All PDP configurations have been exposed via this API as a Web service. You need to have certain privilege to access this API. The following functions can be done by calling this API.

  • Invalidating caches
  • Refreshing policy, attribute, resource finder modules
  • Retrieving PDP configurations
  • Includes the function for testing the Test PDP with a given sample request or a sample request with given policies

Entitlement Service

Actual XACML authorization API has been exposed via this API as a Web service. This service supports the following three communication methods with PEP.

  • SOAP-based Web service
  • Thrift binary protocol (this is much faster than SOAP)
  • WS-XACML (This is the standard way but not popular)

Balana PDP

This is the core of the engine. Balana PDP has been initialized with all the attribute finders, resource finders and policy finder modules that have been plugged with WSO2 Identity Server.

Balana Test PDP

This is same as Balana PDP. However, this instance has been initialized with the PAP policy store. It means, policies that are defined by PAP can be evaluated by using this PDP instance. There is no policy caching or decision caching with this. Therefore this can be only used for testing your policies in the PAP store. Web service API for Balana Test PDP has been exposed via the Entitlement Admin Service with method name “doTestRequest()”.

Carbon Policy Finder

This module finds policies from different policy stores to evaluate a XACML request. The following is a high level diagram of how this works.

Any number of policy finder modules can be plugged with the Carbon policy finder. You need to implement the CarbonPolicyFinderModule interface to write a new module and register it using the entitlement.properties configuration file. By default, WSO2 Identity Server is shipped with a Carbon registry-based policy finder module that can retrieve policies from a registry collection, where the collection path is configurable using a property value in the entitlement.properties configuration file.

All modules would be initialized and policies would be loaded into memory when the Carbon policy finder is used. Loaded policies are kept as a policy collection where you can use your own implementation to access them. A written policy collection implementation can be registered using the entitlement.properties configuration file. The default implementation uses an in-memory cache and creates an effective policy for a given XACML request.

Therefore, the Carbon policy finder always finds effective policies from the policy collection where it is recommended to be kept in-memory. However, if any update in the policy store happens, the Carbon policy finder can be re-initialized automatically by the module that you have written, or you can re-initialize it using the Web service API (Entitlement Admin Service). Also you can manually do it using the Identity Server Management Console.

When you are writing a new module, you need to consider the following in addition to policy retrieving and re-initializing.

  • Policy ordering
  • Policy combining algorithm
  • How to retrieve referenced policies

Carbon Attribute Finder

This module helps to find the missing attribute for a given XACML request. The following is the high level diagram for both the Carbon attribute and resource finders.

Any number of PIP attribute finder modules can be plugged with the Carbon attribute finder. You need to implement the PIPAttributeFinder interface to write a new module and register it using the entitlement.properties configuration file. By default, WSO2 Identity Server is shipped with a DefaultAttributeFinder that communicates with the underlying user store of the Identity Server. The default user store of the Identity Server is ApacheDS where it can be changed using user-mgt.xml file. See Configuring the Realm for more information.

All modules would be initialized and supported attribute Ids are retrieved for each module. During runtime, the Carbon attribute finder checks for the support attribute Id and hands it over to the proper module to handle. A caching machine is used by the Carbon attribute finder for caching the findings or the attribute finder module itself can handle it.

Carbon Resource Finder

This is used to retrieve children or descendant resources of a given root level resource value. Basically it is used to fulfill the requirement of a multiple decision profile. The implementation is same as the PIP attribute finder module. By default, WSO2 Identity Server is shipped with DefaultResourceFinder (which is the implementation of PIPResourceFinder) that communicates with Carbon registry resources.

  • No labels