You are here
- Home
- UK e-Infrastructure Security & Access Management WG
- Groups
- Hashing the ePPN using a Project-Owned Secret Salt to Safely Correlate User Account IDs within a Project
Group administrators:
Recent members:
Hashing the ePPN using a Project-Owned Secret Salt to Safely Correlate User Account IDs within a Project
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 (http://www.egi.eu) 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 (https://goc.egi.eu), the EGI’s central configuration management database (CMDB), a service that conforms to the R&S REFEDS SP Category (https://refeds.org/category/research-and-scholarship) 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.