In this blog post. We are going to visit some architecture design of a XACML engine. When it comes to XACML and Open source world, WSO2 Identity server is one of a major player. Latest release of WSO2 Identity Server support XACML 3.0 based on Balana XACML implementation. As source code, distribution and documents are freely available. We can dig in to them and understand the architecture behind it. This blog post just try to give you some idea of the architecture of the XACML engine (Entitlement engine) of WSO2 Identity Server.
WSO2 identity Server’s XACML engine has two manjor component i.e PAP and PDP. Here i am going to blog some details on Policy Decision Policy (PDP) only.
Following diagram would help you to get some idea about the components inside PDP.
Lets go one by one of them
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. Functions such as followings can be done via calling this API.
invalidating caches
refreshing policy, attribute, resource finder modules
retrieving PDP configurations
function for testing the Test PDP with given sample request or sample request with given policies
Entitlement Service
Actual XACML authorization API has been exposed via this API as a web service. This service supports following three communication methods with PEP
SOAP based web service
Thrift binary protocol (which is much faster than SOAP)
WS-XACML (This is standard way but not popular)
Balana PDP
This is the core of the engine. Balana PDP has been initialized with all 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. But this instance has been initialized with 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 PAP store. Web service API for Balana Test PDP has been exposed via Entitlement Admin Service with method name “doTestRequest()”
Carbon Policy finder
This module finds policies from different policy stores to evaluate XACML request. Following is the high level diagram
Any number of policy finder modules can be plugged with carbon policy finder. You need to implement the CarbonPolicyFinderModule interface to write a new module and register it using entitlement.properties configuration file. By default, WSO2 Identity Server is shipped with carbon registry based policy finder module where it can retrieve policies from a registry collection, where collection path can be configurable using a property value in entitlement.properties configuration file.
All modules would be initialized and policies would be loaded in to in-memory, when Carbon policy finder is initialized. Loaded policies are kept as a policy collection where you can implement a your own implementation for that. Written policy collection implementation can be registered using entitlement.properties configuration file. Default implementation uses a in-memory cache and creates an effective policy for given XACML request.
Therefore carbon policy finder always finds effective policy from the policy collection where it is recommend to kept in-memory. But if any update in policy store is happened, carbon policy finder can be reinitialized automatically by the module that you have written Or you can reinitialized using web service API (Entitlement Admin Service). Also you can manually do it using Identity server management console.
When you are writing a new module, you need to consider about following things other than policy retrieving andreinitializing such as
policy ordering, policy combining algorithm and how to retrieving referenced policies.
Carbon Attribute finder
This module helps to find the missing attribute for given XACML request. Following is the high level diagram for both carbon attribute and resource finders
Any number of PIP attribute finder modules can be plugged with carbon attribute finder. You need to implement the PIPAttributeFinder interface to write a new module and register it using entitlement.properties configuration file. By default, WSO2 Identity Server is shipped with DefaultAttributeFinder that talks with under line user store of the Carbon. (Default user store is ApacheDS where it can be changed using user-mgt.xml file)
All modules would be initialized and supported attributes Ids are retrieved for each module. In runtime, Carbon attribute finder check for support attribute id and hand it over to the proper module to handle. Caching machine is used by Carbon attribute finder for caching the findings Or else attribute finder module, itself can handle it.
Carbon resource finder
This is used to retrieve children or descendants resources of a given root level resource value. Basically to fulfill the requirement of multiple decision profile. 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 talks to Carbon registry resources.