JISC Security and Access Management Event

27 February 2006, Armada House, Bristol

http://www.jisc.ac.uk/index.cfm?name=event_security_0206

• Re-run of the October version of this event (see http://www.nesc.ac.uk/action/esi/contribution.cfm?Title=622 for slides etc.).

Anne Trefethen introduction

• General intro to AuthN and AuthZ, auditing trails of what heppened etc.
• Important that e-Science doesn't come up with security solutions that are completely bespoke to the application - it really needs to be more broadly applicable. Mentioned Shibboleth and how e-Science and the IE community should move together in this respect.

Nicole Harris, Programme Manager. "Access Management and Security"

• Going to be talking with most of the emphasis on e-research. How does JISC support e-Research? 6 sub-committees, but especially the "Support of Research" committee (JCSR). JISC doesn't do pure research - more implementation-oriented.
  • Divided into 'champion' areas.
    • Visualisation
    • Public Understanding and Outreach
    • Middleware And Technical development (Neil Geddes)
    • Security (Brian Gilmore)
    • [and several others I didn't catch!]
  Mentioned the AAA programme - ended in 2004 (a few projects went over into 2005) Now two programmes JIIE and JSR:
  • Core Middleware: Technology Development
  • and CM: Infrastructure.
  "JISC uses the term 'core middleware' for its current development programmes inline with vocabulary used at Internet2, TERENA and other major players in the field of national access management systems for education".
  • AuthN
  • AuthZ
  • Directory Services
  • Identifiers
  The current environment is:
  • Athens
  • e-research CA
  • Federated access trials
  • IP, proxy etc.
  [Nicole used the term "levels of authentication assurance" - is this the right term to be used? I'm not sure] Focussed activities:
  • Shibbolising JISC resources at MIMAS and EDINA
  • Support service - MATU at Eduserv
  • Early adopter funding for individual institutions
  • Regional Early Adoptors
  • Full federated service (probably UKERNA)
  • Communications and outreach programme (e.g. letters to all HE institutions)
  • Evaluation element
  • Repository of outputs
  Completes April (formally, but really July) 2006. Full federated AM system to be in place by July 2006.
  • Only really expecting early adopters to be using national service at that point.
  • Other new starters expected September 2006.
  Grid Oriented Developments (GOD)
  • DYCOM (PERMIS and GRASP) to allow fine grained AM across multiple authorities
  • DYVOSE - dynamic delegation of authority
  • FAME-PERMIS - authN strength/LoA
  • SIPS - PERMIS and Shib

  • SHEBANGS and ShibGrid

  e-Research interest in other projects
  • SPIE - n-tier issues
  • LICHEN - eduRoam in the UK
  • AMIE - attribute assignment and management
  All development focussed. Transition period from August 2006 - July 2008. Central Athens service will not be JISC funded after this date (although 'gateway' services may still be available). In the next few years, these are some of the possibilities:

  • Devel. core middleware with international partnerships

  • Enhancing AAI services
    • Virtual home for identities
    • VO support

    • eduRoam/Federation co-ordination

    • ShibGrid implementation

    Understanding Infrastructural Requirements
    • MIAP trials for e-Learning (Life-long learning)
    • joint support posts at UKERNA and CA
    • Accounting and auditing developments
    "Changing practice"
    • Level of Assurance
      • users need to understand a little how it works.
      Personal Identity Management
    Meeting service to service requirements
    • WS- and SAML compatibility, SAML 2.0 developments
    • Access management
    • Repositories
  A good deal of questions - v. well handled.
  • (Don't know how aware that most people in the room were of Shib, grids and the general AM issues as most questions came from only a few people - including the presenters).
  Attribute Release Policy tools
  • SIGNET (USA)
  • SHARPe (Australia)

Andrew Cormack, Chief Security Advisor UKERNA "Grids: Just another programme?"

• Grids are different/challenging
  • but not as different as an MLE
  • but more different than a new mail system (that uses standard protocols).
  If you're thinking about joining [your department?] to the grid
  • Think about support and response Users: rights and responsibilities
    • users need to be more aware, the environment is non-hierarchical
    Structures and authorities
    • non-hierarchical but might have its own policies
    Networks and systems
    • different challenges
    And make sure it doesn't harm the existing service.
  Support and response
  • grid apps are still developing
    • more tinkering etc.
  • staff need to liaise between users and providers
  • grid services need to be promoted to potential users
    • help early adopters - they will then promote to others
  • grid fault/incident response often involves others
    • (mentioned the EGEE security exercise recently)
    • grids distribute faults, mistakes and incidents too
    • decide what a grid incident might look like
      • and what is the appropriate response?
    • develop existing detection/response plans to suit
      • "Expand your list of contacts"!
      Some people are looking at network traffic flows and base these on how they define "incidents". Heavy grid flows are going to be common - need to be able to tell the problem bulk volumes from the genuine good jobs.
  Users: rights and responsibilities
  • Shared resources mean shared responsibilities
    • e.g. don't write applications to grab all bandwidth if there are other users dependent on that bandwidth.
    • Users must be cooperative and act responsibly
    • Users must respect policy decisions
      • of home site, networks and (many) resource providers
      • the users have more power to abuse (intentionally/unintentionally) using grids and therefore must be more aware.
      • Sites may need to trust users
    • Grids are work in progress
      • Users need some technical understanding
      • And sensitivity to policy and organisational issues
    • Policies may be behind the times
      • Users need to be understanding if they do something bad that doesn't break the existing policy
  Networks and systems
  • Some (not all) grids have high network demands
    • Ensure LAN and user equipment is suitable
    • May need to re-partition networks to segregate demand
  • Some (not all) grids use challenging protocols
    • Arrange firewalls - allow trunk flows
    • Dynamic flows in secured (including endpoints) tunnels
    • Make sure that you aren't providing a route around your existing security
  • Make sure exposed devices are well maintained
    • Applications
    • Grid software
    • Services
    • AND OSs
  Structures and authorities
  • Grids often share across traditional boundaries
    • Depts, orgs, national
    • User doesn't have a contract with the owner of that distant resource: therefore we need better understanding and enforcement.
  • May not fit existing AuthZ/enforcement structures
  Virtual Organisations
  • Home org does the AuthN
  • Resource provider does the AuthZ via a VO

    -> Federation model

  • Not a new idea
    • (IT and) libraries have had guest users for years
  • Will become increasingly common
    • Grids, Shibboleth, JANET Roaming/eduRoam
  • Federation of users and providers agree
    • Clear policies and responsibilities
    • Effective accounging and enforcement
    • To reassure both providers and users
  Developing Best Practice
  • Andrew's "Deploying Grids: UKERNA Technical Guide"
    • also
  • Grid Incident Response: TERENA TF-CSIRT discussion paper.

LUNCH

David Chadwick, PERMIS "Improved Authorisation"

• PERMIS AND SHIBBOLETH
  • Weaknesses in Shibboleth
    • Only one AA is supported
    • Plain attributes (relatively easy to be tampered with)
    • Only basic access control capability
      • need the person who owns the resource to control the access
      • at the moment it is mostly the "Apache administrator"
    What is PERMIS?
    • Modular AuthZ infrastructure -- all aspects of AuthZ
    • Allocating credentials to users
    • Supports distributed credential management
    • Supports dynamic delegation of authority
    • Supports hierarchical RBAC
    • Very secure as policies and credentials can be digitally signed.
    David gives a good credential trustworthiness example using monopoly money, house on mayfair and going to use the money at Tescos. PERMIS policy editor GUI that creates XML. Returns XML that has been written to the user in pseudo-English.
  Let's assume that there are many AAs around that the user needs for the resource to make authZ decision.
  • DyVOSE project (Dynamic Delegation of Authority) at Glasgow.
  • Web-based selection of attributes (roles) and also delegation of authority, and revocation - builds PERMIS policy in the background.
  PERMIS and Globus
  • Now nearly at the point where PERMIS can be used to have a common policy (and interface) between grid resources and campus based resources.
  SAWS - Secure Audit Web Service - effectively stores logs of privileges (including delegations etc.)
  • DyCOM project.

Tim Chown - LICHEN and the Janet Roaming Service

• JRS
  • Original requirement: people roaming about with wireless devices between institutions
  • Was LIN (Location Independent Networking) - rebadged for service launch as JRS 2 scalable solutions:
    • Web redirection gateway access control
    • 802.1x access control
      • access the layer 2 network (port) not granted until user enters their credentials
    What WASN'T adopted
    • Restricted VPN based access control (visit your home VPN)
      • Would not scale as local firewall would have to have the IP addresses of all the institutions' VPN servers - OK for 10s of sites, but not for 100s or 1000s
    National proxy that forwards radius request to home server. JRS has no policy element
    • allows all members of a site to have access
    • but for small collaborative projects, policy control is needed
    Location Independent Collaboration for Higher Education Networks (LICHEN)
    • Soutampton, Bristol and Manchester
    • for policies
    UK Shibboleth early adopters making progress
    • Can Shib be used for WLAN access control?
    • Could the JRS be used as a back end for Shib?
      • Problem: how can the wireless access point use a WAYF? and then a wireless WAYF use a home site Shib login?

    What about JRS using a Virtual Identity Provider (VIdP)?

    • This is the way!
      • 3 levels of attribute support:
        • A No attributes, just is 'a member of'
        • B Implement a common set of eduPerson attributes

        • C Allow bespoke attributes between VIdP and SP What they don't know yet is the demand for such attributes.

      Building a VIdP

      • No changes to WAYF of SP code

      • IdP modified to become VIdP

      • Home site needs to opt in
      • Some policy decisions needed, though.

      Who would manage the VIdP? Probably UKERNA.

Neil Geddes - ShibGrid/GridShib

• Background
  • JISC research into access management issues
  • Improve the way that users access resources across UK educational sector
  • JISC havce chosen Shibboleth
  Gave an introduction to Shibboleth Why do grids use GSI?
  • One of the first working solutions
  • Extensive testing in large deployments

    • IPG, DataGrid, TeraGrid, OSG, EGEE

  • Building of process and trust
    • Which certificates to trust (internationally)
    • International Grid Trust Federation (ITGF) www.gridpma.org
  • Proxy certificates (useful)
  AuthN on NGS
  • Uses GSI from Globus
    • Provides
      • delegation
      • international interoperability

  MyProxy

  • Not always convenient to carry your X.509 certificate around with you
  • Can put it (or a proxy) into a secure store which itself can be accessed easily from anywhere
  JISC Grid and Shib projects

  • to use MyProxy with Shib

  • to use Shib brokered authN to the NGS portal

  Talked a bit about GridShib project (Von Welch)

  • uses cert via GSI
  • but AuthZ via Shibboleth/SAML

  Introduded SHEBANGS and ShibGrid Next version of Shibboleth is coming up with a delegation profile, but it may not be good enough for most grid use. Condor is doing a lot of work to become Shibboleth-friendly. Future priorities and issues:

  • VOs

  • Shibboleth, VOMS, Permis, GridShib

  • Build authZ into some real world application
    • (I think he meant role-based)

Finished with relatively few questions and we pretty much got away early! Less animated than equivalent meeting in October in Edinburgh.

In the breaks I chatted with David White (Technology Assisted Lifelong Learning - TALL - at Oxford). He is doing something with Lionshare (peer to peer app.) for distance learners and the main problem is that their users cannot get on the Oxford databases (University Card, Herald etc.) and therefore they couldn't (easily) use Shibboleth or Webauth SSO to authenticate them.

Also spoke to Ioannis Daskalopoulos from Cambridge e-Science centre. He's working on Cancer Grid and is interested in role-based access to anonymised/de-anonymised data etc. etc. I told him about the VOTES work at Glasgow and of Von Welch's GridShib work.