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

Usage:
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 ()

Usage:

The ‘DefaultAttributeFinder’ talks to the underlying user store to read user attributes. It is by default registered for all the claims defined under ‘http://wso2.org/claims 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/entitlement.properties file. You can also add more attribute finders keeping the default one as well.

Sample:

https://docs.wso2.com/display/IS510/Writing+a+Custom+Policy+Info+Point
 
Abstract Class / Default Implementation:

org.wso2.carbon.identity.entitlement.pip.DefaultAttributeFinder

2. PIP Resource Finder

Usage:
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/entitlement.properties file in case of a different logic required at resource finding. 

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.pip.DefaultResourceFinder

3. PIP Extension

Usage:
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/entitlement.properties file

Interface:
org.wso2.carbon.identity.entitlement.pip.PIPExtension

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,

PAP.Entitlement.Data.Finder.1 

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.pap.CarbonEntitlementDataFinder

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.

PAP.Policy.Publisher.Module.1

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.policy.publisher.CarbonBasicPolicyPublisherModule

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.

PAP.Policy.Version.Module 

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.policy.version.DefaultPolicyVersionManager

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.

PAP.Status.Data.Handler.1 

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.SimplePAPStatusDataHandler

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/entitlement.properties as below.

PDP.Policy.Finder.1= 

Interface:
org.wso2.carbon.identity.entitlement.policy.finder.PolicyFinderModule 

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.policy.store.RegistryPolicyStoreManageModule

2. Policy Store Module

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

Interface: org.wso2.carbon.identity.entitlement.policy.store.PolicyStoreManageModule
Config parameter key should look like,
PDP.Policy.Store.Module= 

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.policy.store.RegistryPolicyStoreManageModule (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.

PDP.Policy.Data.Store.Module=

Abstract Class / Default Implementation:
org.wso2.carbon.identity.entitlement.policy.store.DefaultPolicyDataStore

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.

 Interface:
org.wso2.carbon.identity.application.authentication.framework.handler.authz.AuthorizationHandler

 Abstract Class / Default Implementation:
org.wso2.carbon.identity.application.authz.xacml.handler.impl.XACMLBasedAuthorizationHandler

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

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

Popular posts from this blog

Signing SOAP Messages - Generation of Enveloped XML Signatures

Image
Digital signing is a widely used mechanism to make digital contents authentic. By producing a digital signature for some content, we can let another party capable of validating that content. It can provide a guarantee that, is not altered after we signed it, with this validation. With this sample I am to share how to generate the a signature for SOAP envelope. But of course this is valid for any other content signing as well. Here, I will sign The SOAP envelope itself An attachment  Place the signature inside SOAP header  With the placement of signature inside the SOAP header which is also signed by the signature, this becomes a demonstration of enveloped signature. I am using Apache Santuario library for signing. Following is the code segment I used. I have shared the complete sample here to to be downloaded . public static void main(String unused[]) throws Exception {         String keystoreType = "JKS";         String keystoreFile = "src/main/resour
Read more

How to convert WSDL to Java

Image
Background Basically WSDL (Web Services Development Language) is an XML document used to describe or locate web services. WSDL stands for Web Services Description Language. The document describes a Web service. It specifies the location of the service and the operations that can be taken.  WSDL2Java is distributed with Axis2 package of Apache and need to set-up Axis2 to use this service. A  guide to set-up Axis2  can be found in apache organization documents .WSDL 2.0 is the currently using version. Obviously JDK should be properly installed too. Note: For the 3rd method you are not needed to set these things by yourself. The WSDL document includes server Java programs for Web services and generated classes using WSDL2Java feature includes client stubs, server skeletons and data types that can help in writing client side. The generated stub classes play a great role in distributed computing and if you are interested can read on  what are stub classes . In brief talking, 
Read more

How to Write a Custom User Store Manager - WSO2 Identity Server 4.5.0

Image
With this post I will be demonstrating writing a simple custom user store manager for WSO2 Carbon and specifically in WSO2 Identity Server 4.5.0 which is released recently. The Content is as follows, Use case Writing the custom User Store Manager Configuration in Identity Server You can download the sample here. Use Case By default WSO2 Carbon has four implementations of User Store Managers as follows. org.wso2.carbon.user.core.jdbc.JDBCUserStoreManager org.wso2.carbon.user.core.ldap.ReadOnlyLDAPUserStoreManager org.wso2.carbon.user.core.ldap.ReadWriteLDAPUserStoreManager org.wso2.carbon.user.core.ldap.ActiveDirectoryLDAPUserStoreManager Let's look at a scenario where a company has a simple user store where they have kept customer_id, customer_name and the password (For the moment let's not worry about salting etc. as purpose is to demonstrate getting a custom user store into action). So the company may want to keep this as it is, as there may be other serv
Read more