XACML Reference Architecture based on WSO2 Identity Server

XACML is a powerful access control policy language implemented in XML that can provide a standardized way of validating authorization requests. XACML is the de-facto standard for authorization and provides the ability for a 3rd party application/component to enforce attribute based access control.

Given below is a reference architecture on how different XACML components can work in the deployment.


Policy Enforcement Point (PEP) – PEP is a component that would enforce access control to a resource based on the input received from a Policy Decision Point (PDP). In the actual deployment PEP can be an application that would provide access to a resource. PEP would send attributes to the PDP and the PDP would reply back with response that would be either to allow or deny access to a resource.

Policy Decision Point (PDP) – PDP is the XACML engine that makes policy decisions on behalf of an enforcement point. PDP would make policy decisions based on a set of XACML polices that are deployed in the PDP.

Policy Information Point (PIP) –  PIP is an information source to which PDP can refer to and get more information on an attribute. PIP can be a user store, a flat file, a DB or any data source. For example if the PDP receives a username as an attribute, it can refer to a user store and get the set of roles assigned to that particular role to make a decision on whether to deny or grant access to a resource.

Policy Administration Point (PAP) – PAP is a component from which XACML policies are created/uploaded, edited and deployed to a PDP. An authorized user can come and create these policies in the PAP and the required policies can be deployed to the PDP.

Policy Repository – Policy Repository is where all the XACML policies are stored, policy repository can also manage multiple versions of a XACML policy.

Restricting grant types for an application in WSO2 API Manager

WSO2 API Manager has the capability of restricting which grant types are enabled to a given application. This functionality is provided via the management console of the API Manager. Given below are the steps required

1. App developers should have the required permission in order to restrict the grant types available for an application. Permission given below should be set to a user role associate to the App developer.

2. Once this is done please log out and log into the API Manager’s admin console

3. Now you would see the OAuth URL available in the left navigation, click on this.

4. Here you would see all the applications that are created by the App developer, from this menu select the relevant application to which the grant types should be restricted.

5. Once you are inside the selected application you can define which grant types should be allowed to a given application. By default all grant types are ‘un-checked’ and all grant types are allowed. If you want to override this default configuration select on the required grant types that should be allowed to a given application.

6. Once you are done click on the update button and the configuration would be updated.

Mounting WSO2 instances on a MS SQL Database which is secured via Windows authentication

A multi instance deployment of WSO2 products would require the registry (config and governance) space to be mounted on an external database.  WSO2 Products can be mounted on many types of databases. Below instructions explain how WSO2 products can be mounted on a MS SQL database that is secured via Windows Authentication.

  1. download jTDS from the following link


  1. Extract the folder and copy the jtds-1.2.2.Jarfile to the {WSO2 Product}/components/lib folder
  1. The extracted folder also includes ntlmauth.dllfile in the \x64\SSOfolder copy the dll file to java bin folder(C:\Program Files\Java\jre7\bin)
  1. download and install the jdbc driver for mssql from the following location


  1. Once this is installed set the class path to the following location {JDBC driver Installation Path}\sqljdbc_4.0\enu\auth\x86
  1. Make sure that the IP and the port is enabled at the MSSQL side, this can be verified through telnet.
  1. Change the datasources.xml to the following configuration (Please change the DB name and the hostname accordingly)

  1. Start the ESB.