1 / 5

EGEE Security Plans and Identified Problems/Challenges

This document discusses the security plans and identified problems/challenges in the EGEE project, funded by the European Union. Topics include security requirements, middleware security, security architecture, and coordination with other grid activities.

erickv
Download Presentation

EGEE Security Plans and Identified Problems/Challenges

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EGEE SecurityÅke EdlundSecurity Head EU IST-FP6 Concertation, 17th September 2004 www.eu-egee.org EGEE is a project funded by the European Union under contract IST-2003-508833

  2. Contents • EGEE security plans • Identified problems/challenges EU IST-FP6 Concertation, 17th September 2004 - 2

  3. EGEE security plans (1/2) • Security Requirements - Horizontal activity, managed through central groups • Lesson learned: reused and updated requirements from earlier projects • Collecting (continuous process) the requirements from the activities - Middleware, Sites, Applications. • Share the requirements with other grid activities and get feedback, e.g. in the US • Prioritization set in the security groups, with representatives from all involved activities. • Defining what security modules to deliver when. • Product - leverage on the biomed requirements • To keep the industry focus we put extra effort, from day one, in supporting biomed applications, being a security demanding application. • Middleware - Security is not an add-on, has to be there from start • From start, and ‘all over the place’: All JRA3 members are also part of the Middleware development. • Active in the architecture and design of the middleware Middleware, JRA1 Security, JRA3 EU IST-FP6 Concertation, 17th September 2004 - 3

  4. EGEE security plans (2/2) • Security Architecture - Modular, Agnostic, Standard, Interoperable • Modular – add new modules later • Agnostic – modules will evolve • Standard – start with transport-level security but intend to move to WS-Security when it matures • Interoperable - at least for AuthN & AuthZ • Applied to Web-services hosted in containers and applications (Apache Axis & Tomcat) as additional modules • Worldwide solution - Involve non-European partners at an early stage • Bob Cowles (SLAC, OSG) and Dane Skow (Fermilab, OSG) members of the MWSG • Establish contact through hands-on activities. Example: EGEE and OSG to define common operational security procedures, by contributing to/working out common documents, mostly by reusing OSG work already in place. EU IST-FP6 Concertation, 17th September 2004 - 4

  5. Identified problems/challenges IssueCurrent solution Get focus on Security Active security work from start, security groups, driving/guiding documents Get involvement from GGF, OSG, .. Middleware Security Group (MWSG) Avoid gaps in the security work Security Architect for the MW, Security Head overall responsible Lagging standardization work, e.g. Writing initial recommendations OGSA (Open Grid Services Architecture) for reengineering focusing on ordinary WS now, OGSA later Coordinating operational sec work Joint Security Group (JSG, SA1), guided by JRA3 documents (created together with SA1, OSG) EU IST-FP6 Concertation, 17th September 2004 - 5

More Related