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