Providing Security in e-Infrastructure to Meet the Needs of e-Research

Attendees

Steve Crouch (facilitator), Phil Kershaw (scribe), Ally Hume, Tobias Schiebeck, Mike Jackson, Steve Wilson, Weijian Fang, Louise Price, Matthew Habgood

Overview

Security is often a key concern when conducting e-Research. OMII-UK has produced an overview document of security within the Grid and the support for various security mechanisms within its software (see http://www.omii.ac.uk/news/news.jhtml?nid=205). The aims of this topic (covered in a single session) were:

• How should the OMII-UK Security Document evolve?
• What challenges have been identified facing e-Research?
• What are the specific requirements for security within various domains, and what security related issues have been encountered in these areas?

Conclusions

OMII-UK Security Overview Document:

• Generally good - provides a solid overview of the concepts and the software security mechanisms
• What's missing:
  • Security logging/audit trails
  • Trust should be included at high level
  • A more layman’s approach to structuring
  • Include more advanced security concepts as they become included, but not include in-depth overview of everything e.g. single-sign on, VOMs, etc.
• Approach:
  • Consider each piece of software as a case study for different mechanisms of security
  • Document could be split into separate documents for project managers/PI’s, technical developers:
    • Into 1 overview document + 1 technical document
    • Into 1 overview document + 1 technical document per piece of software
• Should be widely advertised - perhaps include some covered information in FAQ, mailing lists

Challenges facing e-Research:

• Difficult to understand conceptually, set-up, configure, too many options, when it goes wrong security software is hard to troubleshoot.
• Usage of certificates is considered a problem – raised at NGS Innovation Forum. They are also often abused – using security certificates owned by others.
• Problem of crossing administrative domains in terms of security, for a number of reasons:
  • Organisational hurdles
  • Technical differences in architectures
  • Too many different solutions: Shibboleth, Athens, EduRoam
  • Often security solutions assume their own narrow solution – barrier to interoperating
• Security technology should be user driven rather than driven centrally

Specific security challenges faced by PAG:

• PAG requires it's portal software to be signed so it can be delivered as a portlet to a user. How best to do this?
  • Self signed certificates aren't obviously trusted by others.
  • e-science CA won't issue cert to sign code. Should service-level certificates be considered? A compromise would be to include the name of individual within the CN of the certificate.
  • Obtain a certificate outside of e-science - as in case of PAG, which purchased a commercial certificate.
• Securely exchanging certificates
  • Want to create a venue on a new venue server
  • 2 PAG clients – one creates a new venue at a venue server, needs to exchange a certificate so other client can use it – use some sort of SSL connection to exchange? How best to do this?

Further Work

• New draft of OMII-UK Security Document (Steve C)
• Circulate for wider review (Steve C)