Data Grid Security Wrapup Linda Cornwall 4 th

Data. Grid Security Wrapup Linda Cornwall 4 th March 2004

Data. Grid Security Co-ordination Group • No single work-package to tackle Grid security – But WP 2 has a security task and team • Security Coordination Group (SCG) was formed in late 2001 – Lead by David Kelsey • Mandate of SCG (sub-group of WP 7) – To produce the Deliverables of WP 7 on Security – To help coordinate security activities in WPs 1 to 7 – To liaise with WP 6 CA & Authorization groups (and others) – To contribute to the architecture of the EU Data. Grid (ATF) • SCG has larger scope than originally foreseen – At least one representative per middleware WP – Collaboration with Data. TAG and national Grid projects

SCG Achievements - overview • Authentication: Certification Authorities (CAs) for EDG and others – WP 6 Certificate Authorities Coordination Group • Data. Grid Security Requirements (D 7. 5, May 2002) – 112 requirements in many areas… – Authentication, Authorization, Auditing, Non-repudiation, Delegation, Confidentiality, Integrity, Network, Manageability, Usability, Interoperability, Scalability, Performance, Robustness – Priority attached – Data. Grid Requirements, Aims within EDG, Long Term aims • Several joint meetings with WP 8, 9 and 10 for VO use cases • Security Design (D 7. 6, March 2003) (Large UK contribution) • Final Security Report (D 7. 7, January 2004) – includes comparison with initial requirements

Summary of the EDG Security design • Users are issued with a PKI certificate from their local (country) Certification Authority. • Users become a member of one or more `Virtual Organisation’ (VO) • Users are issued with authorization credentials by the VOs to which they belong • Authorization rules are enforced by the local sites or resources – Various Language dependent tools have been developed

Overview of the EDG Security Components (D 7. 6) CA proxy cert: dn, cert, Pkey, VOMS cred. (short lifetime) certificate VOMS request certificate: dn, ca, Pkey user VOMS cred: VO, group(s), role(s) delegation: cert+key (long lifetime) re-newal request My. Proxy delegation: cert+key (short lifetime) proxy cert proxy cert auth Trust. Manager authz Web. Services Authz dn, attrs, acl, req. op ->yes/no auth mod_ssl Trust. Manager pre-process: parameters-> obj. id + req. op. GSI pre-process: parameters-> obj. id + req. op. auth GSI authz LCAS dn, attrs, acl, req. op ->yes/no map dn -> DB role authz doit authz obj. id -> acl dn, attrs, acl, req. op ->yes/no GACL: obj. id -> acl dn, attrs, acl, req. op ->yes/no doit coarse grained (e. g. Spitfire) authz GACL: obj. id -> acl dn, attrs, acl, req. op ->yes/no doit fine grained (e. g. RMC) Java fine grained (e. g. Grid. Site) web LCMAPS dn -> userid, krb ticket doit C fine grained (e. g. SE, /grid) coarse grained (e. g. gatekeeper)

Achievements - Authentication • PKI based Certification Authorities (CAs) for EDG and other Grid Projects – Data. TAG, Cross. Grid, LCG – including a global service for particle physics – Same CAs used by many national projects • Tools to carry out Authentication in languages other than `C’ (GSI) – java (edg-java-security trustmanger) – Apache web services (mod_ssl)

Authorization – Early on • VO LDAP server was developed to manage VO membership – This produced a grid-mapfile • Tool for leasing Pool Accounts to users defined in the gridmapfile obtained from the VO LDAP server • Combination of these allowed users access to resources without a specific account on that particular host. • This provides very course grain authorization according to a VO based identity

Authorization VOMS • Virtual Organisation Membership Service (VOMS) developed jointly between EDG and Data. TAG projects. • Allows for the managements of VO membership for both Users and Services and the issuing of Credentials proving – VO membership, Groups, Roles and Capabilities • VOMS credentials are in the form of a extension to the GSI proxy – VOMS proxy

`Local’ Authorization • Various tools have been developed within EDG to allow access in the local environment. • LCAS and LCMAPS for authorization in C/C++ services • Java authorization Manager – Coarse grained authorization mapping – Credential extraction and checking to allow fined grained authorization by the service • Grid. Site – Authorization in Web services environment • GACL `Grid Access Control Language’ for defining access control based on Grid Credentials

Requirements analysis (EDG 2. 1) • Data. Grid Requirements No. • Success • Mostly satisfied • Not satisfied FS PS NS Authentication 13 11 1 1 Authorization Confidentiality 23 8 9 6 14 1 3 10 Non-Repudiation 3 3 Usability 3 3 Interoperability 3 2 1 Other areas 15 3 8 4 Total 74 28 22 24 FS= fully, PS=partially, NS=not… satisfied “Partially” means not all WPs and/or not all languages

Summary of progress • Authentication – lots of success! • Large amount of progress in Authorization mechanisms – Need to be fully integrated with other middleware • Confidentiality – area where we largely failed. – Depended on Authorization integration being complete, and data being stored in encrypted form – More of a problem for e. g. Bio Medical applications than particle physics • Interoperability – also largely successful. – Based on GSI – Worked closely with the international community, GGF • Some other areas need much more work – security largely turned off in EDG testbed 2. 1 – Liable to denial of service attacks • Areas like non-repudiation need more attention.

Lessons learned • Be careful collecting requirements – In hindsight, the D 7. 5 requirements were rather ambitious – The expectations of the applications were documented but there was not sufficient analysis of the difficulty of integration • Security must be an integral part of all development – from the start • Building and maintaining “trust” between projects and continents takes time – Not just about middleware • Integration of security into existing systems is complex – When designing middleware `think security’ – Don’t rely on adding it later • There must be a dedicated activity dealing with security • EGEE planning has already benefited from our experience

Exploitation • Authentication – The CA infrastructure will continue – EGEE will manage the EDG PKI in a new EU PMA – LCG driving the requirements for global physics authentication – Grid CAs to be registered in new TERENA CA repository (TACAR) – e. Infrastructure and e. IRG meetings (Ireland) to consider this topic • A general EU Grid PKI infrastructure? – Data. Grid people will continue in EGEE and GGF • Security Policy issues – Data. Grid people already active in defining LCG policy and procedures – Important input to EGEE and e. IRG

Exploitation (2) • Authorization – EDG components and people will continue in EGEE, LCG and other projects – VOMS is part of LCG-2 • The HEP applications need roles and groups – Integration with Slash. Grid, ACLs (GACL) and Grid. Site • Joint work with UK Grid. PP, using VOMS and working with PERMIS team • Greater exploitation of the various Authorization tools will possible when they are fully integrated with other middleware – Work in GGF security area groups will continue • • EDG providing reference implementations in OGSA-Auth. Z WS-security, VOMS, LCAS, Grid. Site, Slash. Grid etc XML policy, XACML, VOMS Attribute Certificates, SAML Will continue to drive and track standards • Publication of the work is ongoing