PDP PEP Communication – how WSO2 Identity Server defines

XACML specification clearly defines the externalized architecture, by separating the PDP PEP components. PDP decides authorization decisions where PEP can talk to PDP and get those decisions. Therefore it is better to have a standard way of doing PEP and PDP communication. Because in a deployment any application (PEP) could communicate with any PDP  irrespective of their actual implementation.  There must not be a tight coupling between PEP and PDP. But unfortunately there is no powerful way of defining PEP and PDP communication in a standard manner. There is a standard called, WS-XACML which is not much popular and it is rarely used due to some disadvantages.  Therefore i think it is the time to standardize the PEP PDP communication.

However WSO2 Identity Server exposes its PDP functions as loosely coupling manner, by use of web services. Therefore any application (PEP) can talk with WSO2 Identity Server PDP using web service client. In this blog post i am hoping go through some details on this web service interface.  In WSO2 Identity Server, it is called as “EntitlementService”

[Update] Now there is XACML REST profile that defines a endpoint for XACML policy evaluation. It also defines how XACML request must be received and response back with security considerations. There are JSON profile as well that defines how XACML request/response can send as JSON massages. Identity Server is going to support these. But it is not in release 4.7.0. It would be with next release.

Following are the some import notes about “EntitlementService”

Note 1 : How to see the WSDL of EntitlementService.

1. EntitlementService is admin service according the WSO2 Carbon platform. Therefore WSDL of admin service can not be seen by default.
2. Open carbon.xml file which can be found at <IS_HOME>/repository/conf directory
3. Locate following XML element and set it to “false”

&lt;!-- If this parameter is set, the ?wsdl on an admin service will not give the admin service wsdl. --&gt;
 &lt;HideAdminServiceWSDLs&gt;true&lt;/HideAdminServiceWSDLs&gt;

4. Then restart WSO2 Identity Server running wso2server script which can be found at <IS_HOME>/bin directory.
5. Point to browser https://localhost:9443/services/EntitlementService?wsdl If you have started server in default configurations.

Note2 : Understanding operations in EntitlementService

There are two operations in EntitlementService

1. String getDecision(String xacmlRequest)
Where you need to input a XML String object of XACML request and XACML response also is received as XML String

2. String getDecisionByAttributes(String subject, String resource, String action, String[] environment)
Where you can pass one attribute value of a subject, a resource and an action as input value. XACML request created at the PDP level with default values (default data type as String and default attribute ids) You can use this method most of the cases. As authorization is normally deal with user, resource and action. But you can not use this with complex use cases.

Entitlement mediator in WSO2ESB is used getDecisionByAttributes method for querying the XACML decision.

Note 3 : Security of EntitlementService

As i mentioned earlier EntitlementService has been defined as an admin service of WSO2 Carbon platform. Where you need to authenticate to WSO2 Identity Server to access it. Therefore any application (any PEP) can not call EntitlementService. There must be a trust between EntitlementService and the PEP. PEP must need to have valid credential to access the EntitlementService. Also all communication is done over HTTPS Where confidentiality is grantee. (But i personally think there must be some integrity and non-repudiation if PEP PDP communication is done in public network, which is normally not :) )

Note 4 : Performance  of  EntitlementService

WSO2 Identity Server team has done lot of load testing to find bottlenecks in XACML authorization system. One of the key point that reduce the performance of XACML based deployment; is  PEP PDP communication.  As a solution to that  WSO2 Identity Server has introduce thrift protocol ( which is binary rpc protocol) for  PEP PDP communication with the WSO2 Identity Server v 3.2.3 release.  According to the load testing,  thrift is 16 time faster than normally SOAP over HTTP communication.

In my next blog post, lets write a simple PEP for EntitlementService.

7 Comments

  1. Rémon Sinnema

    “unfortunately there is no powerful way of defining PEP and PDP communication in a standard manner.”

    We’re working on a REST profile that will provide such a PDP PEP communication standard.

    Reply
    1. xacmlinfo

      Yes.. REST profile can be found here [1]. This would be available with next Identity Server

      [1] http://docs.oasis-open.org/xacml/xacml-rest/v1.0/xacml-rest-v1.0.pdf

      Reply
  2. Yasuo

    Your consideration on using HTTPS and some non-repudiation signature inspires me a similar topic in different field.
    In E-Authentication context, NIST SP 800-63-1 requires HTTPS for Level 2, and requires non-repudiation signature on SAML assertion at Level 3.

    These functionality may be needed to keep the trust for each levels of authentication assurance.

    Reply
  3. djob82

    We’re also working on a JSON request-response scheme which we will demo at RSA 2013.
    Finally, there is one profile that has been implemented by several vendors e.g. Oracle and Axiomatics that defines interoperable PEP-PDP interactions and that’s the SAML-XACML profile (http://docs.oasis-open.org/xacml/3.0/xacml-profile-saml2.0-v2-spec-cs-01-en.pdf)

    Reply
  4. raju

    can andbody tell me how to add xacml policy using wso2 as to camel rest endpoint.

    mail me at raju.m@bizruntime.com

    Reply
  5. PK

    “According to the load testing, thrift is 16 time faster than normally SOAP over HTTP communication.”

    Now I am searching for a thrift PEPclient to do this task. Which client did you use for the testing? And is there any disadvantage of using thrift?

    However, pretty nice blog :)

    Reply
    1. Asela

      Thanks… You can find some client that has been used to compare thrift and http performance.. Please find it from here. https://svn.wso2.org/repos/wso2/people/asela/loadtests/loadtestrunner/ Also you can write thrift plugin to Jmeter..

      Reply

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>