Thursday, 14 June 2007

NDG Security, trust and role mapping

The NERC Data Grid security system uses a model of bilateral agreements between organisations to establish trust and so share access to data. This was agreed from early on in the project after hammer out the differing requirements of the participating organisations.

Trust agreements are made by means of role mapping. This assumes that each organisation has a pre-existing system of role based access control to data or at least that, they are prepared to create one. This was in fact a major driver for this solution: organisations already had established roles for data access. They didn't wish make major changes to their infrastructures to support new ones.

Another factor was that access to some datasets is bound by legal agreement with some third party. Organisations did not want to have to re-negotiate these agreements in order to support new roles for cross-organisational access.

To establish a role mapping agreement, an organisation agrees a number of its roles that it wishes to map to roles which the trusted organisation supports. For example, Organisation A has a dataset whose access is restricted by role datasetN. It wishes to make this data available to post graduate researchers at Organisation B. Organisation B has a role allocated to these people called postgrad. Organisation makes a mapping from role postgrad -> datasetN. Currently the system use an XML based role mapping configuration. Each organisation uses this file to establish role mappings. For the example given, Organisation A's map configuration file might look like this:

<?xml version="1.0"; encoding="UTF-8"?>
    <trusted name="Organisation B">
        <role local="datasetN" remote="postgrad"/>
        <role ... />

Mediating access

Roles are allocated to users in Attribute Certificates, XML documents with time limited validity, digitally signed by Attribute Authority that issued them. The Attribute Authority must authenticate the request against a valid user ID in order to issue a certificate. In this case, the user must be known to the Attribute Authority. Access control decisions are made by Gatekeepers. An Attribute Certificate is presented to a gatekeeper along with user ID credentials. These are checked and if a role in the certificate matches the role controlling access to the resource, access is granted.

Attribute Authorities are also responsible for role mapping. In the earlier example, the user of Organisation B is not known to A's Attribute Authority. Therefore a request for an Attribute Certificate would be rejected. However, in this case user B can present their Organisation B Attribute Certificate. Attribute Authority A recognises this as issued from a trusted organisation and applies the mapping to the roles contained. The mapped roles are issued in a new mapped Attribute Certificate issued by a Attribute Authority B. In the example, the original certificate might have contained the role postgrad and the mapped certificate would contain datasetN.

The mapped certificate can now be presented to the appropriate gatekeeper at A in order to gain access to data.

The current system restricts role mapping to one level: it is not possible to map roles from a mapped certificate.


The example here is taken from the DEWS project where NDG Security is employed. The steps are broken down into two diagrams, login and access at a remote site. The Portal organisation is trusted by the Health Data Server.


I want to examine the benefits and drawbacks of role mapping as a mechanism to establish trust...


  • Decentralised: trust on an organisation to organisation basis
  • Selective: organisation chooses who it wants to trust on a case by case basis
  • Scalable: organisations can easily join the system without submitting their entire user base to a central repository
  • Flexible: new trust relationships can easily be made or existing ones broken
  • Control over the Level of trust: A can set the mapping so that gold user role in B may only map to bronze in A
  • Supports organisations' existing security infrastructures with minimal change or disruption. Organisations within NDG had pre-existing authorisation systems and roles. Using role mapping their existing native roles can be maintained without change to user entitlements or associations of roles to datasets.


  • Role mapping adds a layer of complexity in the transaction to gain access to a resource. The client software acting on behalf of the user must obtain an original certificate and then present this for role mapping to get a mapped certificate. David Chadwick has made the case that role mapping is better applied at the gatekeeper giving the analogy of airline loyalty cards. Going to airline A's lounge you don't swap your B airline card for an A one to get in. You present your B card knowing that A will accept it. Thus, a mapped Attribute Certificate would never exist. Its roles would be mapped at the point where the access control decision is made. In favour of mapped certificates it could be argued that it enables more primitive gatekeepers. They have no need of role mapping information since it is held at a central point for the organisation ie. its Attribute Authority
  • Role mappings between a large number of organisations could become difficult to maintain
  • Bilateral agreements must be kept up to date and maintained. If one party changes the mean of a role or deletes a role used in mapping then the mapping itself is broken and this potentially without the knowledge of the other party.
  • Role mapping as an approach could be rejected entirely in favour of centralised service set up jointly between two or more organisations to issue roles.

    • Common roles are agreed and users from participating organisations are registered with the service.
    • Organisations' site administrators are delegated the responsiblity to allocate roles appropriately on a case by case basis.
    • The process of authorisation is simplified since no role mapping is involved. A token issued from the central service is recognised by individual organisation's gatekeepers.
    • Users would need to register with the new service and agree to the terms of the virtual organisation. Legally, they need to give their consent for their ID information to be held by the service.

Wednesday, 13 June 2007

Proxy Certificates and WS-Security don't Mix!

With the current NERC DataGrid system proxy certificates provide a means to authenticate users with Attribute Authorities but problems arise with integrating them with SOAP services using WS-Security.

A SOAP interface was used for NDG Alpha but without WS-Security. For Beta delivery we want to have a fully WS-Security compliant interface to facilitate interoperability with Java toolkits and other languages as required. This was an aim for the related DEWS project.

WS-Security with DEWS

For DEWS it was partially successful: a problem arises in how to communicate the chain of trust from proxy certificate back to the CA certificate: CA Certificate <- user certificate <- proxy certificate. (Ref.

In the WS-Security schema, the BinarySecurityToken element can be set with the X.509 certificate for the recipient to use to validate the signature but in the case of a proxy certificate you would need to pass both the proxy and the user certificate. For DEWS, proxy certificates were dispensed with because of this difficulty or also more importantly, the fact that the Java WebSphere and WSS4J toolkits that the Python code interfaced with use fixed certificate settings set at start up. Proxy certificates are generated at runtime so this is a non-starter.
Instead a server certificate was used for signing messages to an Attribute Authority passing the user ID as a separate element in the message.

Passing a certificate chain with WS-Security

The solution would seem to be to use the X509PKIPathv1 ValueType for the token enabling a chain of certificates to be included. ( This has now been prototyped in Python. There is still a concern though that although the standard supports this, toolkits probably don't. WebSphere includes this option in the WS-Security settings but it's not clear how you create the chain from the certificates in the key store. I've not explored this further. WSS4J I'm told supports the use of X509PKIPathv1 but it's buried deep inside the code and so hard to configure without modifying. This could be pursued further and perhaps as the standard becomes more established support will improving in the various toolkits. I've not as yet looked beyond WebSphere and WSS4J. Ultimately the question arises as to how important are proxy certificates and WS-Security to NDG Security architecture?