UK e-Infrastructure Security & Access Management WG

Last updated:

4 months 2 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:

Andrew Cormack

Recent members:

Allowing users to link Identities

Stephen Booth

18 March 2014 at 11:20am

One of the potential problems we have identified with AuthN tools like UK-Federation and Moonshot is that they (for good reasons) generate a different identifier for each service domain.

However where a Virtual organisation (VO) is consuming resources from many different service domains then the VO and the service provider need to establish a common identity for each user they have in common so that the VO can provide AuthZ rules for the service to implement. A common identity is also required for the service to provide accounting information back to the VO. Each service provider also has to somehow establish a mapping between this VO identity and the AuthN identity for their service domain.

One approach to estblish this link is to use a browser based protocol:

The user visits the VO website and clicks on a link to establish a identity link with a given service.
The VO server creates randomised request-url and redirects users browser to an "import identity" URL on a linking server in the service domain, The request-url is passed as a parameter.
This URL authenticates the user (establishing the service-domain-id) then performs a GET of the request-urll.
The VO and the service mutually authenticate using certificates and the VO-server returns the VO-identity

The service site now has a mapping between the VO identity and its local AuthN identity. This will work with any authentication mechanism that can be used with http, VO and service could even use different authentication mechanisms. The user takes part in the linking process and explicitly consents to the identity being linked.