SourceForge.net Logo

Example SOA Landscape for Task-Role Based Access Control (T-RBAC)

This example application demonstrates the appliance of Task-Role Based Access Control (T-RBAC) [1] inside a Service Oriented Architecture using the Enterprise Service Bus [Apache ServiceMix], InstantSVC and the [Apache ODE] BPEL Engine.

Task-Role Based Access Control

Task-Role Based Access Control is a dynamic model for process oriented business environments and is a convenient way to provide access control in conjunction with workflow/business process systems. Access rights are granted and revoked while a business process is executed and in time with need for a specific access right. Thus, it is possible to reduce overhead for access right management. Additionally, sensitive resources are not accessible all over the time, but only in the context of a special workflow/activity for which it is necessary.

This prototype utilizes the [SAML 2.0] and [XACML] standards to show the potential behind them and enable users to make use of there current security/management solutions combined with this access control model.

Application Domain and Architecture of the Prototype

The prototype operates in the often as example used tourism domain. The need to interact with several partners is obvious, here. The following figure shows all components of this prototype scenario. It is build with a service oriented architecture which could be used by common travel agencies. The main component for the travel agency is the Travel Management component. It implements a simple business process to gather information from Web Services of external partners.

Architecture of the Prototype (FMC Diagram)
Fig. 1.   Architecture of the Prototype Implementation using Apache ServiceMix as ESB, Apache ODE as BPEL Engine and XACML as Policy Definition Language – FMC Block Diagram

These partners are accessible from within the travel agency’s infrastructure using so called Service Adapters. These service adapters delegate the requests to the real external services and are the basis for controlling access to these external services. The used infrastructure should enforce that only authorized calls through these service adapters are allowed to access external services. The Policy Administration Point (PAP) and Policy Decision Point (PDP) are building upon the notion of XACML. The PAP is a simple Web Service storing information about all currently granted rights and providing them as a XACML document. The PDP is directly used by the ESB. This is implemented with a special broker which in fact represents the Policy Enforcement Points (PEP) shown in the above figure. The prototype itself can be tested via the agency front-end or direct SOAP calls. The identity provider is not necessary to test the prototype with direct SOAP calls, but is used for logins with the agency front-end.

Setup Testing Environment

The scenario has been tested with the following software versions. Due to a bug in the xml facility of ServiceMix, we had to use the 3.2.0 snapshots. At the moment, the latest version was build on 2007-09-20, but hopefully more recent versions are compatible, too.

Apache ServiceMix 3.2.0 Snapshot Build

http://people.apache.org/repo/m2-snapshot-repository/org/apache/servicemix/apache-servicemix/3.2-incubating-SNAPSHOT/ --> apache-servicemix-3.2-incubating-20070920.011633-97.zip

Apache Tomcat 6.0.14

http://tomcat.apache.org/download-60.cgi --> apache-tomcat-6.0.14.tar.gz

Apache Axis2 1.3 WAR

http://ws.apache.org/axis2/download/1_3/download.cgi --> axis2-1.3-war.zip

Apache ODE 1.1

http://www.apache.org/dyn/closer.cgi/ode/apache-ode-jbi-1.1.zip

The setup of all necessary software is as easy as coping files from one folder to another.

  1. Extract the ServiceMix archive to a folder called “servicemix”
  2. Extract the ODE archive to a folder and copy the included ode-jbi-1.1.zip to the servicemix/hotdeploy/ folder
  3. Extract the Tomcat archive to a folder called “tomcat”
  4. Extract the Axis2 WAR package to folder and copy the included WAR file (axis2.war) to tomcat/webapps/

Now the infrastructure should be ready to deploy our SOA landscape to it. Please keep in mind, all Web Services are bound to the default configuration. If you need to change any settings of Tomcat or ServiceMix, be aware of the possible need to adjust network ports/URIs in the Web Services as well. This could led to a lot of hassle. We therefore suggest to stick to the default network settings.

Compiling the Projects

The complete project uses [Maven2] as building infrastructure. If you have not used Maven before, this step may be a bit time consuming. Maven provides a very nice way of dependency management and all most all large Java Open Source libraries are available via maven repositories and are downloaded automatically. So you have not to care about where to put all your third party libraries, any longer. While using it the first time, all dependencies have to be downloaded, which could last up to one hour. Therefore, we provide a binary package of all components, too.

To compile the components yourself, download the source package [trbac-src.tar.gz] or grab the source from the [SVN]. Now you can go to the main directory of the source package and issue a “mvn install” to start the compilation and packaging process. As already mentioned, this could last up to one hour for the worst case.

Deploy the Service Landscape

Let’s start with our external services.

  1. If not already done, start up Tomcat to initialize the Axis2 web application, go to the tomcat folder and issue “bin/startup.sh”
  2. Deploy railroad-0.1-test.aar to tomcat/webapps/axis2/WEB-INF/services/. railroad-0.1-test.aar is included in the binary package or the folder railroad/target if you compiled everything on your own.
  3. Check tomcat is running: now you should be able to retrieve a list of available Web Services including “RailRoadService” from http://localhost:8080/axis2/services/listServices
  4. The second external services uses ServiceMix. Copy airline-sa-0.1-test.jar to servicemix/hotdeploy/. It is available in the binary package or at the folder airline/airline-sa/target/.
  5. Startup ServiceMix from its root folder with “bin/servicemix”. For the first time, this could a minute or so.
  6. Check ServiceMix is running proper: at http://localhost:8192/ the Airline Service should be listed with a line like http://hostname:8192/AirlineInfoService-HttpBasic/

