Beyond PSD2 for a Better Open Banking Expereince

PSD2 is acting as a catalyst in the digital transformation happening in the Banking industry. While meeting the compliance requirements of PSD2, financial institutes are excited to make use of the new business models and opportunities opened by this laid foundation. More the customers and partners we can reach, more the business activities and more the revenue. Making the banking functions more accessible and reactive will be a key enabler to provide a seamless experience to these parties, including internal banking staff whom directly affects the business efficiency.
IAM plays a critical role in improving business accessibility without compromising the system boundaries. PSD2 mandates strong customer authentication(SCA), setting the bar high for user authenticity, while keeping few exemptions, not to bother payment services user(PSU) with SCA for every little transactions. While adhering to this policy will make an institute PSD2 complaint, if they can react fast to the fraud rates…

WSO2 Identity Server - Extension Points - Part 3 - XACML

This is the third of a series of posts on extension points available in WSO2 Identity Server, with relevance to separate protocols.

Previous posts can be found at,
With the XACML architecture there are 4 main separate components as,
  • PIP (Policy Information Point) - serves information required for policy evaluation.
  • PAP (Policy Administration Point) - serves capabilities to govern the policies.
  • PDP (Policy Decision Point) - make decision on incoming requests whether to permit or deny based on the defined policies and information collected from PIP.
  • PEP (Policy Enforcement Point) - the interception point which checks and honors the policy decision.

WSO2 Identity Server can act as all these 4 components. In this post we will check on the extendability of these components and their usages.

Policy Information Point(PIP) modules

When the information available locally is not enough to evaluate a XACML request

eg: We need to authorize the user depending on their age, which is not directly available in current user store.

1. PIP Attribute Finder ()


The ‘DefaultAttributeFinder’ talks to the underlying user store to read user attributes. It is by default registered for all the claims defined under ‘ dialect’. If the user attributes needs to be read in from another location or some other deviation is required for default claim retrieval process this extension should be used (by specifying the full qualified custom class name, under "PIP.AttributeDesignators.Designator.1") which can be found at [IS_HOME]/repository/conf/identity/ file. You can also add more attribute finders keeping the default one as well.

Abstract Class / Default Implementation:


2. PIP Resource Finder

To register a PIP resource finder with the PDP. The default resource finder finds the resources of the underlying registry. We need to implement this interface and add an entry to file (by specifying the full qualified class name, under "PIP.ResourceFinders.Finder.1") which can be found at [IS_HOME]/repository/conf/identity/ file in case of a different logic required at resource finding. 

Abstract Class / Default Implementation:

3. PIP Extension

PIPExtensions will be fired for each and every XACML request - which will give a handle to the incoming request. Can be used to carry out custom checks or updates for XACML request, before sending to the PDP. Configured at specifying the full qualified class name, under "PDP.Extensions.Extension.1") which can be found at [IS_HOME]/repository/conf/identity/ file


Policy Administration Point(PAP) modules

1. Entitlement Data Finder

This is the implementation of the policy meta data finder module which finds the resource in the under-line registry by default. Any deviation to policy meta data finding can be written as an extension at this point,


Abstract Class / Default Implementation:

2. Policy Publisher Module

policy publisher module that is used to publish policies to external PDPs. External PDP can be identity server or else can be anything. Therefore this interface provide an extension to publish policies to different PDPs.


Abstract Class / Default Implementation:

3. Policy Version Manager

This manages the versions of XACML policies. If a deviation is required for supported maximum version etc. this can be used.


Abstract Class / Default Implementation:

4. PAPStatusDataHandler

A handler that would be fired after an entitlement policy admin action is done. If any action is required to be done in relevance to this admin action, this extension can be used.


Abstract Class / Default Implementation:

Policy Decision Point(PDP) modules

1. Policy Finder

Policy manage module is an extension point where XACML policies can be stored and loaded into the PDP from different sources. There can be more than one policy finder modules configure in the file [IS_HOME]/repository/conf/identity/ as below.



Abstract Class / Default Implementation:

2. Policy Store Module

Handles the add, update, delete operations of the policies. Any modification to these operations can be done via this extension.

Config parameter key should look like,

Abstract Class / Default Implementation: (by default this is acting as the policy finder as well.)

3. Policy Data Store Module

This is the entitlement policy data store that is used to persist metadata of the policies such as global policy combining algorithm and perform operations such as get, set, remove policy data stored in carbon registry. Any deviations to this can be made via this extension using below config.


Abstract Class / Default Implementation:

Policy Enforcement Point (PEP) modules

When providing fine grained authorization for service providers WSO2 Identity Server act as a PEP itself and calls the own PDP to get authorization decisions. This is an extension point exposed by Identity Application Authentication Framework to customize authorization logic. By default the implementation is done based on XACML, which can be extended to cater for any deviations here acting as PEP.


 Abstract Class / Default Implementation:

At IS_HOME/repository/conf/identity/application-authentication.xml,
Under, <Extensions>,

Hope this will help in extending the functionalities to have your freedom in have the exact requiements catered. Cheers!


  1. Hey..As u mentioned " When providing fine grained authorization for service providers WSO2 Identity Server act as a PEP itself and calls the own PDP to get authorization decisions"
    Is PEP only at authentication only? If not then how does it work.
    When i tried it was happening at time of authentication itself.


Post a Comment

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

How to send an HTML email in Java (Using Google SMTP Server)

Adding Custom Claims to the SAML Response - (How to Write a Custom Claim Handler for WSO2 Identity Server)