GOCDB/notifications

Main

EGI.eu operations services

Support

Documentation

Tools

Activities

Performance

Technology

Catch-all Services

Resource Allocation

Security

Tools menu:	• Main page	• Instructions for developers	• AAI Proxy	• Accounting Portal	• Accounting Repository	• AppDB	• ARGO	• GGUS	• GOCDB
• Message brokers	• Licenses	• OTAGs	• Operations Portal	• Perun	• EGI Collaboration tools	• LToS	• EGI Workload Manager

Use of eppn in EGI

Data Privacy and Code of Conduct Policy Document Under Construction: GOCDB/data_privacy

Hi Ops/all,

Apologies for the lengthy text:

With the plans to include federated identity, services like GocDB (which falls under the R&S REFEDS SP Category) will need to use an attribute supplied by an IdP to create/identify a user account, usually ‘eduPersonPrincipleName’ (eppn) (or less likely ‘eduPersonTargetedID’, eptid, see discussion below). These attributes will be used instead of an x509 DN and will require changes to the output of the PI, changing CERTDN element to PRINCIPAL element in queries like get_user and get_site_contacts - GocDB needs to republish these attributes in its PI for use by the rest of the infrastructure (e.g. queried by Ops portal, used in accounting and so on).

Now, according to the rules of the UK Access Fed (similar rules apply in other feds), “The Service Provider must not disclose to third parties any Attributes other than to any data processor of the service provider or where the relevant end user has give its prior informed consent to such disclosure. see [note2]” . (Where [note2] states: “The basic Rule is that attributes may only be used by the service requested by the user and only for the specified purposes. Service Providers that wish to use attributes in other ways (for example to provide direct user support) can arrange this either by obtaining positive informed consent from each individual End User, or by contract with Identity Providers who are then responsible for informing their End User.”)

Therefore, to use Attributes like the eppn in EGI we need to obtain ‘positive informed consent’ from the user that we can publish and make visible their data/eppn to authenticated users and client-services of GOCDB, including those trusted by UK Access Management Federation, EGI-SSO or IGTF (I think we must explicitly state the different authentication/trust realms, e.g. any person/host with a valid IGTF cert can query the GocDB API for this info).

• Q. Any experts out there know if the sample notification/approval-dialog shown in the screen grab below provides adequate positive consent?
  • Update, looking at: [on the definition of consent]
• Q. Assuming user clicks OK, do you know if there are any issues for EGI and for the hosting institution (STFC) in re-publishing the eppn in the PI? (it then becomes readable to any other service/user who has a valid IGTF cert)
  • Update 20/08/2015: Re-publishing the eppn looks like a no-go: The SP needs to first take account of each/every IdP's policy on whether the eppn can be reused. This is does not scale. However, hashing the ePPN or using the ePUID may be ok (see below).

ePTID

Instead of using an eppn, GocDB could use the ‘eduPersonTargetedID’ (eptid) and re-publish that in the PI – the eptid is less of a security concern because its anonymous/opaque. However, since the eptid will be different for the same user across different SAML Service Providers, this provides little use when there is requirement to identify a particular accountID across different SPs and organisations (this is the EGI requirement). Note, if EGI had a single centralised/proxy IdP, it could be used to re-issue the same eptid consistently to all the underlying EGI services/systems. I think this would be far preferable compared to services individually registering with federations and receiving different eptids per service.

• Update 20/08/2015, using the eptid is not suitable as it does not match the EGI requirement

Hash the eppn

Another possibility would be to hash the eppn (not eptid) to create a persistent and opaque account ID string for republishing within EGI. If we did this, we would need to agree the same hashing alg and optionally securely share a salt string to selected SPs within the EGI so that they can derive the same hash string to correlate the account, i.e. hash('secretSalt+eppn).

• Note, the resulting hash would be truly opaque and other SPs in a federation would not be able to derive/correlate the same hash unless they had access to the same secret salt value (which we would only securely share with selected other/known EGI-project SPs who need to derive the same string).

• Q. Is something like this the longer term plan? If possible, I think it would be best to decide how we do this now to save complexities down the road.

I’d be grateful for any thoughts/guidance on these matters.

Cheers,

David