Andrew McNab - EDG Access Control - 4 Dec 2002 EDG Access Control and User Management (ie Local...

Andrew McNab - EDG Access Control - 4 Dec 2002

EDG Access Control and User Management

(ie Local Authorisation and Accounts)

Andrew McNab, University of Manchester

[email protected]

Andrew McNab - EDG Access Control - 4 Dec 2002GridPP / EDG / WP6

Outline EDG Testbed Overview

Sysadmins’ issues

Existing VO vs CAS

Pool accounts

SlashGrid

Grid ACL’s

XML Grid ACL’s

GACL library

GGF Authorisation Working Group

WP2 Java Security

WP4 LCAS/LCMAPS Site Access Control


Existing EDG Testbed

Currently ~25 sites across Europe


Testbed site administrators’ initial worries...

How can Grid users gain access without me creating new accounts every day?

How can I limit what they can do?

How can I audit what they’ve done to me?

How can I keep track of files they’ve created?

Local access control and account management usually boils down to

mapping Grid identities into appropriate local Unix identities

while respecting the above.


Existing EDG LDAP VO EDG already has a type of VO authorisation server in use: centrally

provided authorisation listings published via LDAP (~300 users in ~10 VO ’s)

mkgridmap tool for building local grid-mapfile with local choice of VO ’s.

GUI tools allow VO managers to manage VO membership

Provides a list of DN ’s for a given group: eg an experiment, or a group within an experiment.

Groups have to be defined by an admin of the VO can’t be defined on ad-hoc basis by small groups of users

Current system gives the functionality running experiments like BaBar cope with, so ok.

However, scaling issues since each site must frequently (daily?) fetch listings for VO ’s it accepts.


Joining an application VO

Users first join the Acceptable Use Policy VO, with their web browser, using their certificate

this involves agreeing to the DataGrid wide AUP, that sets out obligations of sites and users

legal wording done in conjunction with CERN legal experts (who understandably have a lot of experience of international law)

Users can then join the VO of their application (eg an LHC experiment)

VO manager can choose whether to accept user

At each site, AND of AUP VO and Application VO controls access


VOMS - VO Membership Service This is similar to first CAS prototype, but retains user identity.

where CAS gave the user a VO-specific proxy to use, VOMS provides the user with an attribute certificate to include in their own proxy cert

This means proxy can be used with existing GSI-based services but VOMS-aware services can see additional credentials, like VO or

subgroup membership

this will remove the necessity to fetch membership lists every day

but for legacy services, DN membership list can still be obtained to construct grid-mapfile’s etc

VOMS administered in much the same way as existing LDAP VO

Users use voms-proxy-init tool which fetches signed attribute certificate from VOMS and includes this in proxy cert extensions

This will be deployed during current EDG 1.3/2.0beta development


Pool accounts The other half of removing account creation burden from admins

pre-create pools of accounts and allocate these to users when they request access

Widely used by EDG Testbed sites, but not obligatory in practice, almost all have chosen to use it

Auditing possible since all DN=>UID mappings recorded in log files.

Same pool mappings can be shared across a farm by sharing gridmapdir lock files with NFS.

Existing system works ok for CPU+tmpfile only jobs. but not really appropriate if users creating long lived files at the site in

question.

Limitations are because files are still owned by Unix UID: can’t recycle UID until all files created have been removed.


SlashGrid / certfs / curlfs Prototype framework for creating “Grid-aware” filesystems

different types of filesystem provided by dynamically loaded (and potentially third-party) plugins.

Source, binaries and API notes: http://www.gridpp.ac.uk/authz/slashgrid/

certfs.so plugin provides local storage governed by Access Control Lists based on Grid DN’s (and groups.)

Since new ACL’s just have creator’s DN, this is equivalent to file ownership by DN rather than UID.

solves admin worries about long lived files owned by pool accounts.

if pool accounts are prevented from writing to normal disks, then no chance they will write something unpleasant somewhere unexpected.

HTTP/HTTPS plugin (curlfs) ultimately aims to provide NFS/AFS-like functionality, again governed by Grid ACL’s.


Grid ACL’s

For simplicity, would want to have an ACL format we can use local and remote files, and other types of resources.

Current SlashGrid prototype and GridSite use per-directory ACL in .gacl

As a file, this can be stored in directories, copied via unmodified https or gsiftp channels and easily manipulated by scripts and applications.

Implementing ACL’s also solves some other issues that emerged during with Testbed 1:

eg per-UID tape storage: can store all tape files with one UID but associate ACL with the file and use that.

Sysadmins want disk filesystem ACL’s on same physical disk as files if possible.


Grid ACL vs VOMS (or fine-grained VO/CAS)

VOMS provides ACL-like feature of specifying what capability (eg write) is permissible on an object (eg higgs-wg-montecarlo).

(If using lots of subgroups within an LDAP VO, could achieve much the same thing: eg define a group of people in higgs-wg-montecarlo-write)

In some cases, this could be used to provide ACL functionality.

However, it 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 machine

The two systems should be seen as complementary when you create some Higgs Monte Carlo simulation, put it somewhere

the ACL gives write access for people with “higgs-wg-montecarlo” group.)

