Context-enhanced Authorization

Context information can make authorization management more flexible and more secure. Knowing when and where users are, and what they are up to helps in determining which access rules to apply. We recently did a project with Rabobank and IBM where we ask (and answer) questions such as: 

• What authorization related use-cases could benefit from context information?
• Which context-sources are relevant, mature enough, secure enough to be used today (or in the very near future)?
• How to deal with the (lack of) quality and authenticity of context?
• How does context information interact with authorization standards such as XACML and today's implementations of those standards? (See my previous posts for more technical details on the hands-on XACML work that we did in that project.)

The main lessons learned (the answers to the above questions) are:

• Typical use-cases can be found in the area of the mobile workforce ("nomadic working", etc.). As organizations introduce these new ways of working, traditional security policies that are only based on (authenticated) identity and static roles and entitlements are too strict and too coarse-grained. Context can make a difference here and allows finer-grained access so that, for example, medium level security tasks can be performed from home if the context allows this.
• A model for context-information can be constructed around different context-types, some traditional (location, time, ...), some more exotic (physiological, mental, social, ...). The above use-cases can already be adressed with the more traditional context-sources: location, time, proximity, device id, network id. These basic context-sources are readily available, and are under control of the organization.
• The easiest way to deal with authenticity and quality of context is to rely on trusted context-sources that are under control of the organization.
• Externalization of authorization, such as propagated by the Attribute Based Access Control (ABAC) paradigm (and facilitated by standards such as XACML) works well in practice when combined with context information. In a demonstrator (see video above) we showed that adding context to authorization policies managed by Tivoli Security Policy Manager (a XACML IBM product) comes down to adding a policy information point. Relying applications only need to understand XACML in order to become context-enabled.

Obviously, there are questions left for future research. How to deal with privacy issues is one of them. Complexity of policies and other scalability and performance issues form another. Want to read more? Go check out the project page or read the white paper.

XACML with Tivoli Security Policy Manager - Part 2

(This is part 2, for installation & configuration see part 1)


Using the TIP to specify services
TSPM needs to have a model of the resources that need protection (collections of resources are called services in the TSPM documentation). Rather than an unstructured bag of resources, a service in TSPM is specified as a tree of labeled nodes. Services can be created by hand using the web-based editor inside the TIP, or can be imported from other descriptions of applications.

An example of a supported description language for importing services is WSDL. It is relatively easy to start protecting web services in this way, just point TIP towards your WSDL file (it even supports multi-part WSDL including schemas). The resulting application model consists of the web methods of the web service (as resources). A PEP can then try to access these resources using the "invoke" action.


Using the TIP to specify policies

Policies can be created using the web-based structure editor inside the TIP. A policy can be attached nodes of a service, and the policy then holds for that node and all child-nodes of that node.

A policy built in the editor is series of rules connected using "else-if" connectives. Each rule consists of elementary propositions formed by comparing an attribute with a value of approprate type, connected using "or" and "and" connectives.

The web based nature of the structure editor forces it to be simple. Policies, perhaps created using some other editor, can also be imported as long as they are in XACML format. And, of course, polcies can be exported.

Writing a custom PEP
To test an installed and registered RTSS just use the authorization web service. Hand-craft a XACML request and send it using curl:

curl --basic -u "wasadmin:waspassword" --header "Content-type: text/xml;charset=UTF-8" --header "SOAPAction: http://xacml.ws.authz.rtss.tscc.ibm.com/rtss/AuthzService/XACML" --data "@request.xml" "http://tspm:9080/rtss/authz/services/AuthzService"

(Where a file request.xml holds the XACML request.) Note that the service uses basic authentication. The same web service is also exposed on an https port, allowing mutual TLS authentication (and possibly fallback basic authentication to authenticate the client). The request to send needs an environment section with a "ContextId" attribute, and issuer "http://security.tivoli.ibm.com/policy/distribution". The resource section of the request refers to identifiers of the nodes in the service (as specified via TIP as above).

Based on the WSDL of TSPM's authorization service you can also create a custom PEP client with JAX-WS.

An alternative to write a custom PEP in Java is to use the JACC+ API provided by IBM. This API implements (and extends) the Java Authorization Contract for Containers (JSR-115). The resulting Java code will be at a slightly higher level of abstraction, but this PEP needs an instance of RTSSClient (and thus needs to run inside WAS). You'll need the com.ibm.sec.authz.jaccplus_7.3.jar that came with RTSSClient and the javax.j2ee.jacc.jar (or stubs thereof) to compile your war.

Writing a custom PIP
A policy information point (PIP) provides values for attributes that are not part of the request sent by the PEP. TSPM has some environment attributes pre-configured (e.g. time of day, date), an external PIP allows to add other environment attributes. A custom PIP needs to implement the IExternalFinder interface and needs to be packaged as an OSGi module (which comes down to including a 3-line plugin.xml in the jar) and needs to be registered (which comes down to adding some lines to the security-services.xmi file on the WAS and running an osgiCfgInit.sh script).

Conclusion
This is not a product review! (so these are just some observations...)

• Configuring IBM Tivoli Security Policy Manager, and the stack of technologies it depends on, is, doable yet by no means trivial (for a beginner). It gets easier though, after a couple installation attempts.
• Implementing XACML support into external applications (essentially implementing a PEP interface), on the other hand, turned out to be simpler than expected.
• The same holds for implementing a PIP interface.
• The web-based editors in TIP for services and policies were ok for our purposes, yet may be a bit limited when dealing with complex services and policies

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.