Addressing Security Concerns with WSO2 Governance Registry Policy Store

  • By Eranda Sooriyabandara
  • 10 Oct, 2013

Applies to

WSO2 Governance Registry Version 4.5.3 and above
WSO2 Identity Server Version 4.1.0 and above
WSO2 Enterpise Service Bus Version 4.7.0 and above
WSO2 Application Server Version 5.1.0 and above


Table of contents

  1. Introduction
  2. XACML
  3. Terminologies used in XACML policy enforcement
  4. System Architecture
  5. Setting up the servers
  6. Deploying artifacts to servers
  7. Sending requests
  8. Advantages of having Governance Registry as the policy store



A typical service-oriented enterprise has mainly three entities in interaction; service consumers, services, and resources. To ensure system integrity and for these entities to perform appropriate actions in the SOA environment the enterprise needs to have a various types of policies that are defined and enforced. In this article, we describe how an enterprise can enforce an XACML (eXtensible access control markup language) policy using WSO2 ESB as the Policy Enforcement Point (PEP), WSO2 IS as Policy Administrative Point (PAP), Policy Information Point (PIP), and Policy Decision Point, and WSO2 Governance Registry as the Policy Retrieval Point (PRP).

We first provide a brief introduction to XACML and then we will show you how to set the servers with special configurations with the content, and finally illustrate a sample request with the expected response for an authorized user.



XACML (eXtensible Access Control Markup Language) is an XML-schema based policy language, which is used to describe fine grained access control decision request/response language. It can be used to describe the general access control requirements with the standard extension points for defining new functions, data types, combining logic, etc. as well as it allows to form a query to validate the authorization of the action and to interpret the result.


Terminologies used in XACML policy enforcement

  • PEP - Stands for Policy Enforcement Point where the incoming request is received and the authorization request will be generated and sent over to the authorization engine
  • PIP - Stands for Policy Information Point where information about policy elements such as attribute value and meaning, resource information used in policy, environment in which the particular policy to be evaluated
  • PDP - Stands for Policy Decision Point where the authorization request is evaluated (sent by the PEP) and the decision is made whether to authorize or not. This point in general is called the authorization engine since it is the decision maker for authorization requests
  • PAP - Stands for Policy Administration Point where the policy is managed
  • PRP - Stands for Policy Retrieval Point where the policy is stored and retrieved by the authorization engine to evaluate against the incoming authorization request


System architecture

Here, we are going to restrict users who are from other destinations apart from Sri Lanka from accessing the StockQuoteService, which is deployed in the WSO2 Application Server in the service URI https://${host}:9446/services/SimpleStockQuoteService/. In order to do this, we are going to create a proxy service in WSO2 WSO2 ESB, which is in the middle of the service and client. To carry out the authorization validation, we add an Entitlement Mediator in sequence to the proxy service, which sends the client request to the WSO2 IS. WSO2 IS validates the request against the EntitlementPolicy policy promoted to PDP, which is retrieved from WSO2 Governance Registry and acts as the PRP or policy store. After authorizing the request, it sends the request to the SimpleStockQuoteService, which is the original service, and sends the response to the client via WSO2 ESB. See the figure below.


<Policy xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"  PolicyId="EntitlementPolicy" RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable" Version="1.0">
   <Rule Effect="Permit" RuleId="Rule-1">
               <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                  <AttributeValue DataType="">read</AttributeValue>
                  <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="" MustBePresent="true"></AttributeDesignator>
         <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:any-of">
            <Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"></Function>
            <AttributeValue DataType="">Sri Lanka</AttributeValue>
            <AttributeDesignator AttributeId="" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="" MustBePresent="true"></AttributeDesignator>
   <Rule Effect="Deny" RuleId="Deny-Rule"></Rule>


Setting up the servers

As mentioned in the system architecture, we need to set up the servers to ensure the system functions properly. Let's check the servers one by one.


WSO2 Enterprise Service Bus

  1. Set the port offset to 1 in $APPSERVER_HOME/repository/conf/carbon.xml


WSO2 Governance Registry

  1. Set the port offset to 2 in $APPSERVER_HOME/repository/conf/carbon.xml


