1 / 4

Enhancing Grid Security with VOMS and GACL

Learn about Virtual Organisation Membership Service (VOMS) for efficient access management and Grid Access Control Lists (GACL) for streamlined authentication on the Grid. Explore compatibility, standardization, and fine-grained access control options.

jdumas
Download Presentation

Enhancing Grid Security with VOMS and GACL

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. EU DataGrid VOMS and GACL Andrew McNab, University of Manchester mcnab@hep.man.ac.uk http://www.gridpp.ac.uk/authz/

  2. Virtual Organisation Membership Service: VOMS • In EDG1.0, published lists of VO and group membership via LDAP (allocate pool accounts and grid-mapfile with this information.) • VOMS server instead supplies signed attribute certificates to users. • Users can then present these attribute certificates to sites/resources and obtain access with group privilege, role etc. • Certificates are included in GSI proxy certificates as extensions • but user’s authentication cert is still primary credential • backwards compatible with plain GSI or X.509 • Multiple attribute certificates can be used simultaneously, even from different VOMS servers and VOs. • Would benefit from standardisation of attribute certificates’ namespaces, group vs role vs capability, validity constraints, and “binary” / XML etc formats.

  3. GACL access control lists • When building GridSite, SlashGrid and the EDG Storage Element (“fileserver”), we needed a simple ACL format to use, in terms of GSI identities, or LDAP-VO and VOMS VOs and groups. • Currently use per-directory XML ACL in file .gacl • As a file, this can be stored in directories, copied via unmodified https or gsiftp channels and easily manipulated by scripts and applications. • Supports Admin, List, Read and Write privileges (cf. AFS) • Some of our applications are very sensitive to efficiency of parsing ACLs (eg SlashGrid filesystems.) • can currently do this by parsing ACL file once, evaluating credentials against ACL once, and then just stat()ing ACL file to check it’s not changed in the future. • Would like a standard ACL format, probably based on a recognised standard (XACML?), which we can nevertheless implement in a similarly efficient way.

  4. Grid ACL vs fine-grained VO: VOMS, CAS etc • VOMS (or CAS etc) can provide ACL-like features, specifying what capability (“write”) is permissible on objects (“higgs-wg-montecarlo”) • In some cases, this could be used to provide full ACL functionality. • However, we think this is too coarse-grained and too heavyweight for all contexts • eg if my job creates a temporary, working directory in /grid/tmp, I don’t want to have to set up a new entry on the central VOMS or CAS machine • We think the two types of system should be seen as complementary • when you create some Higgs Monte Carlo data, you set its local ACL to give write access for people with “higgs-wg-montecarlo-admin” credential. • when you create a temporary working directory, you set its local ACL to give only you read and write access. • applications should be able to “find their own level” when splitting policy between local ACL or VO-wide authorisation service

More Related