...
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.