1. PaN-data WP4 - Users Gordon Brown STFC-e-Science Alun Ashton DLS Bill Pulford DLS

2. WP4 Development of standards for common user information exchange Objectives To foster interoperability of user information across the participating facilities and the wider research community. To develop standards enabling a shared Virtual Organisation Management and common processes across the participating facilities. Methodology The ultimate objective is the implementation of a system to allow scientific users to access data files across the physically distributed repositories. A typical use case would be a user having performed experiments at several facilities who needs to perform the same data analysis on all data sets. This process involves the use of remote computing resources and software packages, which implies a system whereby a logged user at a local site can be automatically authenticated and authorised (AAA) to use remote facilities. This additional level of AAA should be as transparent as possible to the user. Data protection laws in each country enormously complicate the sharing of user information between organisations. Consequently the AAA must function with the transfer of the very minimum of information, possibly only the user’s name and/or email and the trust information. A corollary is that AAA is not involved in implementing user databases at each site but rather in providing a mechanism of interfacing with existing applications to make available the trust information in a consistent and coordinated manner across the facilities. Task 4.1: Review existing authentication solutions with special emphasis of the IRUVX / ESRFUP prototype solution. Propose prototype authentication system in view of the needs of the full neutron and photon community (M1-M8). Task 4.2: Workshop with facility authentication experts; plan the adoption strategy for the full- community authentication system (M9). Task 4.3: Revise the proposal in the light of the workshop findings, and determine the next steps (non web-based applications, GRID-related issues). (M8-M12). (Note: the final workshop to disseminate the results of the work package takes place in WP3) Deliverables D4.1 : Proposal for authentication system enabling shared Virtual Organisation Management (M8) D4.2 : User information workshop report (M10) D4.3 : Revised specification of common authentication system (M12)

3. Objectives How to share user information Centralisation v Federation Best way for user access/authentication DLS Objectives: – Remote access including role based access control – Seamless access to remote large computing resources

4. Overview of Current Access Internal central file system with remote log in. Web access for MX data in place. Internal central file system with remote log in. Also Internet Data Access via web service VMS login or PC browse of directory structure. Web access by known experiment number only Internal file system with remote log in. Internet Data Access via web service Internal central file system with remote log in + dcap and pnfs access on FLASH. Others?

5. Overlaps with Other Projects IRUVX-PP WP2 – User Needs and Policies ESRFUP WP7 – User Single Entry Point to ESRF and ILL

6. VOMS I Virtual Organisation Membership Service. Provides tools to help grids manage the authorization of their users. Helps Virtual Organisations (VOs) by delegating the approval of users to the VO itself, consequently removing the onus upon the end user to register with each resource s/he might use as part of the VO. VOMS is a project resulting from a collaborations between EDG and DataTAG. VOMS service allows VOs to be created and each VO membership is managed by a named VO manager.

7. VOMS II Simple account database with fixed formats for the information exchange and features – single login – expiration time – backward compatibility – multiple virtual organizations. Database is manipulated by authorization data that defines specific capabilities and roles for users. Administrative tools can be used by administrators to assign roles and capability information in the database. Command-line tool allows users to generate a local proxy credential based on the contents of the VOMS database. – This credential includes the basic authentication information that standard Grid proxy credentials contain, but it also includes role and capability information from the VOMS server. VOMS-aware applications can use the VOMS data to make authentication decisions regarding user requests.

8. Diamond Single Sign On The aim of this project was to provide a mechanism for uniquely identifying users of UK large scientific facilities irrespective of their method of access. All users of the major facilities will need only one username/password combination to access any of the facilities. These credentials or an automatically generated certificate or token will allow access to any computing technology given the correct authorization. The authorization will be performed locally by the facility involved based on the single unique identifier derived from 1-3. Normally we use either CAS (Originally Yale – now JASIG) or myProxy to perform user authenication - http://www.ja-sig.org/products/cas/index.html A Java Web service filter uses authenticated user name with Actve Directory and/or local ldap to determine the user's roles. Partners: STFC, e-Science, SRS, ISIS, Diamond Users can now reset their own passwords using a “Bank Type” web application.

9. OpenID User can adopt a digital identifier from one or more of authentication providers. Providers are numerous and are chosen by the users themselves. Identifiers in form of userid.openidprovider.net (i.e. a sort of URI) The authentication providers (AP) maintain the information such as name and email necessary for the operation of the scheme. In the case where an OpenID user tries to login to a site other than their AP, the authentication is proxied automatically to their AP which replies either "yes" or "no" - his can be the only information transferred.

10. OpenID The site that the user is trying to access may require further authentication information but none of these needs to be transmitted between sites. This idea may be particularly relevant for the members of PaN-data since many of our users are already inscribed simultaneously in a number of the facilities. The OpenID is the single digital identifier relating these common records and would thus enable one of the fundamental requirements to authorize access to physically distributed files and resources. Acknowledged that this represented to 70% or more use cases for AAA in PaN-data. schemes - e.g user.openid.diamond.eu

11. OpenID - Advantages 1.Responsibility for the user's information is controlled by the user themselves 2.Very widely available and used in the world. http://openiddirectory.com 3.Very large selection of open source software in most technologies for both servers and clients 4.An OpenID server site can be set up quite quickly without the continuous support from specialized people. 5.X509 certificates can often be auto-generated to enable more advanced interactions such as setting up data processing pipelines. 6.Usefully for Diamond, our Central Authentication System (CAS) already has support for OpenID. 7.No immediate need for a central repository of user information. This may eventually be very useful but the political and practical difficulties could cause critical delays to other components. a.It should be possible to transfer a user's information between authenticating member sites using first their explicit authorization and by then using their OpenID as the mechanism controlling the actual transfer. b.Assuming that the user had authorized the maintenance of their basic name and address information across sites, the use of the single digital identity would enable an automatic process of transfer. c.It would be necessary to assume the the user may have more than one OpenID and it would be necessary on all sites to maintain a list belonging to each user.

12. OpenID: Disadvantages and Next Steps Disadvantages – Possible security problems due to spoofing and/or phishing of the OpenIDs. - This could be addressed by adding some additional checks at the authenticating sites. Possible next steps: 1.Set up OpenID APs at all or most EDNP members. 2.Standardize on naming schemes - e.g user.openid.diamond.eu

13. Next Steps Set up OpenID More detailed survey of user databases (looking at possible ways to join them)

14. Questions and (hopefully) Answers