LCGEGEE Security Update HEPiX, Fall 2004 BNL, 18 October 2004

1
LCG/EGEE Security UpdateHEPiX, Fall 2004BNL,
18 October 2004

• David KelseyCCLRC/RAL, UKd.p.kelsey_at_rl.ac.uk

2
Outline

• Update since October 2003 (Vancouver HEPiX)
• Introduction
• Policy
• Procedures Operations
• Technology
• Future work

3
Introduction LCG EGEE
4
LCG today
5
The next generation of gridsEGEE Enabling Grids
for E-science in Europe

• Build a large-scale production grid service to
• Underpin European science and technology
• Link with and build on national, regional and
  international initiatives
• Foster international cooperation both in the
  creation and the use of the e-infrastructure

6
EGEE Activities
32 Million Euros EU funding over 2 years starting
1st April 2004

• 48 service activities (Grid Operations, Support
  and Management, Network Resource Provision)
• 24 middleware re-engineering (Quality
  Assurance, Security, Network Services
  Development)
• 28 networking (Management, Dissemination and
  Outreach, User Training and Education,
  Application Identification and Support, Policy
  and International Cooperation)

Emphasis in EGEE is on operating a
production grid and supporting the end-users
7
Security Activities in EGEE(LCG)
CA Coordination
NA4
NA4
Middleware
NA4
NA4
Solutions/Recommendations
Req.
JRA3
JRA1
Applications
Req.
Security
Req.
Req.
Middleware Security Group
Joint Security Policy Group
Req.
OSCT
Req.
Joint Security Policy Group defines policy and
proceduresand inputs requirements to MWSG(For
LCG/GDB and EGEE/SA1) (Cross Membership of US OSG
Sec Team)
Operations
SA1
LCG
OSG
8
Security Policy
9
LCG Security Policy

• During 2003/04, the LCG project agreed a first
  version of its Security Policy
• Written by the Joint Security Policy Group
• Approved by the Grid Deployment Board/PEB
• A single common policy for the whole project
• But does not override local policies
• An important step forward for a production Grid
• The policy
• Defines Attitude of the project towards security
  and availability
• Gives Authority for defined actions
• Puts Responsibilities on individuals and bodies
• Now being used by EGEE and (some) national Grids

10
LCG Policy
New since Oct 2003
picture from Ian Neilson
Incident Response
Certification Authorities
Audit Requirements
Usage Rules
Security Availability Policy
Application Development Network Admin Guide
User Registration VO Management
http//cern.ch/proj-lcg-security/documents.html
11
Security Procedures Operations
12
Security Procedures

• Incident Response
• Open Science Grid leading this area
• See talks in Friday mornings Operations session
• LCG/EGEE Operational Security
• Operational Security Coordination Team (OSCT)
• Again see Fridays talk
• User Registration VO Management
• Requirements for 4 LHC Experiments
• Presented at May 2004 (Edinburgh) HEPiX (M.Dimou)

13
User Registration and VO Membership Management

• Requirements document (V2.7)
• https//edms.cern.ch/document/428034
• approved by GDB in May 2004
• Task force created to propose the solution
• Many discussions with CERN HR, User Office,
  Experiment Secretariats, VO managers,
• Recent Meeting at CERN
• 15-17 September, 2004
• http//cern.ch/dimou/lcg/registrar/TF/meetings/20
  04-09-15/
• Technical solution now agreed

14
User Registration (1)

• Every user (4 LHC expts) must register in CERN HR
  db first
• Already true for the majority
• Advantages of using existing procedures
• No duplication of effort or personal data
• External users (e.g. people never coming to CERN)
  and short-term users (e.g. external summer
  students)
• Need a simple, speedy and robust procedure
• Non-VO people
• e.g.testers/experiment independent people
• must register in CERN HR (e.g. via LCG/IT)
• Eventual aim is to use the experiment
  participation end-date in CERN HR to trigger
  immediate suspension from the VO

15
User Registration (2)

• VO registration expiry date
• Not exceeding 1 year from date of VO registration
• Less if institute-contract/CERN HR registration
  expires before then
• Personal User Data will only reside in CERN HR
• There is no automatic membership of VO
• User has to complete a form and the VO manager
  has to approve
• Authorized personnel at resource centres will
  have read access to the VO registration info

16
User Registration (3)

• When VO expiry date is reached, the VO membership
  is immediately suspended
• Advance warning will be sent to the user
• There will be other possible reasons for
  suspension
• E.g. following security problems

17
Technical Solution agreed

• 15-17 Sep meeting decisions
• The VO registration database
• Will be VOMRS component from US CMS VOX
• VOMRS needs development to meet new requirements
  (FNAL working on this)
• VOMRS manages the groups and roles -gt VOMS
• CERN is working on VOMRS interconnection to the
  CERN HR DB (Oracle)
• The dynamic Authorization will be VOMS
• Groups and roles
• Non-LHC VOs may use the VOMS-admin component (an
  alternative admin UI)
• Time to implement not yet agreed
• Aiming for early in 2005

18
Security Technology
19
Authentication EU Grid PMA CAs

• Green Accredited
• Yellow Recent approvals or still under
  discussion
• Slovenia just approved
• Austria Bulgaria soon?
• Other Accredited CAs
• DoEGrids (US)
• GridCanada
• ASCCG (Taiwan)
• ArmeSFO (Armenia)
• CERN
• Russia (HEP)
• FNAL Service CA (US)
• Israel
• Pakistan

27 Accredited CAs
Catch-all CAs operated by CNRS (for EGEE) US
DOE (for LCG) SEE-GRID (for SE Europe)
20
AuthZ VOMS LCAS
host cert(long life)
service
user
crl update
user cert(long life)
VO-VOMS
registration
registration
VO-VOMS
voms-proxy-init
VO-VOMS
proxy cert(short life)
service cert(short life)
VO-VOMS
authz cert(short life)
authz cert(short life)
authentication authorization info
LCAS
21
gLite security

• Aims at being
• 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
Security architecture https//edms.cern.ch/docume
nt/487004/
22
EGEE AuthZ Policy
Policy comes from many stakeholders
Graphics from Globus Alliance GGF OGSA-WG
23
Future Work

• Policy
• Working on more general policy (with OSG)
• No longer LCG-specific
• EU eInfrastructure Reflection Group (18 Nov 04)
• Acceptable Use Policy and Authorization for EU
  eScience
• Procedures
• Operational Security, including Incident Response
• User Registration
• Technology
• Authentication
• Asia/Pacific Americas PMAs being created
• Credential Repositories
• Authorization dynamic role-based access control
• VOMRS VOMS
• Local control and policy, e.g. via LCAS/LCMAPS
• Security requirements, Operational Constraints
• Very important to get Site input to operations
  and middleware development (all feedback is very
  welcome!)

24
References

• LCG/EGEE Joint Security Policy Group
• http//proj-lcg-security.web.cern.ch/
• EGEE JRA3 (Security) http//egee-jra3.web.cern.ch
  /
• Open Science Grid Securityhttp//www.openscienceg
  rid.org/techgroups/security/
• EU DataGrid Security http//hep-project-grid-scg.
  web.cern.ch/
• LCG Guide to Application, Middleware and Network
  Security https//edms.cern.ch/document/452128
• EU eInfrastructure Reflection Group http//www.e-
  irg.org/
• EU Grid PMA (CA coordination) http//www.eugridpm
  a.org/
• TERENA Tacar (CA repository)http//www.terena.nl/
  tech/task-forces/tf-aace/tacar/