Now the external services should be up and running and could be tested with something like [soapUI]. Additional hints are given in the README files of the services in their source folders.

The in next steps we deploy the authorization service, adapters for external services and the travel agency business process.

  1. Copy authorization-sa-0.1-test.jar to servicemix/hotdeploy/ (in binary package or at authorization/sa/target/ folder)
  2. Copy external-service-adapters-sa-0.1-test.jar to servicemix/hotdeploy/ (in binary package or at external-service-adapters/external-service-adapters-sa/target/ folder)
  3. Copy travel-agency-sa-0.1-test.jar to servicemix/hotdeploy/ (in binary package or at travel-agency/sa/target/ folder)

At this point all business services should be up and running. This can be tested with the soap-test.php in the source folder. 

php soap-test.php process.soap http://hostname:8192/Process01/

This command issues a SOAP request to your ServiceMix instance and the business process queries the external services for information. While processing the request, ServiceMix should log some grant and revoke actions to its console. The result, which is returned by the command line, should look similar to the following. 

<?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><Process01Response xmlns:sns="urn:/Process01.wsdl" xmlns="urn:/Process01.wsdl">
  <sns:quotes xmlns:sns="urn:/Process01.wsdl">
    <sns:quote xmlns:sns="urn:/Process01.wsdl">
      <sns:vehicle xmlns:sns="urn:/Process01.wsdl">plane</sns:vehicle>
      <sns:price xmlns:sns="urn:/Process01.wsdl">0.0</sns:price>
      <sns:departure xmlns:sns="urn:/Process01.wsdl"></sns:departure>
      <sns:arrival xmlns:sns="urn:/Process01.wsdl" />
      <sns:duration xmlns:sns="urn:/Process01.wsdl">0.0</sns:duration>
    </sns:quote>
    <sns:quote xmlns:sns="urn:/Process01.wsdl">
      <sns:vehicle xmlns:sns="urn:/Process01.wsdl">train</sns:vehicle>
      <sns:price xmlns:sns="urn:/Process01.wsdl">20.99</sns:price>
      <sns:departure xmlns:sns="urn:/Process01.wsdl">2007-12-12T11:12:12.000Z</sns:departure>
      <sns:arrival xmlns:sns="urn:/Process01.wsdl">2007-12-12T16:12:12.000Z</sns:arrival>
      <sns:duration xmlns:sns="urn:/Process01.wsdl" />
    </sns:quote>
  </sns:quotes>
</Process01Response></soapenv:Body></soapenv:Envelope>

In the last step we need to deploy the Policy Enforcement Point (PEP) to the Enterprise Service Bus. At this point ServiceMix has to be shutdown, because the PEP is an alternative Broker implementation for the bus.

  1. Shut down ServiceMix with a CTRL+C in the console window where it has been started.
  2. Copy PepBroker?-0.2.0.jar and the authorization-jsr181-su-0.1-test.jar to the servicemix/lib/ folder. Both can be found in the binary package or at there target folders (pep-broker/target/ and authorization/jsr181-su/target/).
  3. Copy sunxacml-1.2.jar from the binary package or http://ping.chip.org/maven/com/sun/xacml/sunxacml/1.2/sunxacml-1.2.jar to servicemix/lib/
  4. Substitute the <sm:securedBroker/> part in your servicemix.xml (residing in servicemix/conf/)

with this bean: 

<bean class="net.instantsvc.servicemix.broker.PepBroker">
  <property name="policyDecisionPoint">
    <bean class="net.instantsvc.servicemix.pdp.PolicyDecisionPoint">
      <property name="authorizationServer" value="service:http://instantsvc.net/servicemix/authorization/AuthorizationService" />
    </bean>
  </property>
</bean>
  1. StartServiceMix with “bin/servicemix” at its root folder. Startup is finished if the LogTask has completed. It is most times the last line at console output on startup.

Now the complete prototype should run and you can try to issue a SOAP request again with: 

php soap-test.php process.soap http://hostname:8192/Process01/

The result should not have changed to the previous one, but now you should see much more output on the ServiceMix console. Here are all message activities logged, which are going though the new broker. The broker logs all results of access control decisions, too. Now this setup tutorial is finished. If your interested in the used technologies have a look at the components in detail.

Components

The following is a short list of the included projects/components of our SOA Landscape.

pep-broker

Policy Enforcement Point with integrated Policy Decision Point

authorization

Authorization Service (XACML Policy Administration Point)

travel-agency

BPEL JBI component of the Travel Agency

external-service-adapters

Adapters for the External Service Providers Airline and RailRoad

airline

Airline Service Provider

railroad

RailRoad Service Provider

front-end

PHP-based Web Front-End with Single Sing-On via SAML

servicemix-realtime-monitoring

Real-time Monitoring for Apache ServiceMix

jbi-hello-world and bpel-hello-world

Hello World projects as a template for own deployments

Please refer to the README files of the subprojects for installation instructions.

It is probably also worthwhile to have look at the documents and architecture models included in the docs folder of the package.

[1] Oh, S., Park, S.: Task-Role Based Access Control (T-RBAC): An Improved Access Control Model for Enterprise Environment. In: DEXA ’00: Proceedings of the 11th International Conference on Database and Expert Systems Applications, London, UK, Springer-Verlag (2000) 264–273 http://www.springerlink.com/content/3f9d8wfagnple48r/fulltext.pdf