Dynamic Privilege Management Infrastructures Utilising Secure Attribute Exchange Dr John Watt Grid D

1
Dynamic Privilege Management Infrastructures
Utilising Secure Attribute ExchangeDr John
WattGrid Developer, National e-Science
CentreUniversity of Glasgowjwatt_at_dcs.gla.ac.uk

2
Overview

• DyVOSE Overview
• PERMIS
• Static PMI Implementation
• Shibboleth and the SAAM Module
• Dynamic Delegation
• Future Work

3
DyVOSE Overview

• Dynamic Virtual Organisations for e-Science
  Education (DyVOSE) project
• Two year project started 1st May 2004 funded by
  JISC
• Exploring advanced authorisation infrastructures
  for security in context of education
• University of Kent provide authorisation software
  (PERMIS) and security expertise
• Applied in Grid Computing module part of advanced
  MSc at the University of Glasgow
• Will provide insight into rolling out
  authorisation infrastructures/Grid to the masses
• Exploration of current state of the art in
  authorisation infrastructures
• Second phase of work involves NeSC Edinburgh
• Extensions to the existing PERMIS infrastructure
  to provide dynamic delegation of authority and
  recognition of authority
• Project website http//www.nesc.ac.uk/hub/project
  s/dyvose/

4
DyVOSE Participants

• Dynamic Virtual Organisations in e-Science
  Education (DyVOSE) team
• Principal Investigators
• Dr Richard Sinnott (NeSC Glasgow)
• Prof David Chadwick (Kent)
• Implementation
• Dr John Watt (NeSC Glasgow)
• Dr Sassa Otenko (Kent)
• Mr Tuan Anh Nguyen (Kent)
• Mr Wensheng Xu (Kent)
• Other Key People Involved
• Dr David Berry (NeSC Edinburgh)
• Dr Sandy Shaw (EDINA) SDSS/Shibboleth

5
DyVOSE Workplan Phase 1

• Looking at applying existing PERMIS technology to
  establish static Privilege Management
  Infrastructure at GU

ScotGrid

GU Condor pool

Other (known!)

Grid resources

PERMIS based
Education
authorisation
VO
policies

Authorisation checks


Authorisation decisions

6
DyVOSE Workplan Phase 2/3
Glasgow
Edinburgh
ScotGrid
Condor pool
Blue Dwarf
Dynamically established VO resources/users
Delegated VO policies
Edinburgh Education VO policies
Glasgow Education VO policies
Shibboleth
PERMIS based Authorisation checks/decisions
7
Authorisation Technologies

• CAS/VOMS
• Rights/roles asserted by centralised server
• No interpretation needed at resource end
• Flexible at VO level, but no resource level
  decisions
• Akenti
• Access Control at Resource end (not central)
• Desirable
• Not VO specific
• PERMIS
• X509 and SAML

8
PERMIS

• PrivilEge and Role Management Infrastructure
  Standards validation

• X509 Role Based Access Control (RBAC)
• Attribute Certificates hold user roles in LDAP
• XML policy defines the access control
• Java API allows any app to be protected
• Complex Policies and multiple Attribute
  Authorities supported

9
PERMIS Functionality

• PERMIS allows to
• Define roles for who can do what on what
• Policy Role x Target x Action
• Can user X invoke service Y and access or change
  data Z?
• Policies created with PERMIS PolicyEditor (output
  is XML file)

10
PERMIS XML Policy
11
PERMIS based Authorisation

• PERMIS Privilege Allocator then used to associate
  roles with specific users
• Signed policies are stored as attribute
  certificates in LDAP server
• Exploiting the GGF AuthZ specification
• Generic way to authorise access to Grid services
  using SAML callouts
• Based on GT3.3 PERMIS
• Grid service (WSDD) has policy information
  associated with it
• DN of clients, target and actions checked when
  attempts made to invoke services
• BRIDGES and DyVOSE only projects exploiting this
  API right now (Von Welch at AHM 2004)

12
Explorations in Grid Course

• Students applied Policy Editor to develop
  security policy for use in their assignment
• Sorting/searching works of Shakespeare
• run on single PC,
• using training lab Condor pool,
• as GT3.3/Condor service,
• as GT3.3 service using GSI,
• To see how authorisation at service level
  achieved
• Service should be accessible by themselves and
  lecturing staff only
• using for GT3.3-PERMIS authorised service
• To see how authorisation at method level achieved
• Students split into groups (Gp1, Gp2)
• Sort method available to their group and
  lecturers only
• Search method available to all
• Performance aspects investigated throughout

13
PERMIS/Globus Issues

• Long time wrestling with GT3.3-PERMIS integration
• Some delays due to version issues with GT3.3
• Also required some debugging of GT3.3 (commenting
  out code)
• Continued feedback on PERMIS tools
• Policy editor refinements
• Numerous discussions/meetings with Salford team
  on sorting out PERMIS-GT3.3 issues
• Certificate dependencies in using PERMIS
• Expects certificates created using openSSL
• Experienced gained for DyVOSE Phase 2

14

• SSO and Access Control on Web Resources
• Home Institution AUTHENTICATES
• Recognised across the federation
• Temporary handle created
• Releases user attributes to service providers
• User can restrict attribute set release
• Resource Institution AUTHORISES
• Using attributes passed by the home institution
• Resource has final access decision
• Resource trusts Home to release correct info
• We have V1.2 operating as part of SDSS
• Walkthrough provided on DyVOSE website

15

• Messages are secure, attributes may not be!
• Shibboleth encodes its messages in SAMLv1.1
• But attributes are not digitally signed
  (plaintext)
• Authz Configuration is Apache-based
• Any changes to rules requires complete restart of
  Web Server
• Multiple Attribute Authorities unsupported
• Coarse grained access control function
• User A with Attribute B can access C

16
again!

• Could PERMIS resolve these issues?
• Attributes are stored in digitally signed X509
  ACs
• User attributes are now secure
• PERMIS PMI controls the Authorisation
• No Shibboleth/Apache restart when rules change
• PERMIS supports multiple Sources of Authority
• User may select attributes from more than one AA
• Complex access control policies
• Conditionals, Role Hierarchies

17
The PERMIS SAAM Module

• Apache module providing an authorisation handling
  function
• mod_permis loaded BEFORE Shibboleth module in
  Apache configuration file httpd.conf
• Requires alteration of approx 5 files at
  federation sites
• mod_permis can either
• Collect the ACs from LDAP itself (PULL mode)
• Be provided the ACs for decision (PUSH mode)
• Development of a Flexible PERMIS Authorisation
  Module for Shibboleth and Apache Server
  D.Chadwick, O.Otenko, W.Xu

18
The PERMIS SAAM Module
19
Dynamic Delegation

• Static PMI successfully built at Glasgow
• Goal is to build a PMI-based VO between Glasgow
  and Edinburgh
• Requires provision for Dynamic Delegation of
  Authority
• Extensions to the PERMIS software will implement
  this infrastructure
• Two cases will be investigated
• Static Delegation (easily done by adding
  Edinburgh SOA and Roles to Policy)
• Simple Dynamic delegation (this years Grid
  Course)

20
Static Delegation
21
Simple Dynamic Delegation
22
Future Work

• Implementation of new PERMIS Dynamic Delegation
  Software
• DIS (Delegation Issuing Service)
• Cross-certification
• Role Mapping
• Design of final student use-case to demonstrate
  dynamic PMI
• Final Report on best practices and methods