Cross-Enterprise Security and Privacy Authorization (XSPA) using IBM Tivoli Security products

05 March 2010

Overview

The XSPA technical committee defines profiles of OASIS open standards to enable secure, cross-enterprise exchange of personal healthcare data. Built on XACML, SAML and WS-Trust the XSPA defined profiles enable healthcare staff to access a patient's data at their "primary care provider" in a manner that is secure, respects the patient's privacy wishes and enforces access control based on organisational constraints.

This year at RSA 2010 OASIS put together a demonstration booth with three separate interop events -- XSPA being one of them. IBM participated in this event, along with Oracle (using Sun technology) and Jericho Systems. As has been the case in previous XSPA demonstrations, Veteran's Affairs (VA) provided the client and server applications that call out to the various vendors' components.

This year the focus was on showing support for the new WS-Trust profile, with IBM and Sun/Oracle providing interchangeable WS-Trust endpoints for the client domain's STS. The infrastructure built for previous interop events for the XACML profile is still in place -- in this event IBM's XACML PDP was used for the client domain, and Jericho's XACML PDP was used for the service provider domain.

A number of use cases were demonstrated at the event:

Data masking: allowing a patient to mask parts of their medical history based on role or specific subject identifier;
Emergency override: if a user is unable to perform a cross-enterprise search under the course of a normal healthcare treatment, they can declare an emergency over-ride and access the data. This is still under the control of organisational policy -- the user must have the correct HL7 permissions to declare emergencies.
Genomic risk marker filtering -- The genome of some patients have been analysed and markers for being "at-risk" of certain health issues (such as schizophrenia) have been identified. The patient can choose to hide some of these at-risk markers to protect their privacy.

XSPA using IBM Tivoli Security solutions

IBM participated in this event using a solution built entirely on IBM products. Tivoli Security Policy Manager (TSPM) provided the runtime WS-Trust, SAML and XACML capabilities; Tivoli Access Manager (TAM) and Tivoli Directory Server (TDS) stored the user credentials and attributes for the use case at hand; and of course the whole solution is hosted on WebSphere Application Server (WAS).

TSPM contains a number of runtime security services. The ones used in this scenario are the identity service, which is the Security Token Service (STS) for the WS-Trust component, and the authorisation service, which is the XACML PDP.

The STS component is provided by the Tivoli Federated Identity Manager (TFIM) product. When a customer purchases TSPM a license to use this component of TFIM is included; however the configuration of the STS is still done via the TFIM console. The configuration instructions below include references to TFIM for this reason.

In order for the STS to issue SAML 2.0 tokens containing the XSPA-defined attributes, the LDAP server must be populated with the correct attributes.

Rather than defining a new LDAP schema, the following attributes were used to store the XSPA attributes:

urn:oasis:names:tic:xacml:1.0:subject:subject-id = cn
urn:oasis:names:tic:spa:1.0:subject:nip = uniqueIdentifier
urn:oasis:names:tic:spa:1.0:subject:organisation = organizationName
urn:oasis:names:tic:spa:1.0:subject:organization-id = organizationalUnit
urn:oasis:names:tic:xacml:2.0:subject:role = businessCategory
urn:oasis:names:tic:spa:1.0:subject:hl7:permission = mail

In a production environment we'd most likely make the effort to clearly define a new schema, however for the purpose of this demonstration overloading existing attributes sufficed.

The following attributes for the two users in the use case were used:

Doctor Bob:

uid = drbob
CN = Doctor,Bob
uniqueIdentifier = 100035
organizationName = Healthcare Domain A
organizationalUnit = 1.0.0.0.0.1
businessCategory = MD/Allopath
mail = PRD-003, PRD-005, PRD-006, PRD-009, PRD-010, PRD-012, PRD-017

Nurse Alice:

uid = nursealice
CN = Nurse,Alice
uniqueIdentifier = 100040
organizationName = Healthcare Domain A
organizationalUnit = 1.0.0.0.0.1
businessCategory = Registered Nurse (RN)
mail = PEA-001, PRD-006

A custom TFIM mapping module was written to extract all the attributes for a given user from the LDAP into the STSUU. This custom module searches for the Principal name (using a configured attribute, for example 'id') under a configured base DN and extracts all the attribute values. An XSLT mapping rule then maps the required subset of these LDAP attributes to XSPA attribute identifiers as per above.

The XSLT mapping rule also extracts any passed Claims in the XSPA namespace and places them into the returned SAML assertion. Claims are passed in the form:

<trust:Claims Dialect="urn:oasis:names:tc:xspa:1.0:claims">
    <xspa:ClaimType xmlns:xspa="urn:oasis:names:tc:xspa:1.0:claims" 
        Uri="urn:oasis:names:tc:xspa:1.0:subject:purposeofuse">
        <xspa:Value>Emergency Treatment</xspa:Value>
    </xspa:ClaimType>
</trust:Claims>

This feature of the profile allows the client application to insert dynamic values into the SAML assertion, which the service provider may or may not use when authorising the request. The example given above is specifying the "purpose of use" as "Emergency Treatment"; this might allow otherwise unauthorised users access to data in order to effectively treat the patient.

The trust chain is then configured as follows:

UsernameToken (validate, authenticate using TAM)
LDAP attribute extraction (map)
Default mapping module (map)
SAML 2.0 (issue, with signature)

The SAML assertion is signed with the same key that is used for the SSL endpoint (TFIM is configured with WebSEAL as the point-of-contact in the VM we used).

For this interop, RTSS was only used for the client side's internal authorisation. The default policy was used, imported straight into the RTSS Storage Service. No modification was required. However, the service provider's policy could be modelled in TSPM if desired.

Cross-Enterprise Security and Privacy Authorization (XSPA) using IBM Tivoli Security products

Overview

XSPA using IBM Tivoli Security solutions

Further Reading