Last updated: 
3 months 4 weeks ago
Group Manager
At the request of the Research Councils UK e-Infrastructure group, Janet established a working group from 2013-2016 to support those providing and using e-infrastructure services in achieving an approach that both protects services from threats and is usable by practitioners. More detail about the group can be found in the Terms of Reference The Working Group published the following papers: E-infrastructures: Access and Security (summary paper) (Jan 16) Federated Authentication for e-Infrastructures (Sep 14) Technical Security for e-Infrastructures (Nov 14) Authorisation/Group Management for e-Infrastructures (May 15) Policies for e-Infrastructures (Jan 16) Accounting and e-Infrastructures (Nov 16) Information about the Working Group's activities, as well as discussion documents, links and recommendations is linked under the following categories. Unless marked otherwise, all items are works-in-progress and we very much welcome your comments and contributions. Meetings   Presentations Case Studies Discussions Technologies References     Andrew Cormack (WG Chair)

Group administrators:

Hashing the ePPN using a Project-Owned Secret Salt to Safely Correlate User Account IDs within a Project

13 October 2015 at 3:22pm

In this article, issues related to correlating account IDs derived from attributes across collaborating systems are discussed. A technical solution is described that service providers (SPs) belonging to the same project can adopt for safely correlating attribute-derived data such as account IDs.

The European Grid Infrastructure ( is planning to introduce support for federated identity alongside x509 certificates as a means to authenticate users in a number of its core operational services. This includes GOCDB (, the EGI’s central configuration management database (CMDB), a service that conforms to the R&S REFEDS SP Category ( Authentication in GOCDB is currently via x509; the DN string from a user’s personal certificate is used to create an account ID that can be correlated across different services within the infrastructure. However, in lieu of a personal certificate, a user’s account ID will need to be derived from a persistent attribute supplied by a third-party identity provider (IdP). Pragmatically (see the R&S attribute subset), the most suitable available attribute is the eduPersonPrincipleName (ePPN); the eduPersonUniqueID (epUID) is not widely supported and the eduPersonTargetedID (ePTID) cannot, by design, be correlated across different SPs. Data-protection problems arise when a service needs to republish the ePPN or similar attribute-derived data (e.g. an account ID) that can be used to identify a person. In the GOCDB example, the ePPN could be used as the account ID for republishing to the EGI accounting and monitoring systems. This can contravene the federation’s rules of membership, especially if attributes are republished outside of the EU without the user’s positive informed consent. Secondly, there is also a scalability issue since the SP would also need to check with each/every third-party IdP that republishing of the ePPN would not contravene the IdP’s individual attribute release policy.

To address this, related SPs such as those belonging to the same project can create an opaque account ID that is derived from the ePPN by including a secret salt value, for example; ID = hash(‘secretSaltValue + ePPN’).  In doing this, the same hashed account ID can only be reproduced if:  a) an SP has (secure) access to the same secret salt value and, b) the SPs agree to use the same hashing algorithm.  Provided the salt value is not disclosed to any third parties, the resulting hash string is opaque and can be safely republished as an account ID across all the collaborating systems.