OPA for HTTP Authorization

Open Policy Agent[1] is a promising, light weight and very generic policy engine to govern authorization is any type of domain. I found this comparion[2] very attractive in evaluating OPA for a project I am currently working on, where they demonstrate how OPA can cater same functionality defined in RBAC, RBAC with Seperation of Duty, ABAC and XACML.  
Here are the steps to a brief demonstration of OPA used for HTTP API authorization based on the sample [3], taking it another level up.
Running OPA Server First we need to download OPA from [4], based on the operating system we are running on.  For linux, curl -L -o opa https://github.com/open-policy-agent/opa/releases/download/v0.10.3/opa_linux_amd64 Make it executable, chmod 755 ./opa Once done, we can start OPA policy engine as a server.
./opa run --server Define Data and Rules Next we need to load data and authorization rules to the server, so it can make decisions. OPA defines these in files in the format of .rego. Below is a sample …

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


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

Interface: org.wso2.carbon.identity.entitlement.policy.store.PolicyStoreManageModule
Config parameter key should look like,

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.


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.

  2. BlueHost is ultimately the best hosting company with plans for all of your hosting requirements.


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)

How to convert WSDL to Java