when you just create a temporary directory, the ACL defaults to just the creator having admin access.


An example XML Grid ACL format...

<gacl version=“0.0.1”><entry> <dn-list> <url>ldap://ldap.abc.ac.uk/ou=xyz,dc=abc,dc=ac,dc=uk</url> </dn-list> <voms-cred> <voms>/O=Grid/OU=abc.ac.uk/DN=AbcVOMS</voms> <vo>Abc</vo> <group>readers</group> </voms-cred> <allow><read/></allow></entry>

<entry> <person> <dn>/O=Grid/DN=Andrew</dn> </person> <allow><read/><list/><write/></allow> <deny><admin/></deny></entry></gacl>


GACL library XML ACL format not finalised but have several products in use

which need to use it: GridSite for www.gridpp.ac.uk; SlashGrid; fileGridSite; and EDG Storage Element.

ACL may change again in the future; may need to understand different (ugh!) ACL’s from other Grid projects.

Insulate ourselves from this by putting ACL handling functions into a standalone library, and make this understand the current XML.

Handles ACL’s in a reasonably general way packs C structs and linked lists with their contents

provides access functions to manipulate the structs as new types.

Despite current C implementation, API is readily translatable to object-orientated languages

Java API and implementation being produced


GGF Authorization Working Group (Authz)

This had BOF at GGF6 and is with GFSG now proposed chairs Markus Lorch (VT) and Andrew McNab (Manchester)

Initial objectives are authorisation Glossary, Requirements and Systems Review documents.

But underlying aim is to get all the authorisation people talking to each other, and hopefully standardising.

Areas we’re hoping for convergence in, are: VOMS vs CAS vs IETF Attribute Certificates

GACL acl’s + other ACL’s

Callouts/plugins for services to enforce locally defined policies

Fitting authorisaiton solutions emerging from Grids into wider Web Services security world

See http://zuni.cs.vt.edu/grid-authz for Authz WG website


Other authorisation work

EDG WP2 (Data Management) has built a set of Java security modules

this includes modules for verifying GSI proxies, and enforcing ACL and grid-mapfile access control

can provide security handling for other Grid services

filtering of both plain HTTP and SOAP requests, and queries from service itself during processing

EDG WP4 (Fabric Management) site access system LCAS - provides site-specific callouts to check authorisation based on

user identity, what is requested, quotas, free-slots in batch system etc

LCMAPS - manages current mappings of Grid to local identities

some of this functionality will also be provided by recent Globus proposal for authorisation callouts, but limited to yes/no on identity only


WP2 Authorization

(slide from Joni Hahkala)


David Groep – Pluggable Authorisation, LCAS and beyond – 2002.11.18 - 2

WP4 LCAS Authorization Service

LCAS plugable authorization

User Credentials

Name

Full proxy

J ob request details

Framework

combination of individual modules

Simple policy scheme (ordered)

Extensible (modules are .so ’s)

Near f uture (03Q1): ‘daemon’

TLS auth

LCAS client

apply creds *

Jobmanager-*

Gatekeeper LCAS

ACL

timeslot

gridmap

config

LCMAPS clnt

Id

Yes/no

In release 1.3


Summary Most of the concerns of Testbed site admins are being addressed

Current VO system is probably sufficient, but VOMS (or CAS) would be more flexible.

Pool accounts are useful but limited by UID file ownership issues.

SlashGrid / certfs provides a solution to this.

GACL library provides API for handling XML Grid ACL’s

Standardisation of these efforts starting with GGF Authz WG

Java Security tools being written for Grid Services to use

LCAS/LCMAPS allows flexible, locally configurable site policies

See http://www.gridpp.ac.uk/authz/ for links to source code and details of all tools mentioned in this talk

Andrew McNab - EDG Access Control - 4 Dec 2002 EDG Access Control and User Management (ie Local...

Documents

Transcript of Andrew McNab - EDG Access Control - 4 Dec 2002 EDG Access Control and User Management (ie Local...