WSO2 Identity Server

  1. Mount Governance Registry /_system/governance/trunk/policies collection to Identity Server /_system/governance/repository/identity/Entitlement/Policies collection using JDBC mount. Click here for the registry mount documentation. Note that you should not enable clustering since Identity Server and Governance Registry are not the same type of servers.
  2. Change the embedded LDAP userstore to JDBC userstore where WSO2 ESB and WSO2 IS both share the same userstore. Click here for documentation of setting up JDBC userstore in Identity Server


Registry mount configuration

<remoteInstance url="https://localhost:9444/registry">
       <cacheId>[email protected]:mysql://localhost:3306/gregdb</cacheId>

    <mount path="/_system/governance/repository/identity/Entitlement/Policies" overwrite="true">

    <handler class="org.wso2.carbon.identity.entitlement.policy.finder.registry.RegistryPolicyHandler">
        <filter class="org.wso2.carbon.identity.entitlement.policy.finder.registry.RegistryPolicyMediaTypeMatcher">
            <property name="mediaType">application/xacml-policy+xml</property>


WSO2 Application Server

  1. Set the port offset to 3 in $APPSERVER_HOME/repository/conf/carbon.xml


Deploying artifacts to servers

After setting up the servers start them with "-Dsetup" option to create new database tables. Then we need to add the artifacts which we are using as follows.


WSO2 Application Server

  1. Deploy SimpleStockQuoteService service


Deploying service


Deployed service list


WSO2 Governance Registry

  1. Add EntityPolicy using Metadata -> Add -> Policy


Adding policy


Policy list


When the policy is added from the Governance Registry it will also appear in the entitlement policy list in the Identity Server


WSO2 Identity Server

  1. Promote the policy to the PDP

WSO2 Enterprise Service Bus

  1. Create in-sequence (InSeq) as below
    <sequence xmlns="">
       <entitlementService remoteServiceUrl="https://localhost:9443/services" remoteServiceUserName="admin" remoteServicePassword="admin">
             <makefault version="soap11">
                <code xmlns:soap11Env="" value="soap11Env:Server"/>
                <reason value="Access Denied"/>
             <log level="full"/>
                   <address uri="https://localhost:9446/services/SimpleStockQuoteService/"/>
       <header xmlns:wsse="" name="wsse:Security" action="remove"/>
  2. Create the out-sequence (OutSeq) as below
    <sequence xmlns="">
  3. Then create a proxy service using above in-sequence and out-sequence and then apply the security with the UserNameToken. In addition we used the original StockQuoteService wsdl as the publish WSDL. Configuration will be as follows
    <proxy xmlns=""
       <target inSequence="gov:/trunk/sequences/InSeq"
       <publishWSDL uri="https://localhost:9446/services/SimpleStockQuoteService?wsdl"/>
       <policy key="conf:/repository/axis2/service-groups/HelloServiceProxy/services/HelloServiceProxy/policies/UTOverTransport"/>


Now the configuration for our set up is done and we can try it out with the help of the try-it feature that is available in the ESB.


Sending requests

To send requests to the service you can use the try-it feature available in the ESB or SoapUI. Given below is a request body and the response body for a request.



<proxy xmlns=""
   <target inSequence="gov:/trunk/sequences/InSeq"
   <publishWSDL uri="https://localhost:9446/services/SimpleStockQuoteService?wsdl"/>
   <policy key="conf:/repository/axis2/service-groups/HelloServiceProxy/services/HelloServiceProxy/policies/UTOverTransport"/>



<ns:getQuoteResponse xmlns:ns="https://services.samples">
   <ns:return xmlns:ax2417="https://services.samples/xsd" xmlns:xsi="" xsi:type="ax2417:GetQuoteResponse">
      <ax2417:lastTradeTimestamp>Wed Oct 02 01:13:00 IST 2013</ax2417:lastTradeTimestamp>
      <ax2417:name>IBM Company</ax2417:name>


Advantages of having Governance Registry as the policy store

  1. Policy validation available
  2. Policies can be re-used
  3. Non-carbon application can access/use policies using its standard APIs (WS, Atom)



We could conclude that in order to have a complete policy governance story you need to have a policy store, the place where all your policies reside. To this end, you can leverage WSO2 Governance Registry as your policy store as it helps you to efficiently govern your policies while enabling several interfaces to access it. Going beyond policy governance, you can also use WSO2 Governance Registry to create your entire governance story to ensure a conducive environment.



About Author

  • Eranda Sooriyabandara
  • Senior Software Engineer
  • WSO2 Lanka (pvt) Ltd.