PIP Architecture with WSO2 Identity Server

WSO2 Identity Server is based on the sun xacml implementation.  Sunxacml provides an interface for plugging different PIP implementations as modules. “AttributeFinderModule” is the interface that would allow us to do this

But WSO2 identity Server would not force us to use it. Because sunxacml’s interface  seems to be more complex and Carbon platform features would not be inherited to those AttributeFinderModules. Therefore WSO2 identity Server exposes simple interface with more sophisticated functions by wrapping the “AttributeFinderModule”.

Therefore If we are writing a PIP module for WSO2 Identity Server,  we need to register it with the “CarbonAttributeFinder” . Also this PIP moudle must be implemented the “PIPAttributeFinder” interface in org.wso2.carbon.identity.entitlement.pip package

Lets see how pip layer has been implemented in the WSO2IS. I hope following sample diagram would help you to understand it.  Please sorry..!! my drawing are not much good 🙁 .

There are actually three-phase that PIP layer (CarbonAttributeFinder) comes in to play.

Initialization of the external PIP attribute finder module

1. When WSO2 Identity Server startup,  entitlement core component of the WSO2Identity Server is started, It calls to “EntitlementExtensionBuilder” to build the configuration that are used for initializing the entitlement engine

2. “EntitlementExtensionBuilder” reads the entitlement configuration file in the file system and create the configuration data.

3. It initializes the listed PIP attribute finder modules in that entitlement configuration file

4. Then these initialization and configuration data are kept in the “EntitlementConfigHolder”

Initialization of the entitlement engine

5 Entitlement Engine (PDP) is initialized (When 1st request comes or PAP API is accessed)

6. PDP initializes the “CarbonAttributeFinder”

7. In the initialization process of “CarbonAttributeFinder”, It reads PIP attribute finder data from the “EntitlementConfigHolder”

8. “CarbonAttributeFinder” calls to all registered PIPs. Then it asks for the supported attributes of each PIP and reads them. Then keeps support attribute ids in a map as the key and the entry as the PIPs that are published it.

XACML request with missing attributes

9. XACML request is hit with the PDP

10. If there is a missing attribute id in the XACML request PDP calls to “CarbonAttributeFinder” for help

11. “CarbonAttributeFinder” check whether this  an attribute id is supported.  If is supported, It calls to all PIP attribute finder modules that support this attribute id.  Then each PIPs retrieve the attribute value of it.
Then results from each PIP are combined and sends back to the PDP for request evaluation

Discuss this article on Stack Overflow

Leave a Reply

Your email address will not be published. Required fields are marked *