XACML with Tivoli Security Policy Manager - Part 1

Over at Novay we've been working with XACML in the context (pun intended) of a couple of projects. One such project is Context-enhanced Authorization, which I will cover in a seperate post. In another project we are looking at interoperability with IBM's DataPower appliance in the presence of already existing XACML infrastructure, I also hope to cover that a seperate post at some point in the future.

For now, let me just get some of the (technical) XACML experiences off my chest, both to have a record of high level steps needed to deploy a real-world XACML implementation (such implementations can be pretty intimidating), and to be able to talk about the issues that we encountered with XACML in general and TSPM in particular. Caution: If you're not comfortable with the general XACML PAP, PDP, PEP, PIP terminology, this post may not be for you ;).

Installation
We used IBM's Tivoli Security Policy Manager (TSPM) in these projects. TSPM runs as an enterprise Java application inside IBM's WebSphere Application Server (WAS). It needs a database to store policies (either Derby or DB2; Derby was good enough for our purposes). And it needs a user registry for administrative user accounts (OpenLDAP works ok for our purposes).

I used the 64-bit Linux version of WAS 7.0 which installs fine on Fedora or SUSE inside VMWare and in the Amazon cloud. I used the graphical installer, which means some extra packages need to be installed on the target machine (otherwise the OS can stay pretty minimal). I updated WAS to the latest version (7.0.0.21 at the moment of writing).

TSPM itself is installed using a graphical installer as well. The installer is a 32-bit (Eclipse) application, so compatibility packages are needed to install on 64-bit Linux.

To turn TSPM into a PAP a so-called Tivoli Integrated Portal (TIP) needs to be installed. This is another enterprise Java application which runs inside a seperate WAS instance. Again a 32-bit Eclipse installer is used here. TIP exposes a web interface which allows to create services and policies.

To turn TSPM into a PDP the Runtime Security Services (RTSS) server needs to be installed. This is another enterprise Java application which, typically, runs inside the same WAS instance that TSPM was installed on. The same 32-bit Eclipse installer is used. RTSS exposes a SOAP web service that PEPs can send authorization requests to.

There's also a higher level Java API (the JACC+ API) for implementing PEPs (see below), this requires the PEP to run on a seperate WAS and an enterprise Java application called RTSSClient needs to be installed. A JACC+ PEP can also run locally (on the WAS that runs TSPM), the RTSSClient then replaces the RTSS (i.e. you don't install RTSS at all).

Configuration
Some scripts need to be run to configure TSPM and to register RTSS (and/or RTSSClient). Especially the tspmConfigTool took some retries to get right. These scripts take configuration files (or "response" files) as input, making it easier to deploy the same configuration elsewhere... once you get it right.

A local policy distribution target (PDT) needs to be registered so that policies can be distributed from the PAP to the PDP. If TSPM acts both as PAP and as a single PDP (servicing multiple PEPs, the simplest XACML use case) the whole notion of PDT seems odd (changes to the policy are distributed... to itself, but only if you tell it to do so). The notion of PDT is not part of the XACML spec (despite being a 3-letter abbreviation starting with a 'P'). In the use case where we hooked up the DataPower to TSPM the DataPower itself can also act as a PDP and needs to be registered using the tspmRegisterPDT.sh script (the instructions are not part of the configuration guide, and you may need to use the gsk7cmd command which was not installed by default).

Obviously, some things went wrong during installation and configuration. Some of these issues blocked the installation or configuration process, some issues only became clear after working with TSPM for a while. Here's a small selection:

• When installing on an instance in the Amazon cloud, the IP address of the instance can change (not the external IP, which was fixed using an elastic IP address, but the internal one). TSPM requires a fully-qualified host name at several points during installation. The solution is to set up an alias for the machine in /etc/hosts and/or to explicitly fix the IP address in WAS's configuration.
• There's a known WS-Security issue with timestamps, which requires fixing some policy settings in WAS before policies can be distributed.
• The tspmRegisterPDT.sh script failed with some internal exception. This turned out, after a very long search, to be a corrupted log file causing the "SIB MessageBroker" not to be started. Causing some WS-Notification call to fail during registration of the PDT.
• RTSS appeared to cache authorization decisions for 2 minutes (which was not appropriate for the kind of policies used in the Context-enhanced Authorization project). A related question was answered on stackoverflow.com.

Resources

1. The TSPM installation, configuration, and administration guides over at the IBM information center.
2. IT Security Policy Management Usage Patterns Using IBM Tivoli Security Policy Manager 2011 Redbook by Buecker et al. was useful, especially Chapter 8 (on custom PEPs and PIPs).
3. The TSPM wiki on DeveloperWorks.