Andrew McNab - Security - 1 July 2003 Security: Authorization, Access Control and Usage Control Andrew McNab, University of Manchester [email protected]

Andrew McNab - Security - 1 July 2003

Security: Authorization, Access Control and Usage Control

Andrew McNab, University of Manchester

[email protected]

Andrew McNab - Security - 1 July 2003GridPP / EDG / WP6

Outline

Certificates and VO servers

New VOMS system

Using VOMS

Access Control: GACL

mod_gridsite

mod_slashgrid?

Usage Control: PBS and Unix disk quotas

“Usage peering” and retrospective usage targets

Genuine accounting

Future security work


Certificates and VO servers EDG users and hosts are identified by X.509 certificates, signed by

one of ~20 “national” Certificate Authorities. Jobs use a short term certificate derived from this: GSI Proxy.

X.509 defines how user’s public key and the CA’s signature of key + the user’s name is stored.

This provides authentication: equivalent to an ID Card.

Simplest way to build authorization and access control using this, is with a list of authorized users for a resource.

This is what EDG currently does with LDAP VO servers. Lists of members for each Virtual Organisation (ATLAS, BaBar etc) are

published.

Sites make local authorized user lists (grid-mapfile) from this.

However, scaling and latency issues since all sites must fetch list of all users currently authorized


Virtual Organisation Membership Service: VOMS

Instead of publishing lists of VO and group membership, supply signed attribute certificates to users: Ticket rather than ID Card.

Users can then present these attribute certificates to sites/resources and obtain access with group privilege, role etc.

Certificates can be included in GSI proxy certificates as extensions “A ticket in your ID card wallet.”

Multiple attribute certificates can be used simultaneously, even from different VOMS servers and VOs.

Potential to allow users to create ad-hoc groups within VO, and to discard unnecessary VOMS credentials at delegation steps.

Implementation is backwards compatible with normal Globus and HTTPS use of certificates

so still compatible with other Grid projects and HTTPS webservers.


Using VOMS

Virtual Organisation sets up a VOMS server This has a list of members of the VO, and what groups, roles and

capabilities they have.

They can be listed in more than group.

Instead of using grid-proxy-init to make temporary proxy “each day”, users use voms-proxy-init command

This contacts VOMS server and creates proxy with VOMS extensions

Main body of proxy proves identity

VOMS extension(s) prove VO and group memberships.

Users can choose which subset of their groups to include in proxy Useful for privacy (bio applications esp.) and to avoid giving

unnecessary rights to jobs.


Access Control: GACL

When going beyond simple lists of users, need a more flexible way of writing access control policies that can include individuals, VO-LDAP or VOMS groups.

GridSite, SlashGrid and Storage Element use GACL, simple Access Control Lists written in XML.

Simplicity important because these fileserver / filesystem applications involve very many access control evaluations.

However, GACL isn’t a recognised standard and something standards-based would be better.

Could go to, say, an equivalent subset of XACML.

Proposed OGSA Authorization WG in GGF may endorse some way of using (probably) XACML as an “Authorization Language.”


GridSite

GridSite manages access to websites and HTTP(S) fileservers Users and admins load GSI cert + key into unmodified web browsers

Originally produced for www.gridpp.ac.uk

GACL ACL’s control level of read and write access to file/directory Write access by HTML forms (interactive) or HTTP PUT (programmatic)

Programmatic access makes webserver export something looking more like a filesystem: GET (read), PUT (write), HEAD (stat), DELETE (unlink)

New 0.9 architecture provides extended functionality via Apache module.

Support for efficient HTTP GET and PUT operations.

ACLs enforced at low level inside Apache request processing so now available for coarse grained access control to PHP, CGI, JSP etc as

well as HTML.


mod_gridsite

mod_ssl: plainHTTPS > env vars

mod_gridsite: GACL access control + GACL > env vars

mod_gridsite:.html headersand footers

.shtml,mod_perlCGI, PHP

mod_jk:JSP withTomcat

HTTP

grst-admin.cgi: page editing,file upload, ACL editing etc.

grst-proxy.cgi: G-HTTPS, 3rdparty COPY, proxy GET + PUT

mod_gridsite:PUT, DELETE,

MOVE

mod_ssl-GSI: HTTPS withGSI+VOMS+CAS > env vars


SlashGrid Framework for creating “Grid-aware” filesystems

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

client-side daemon manages access and remote file fetching: cf AFS cache daemon on clients.

Supports access control by GACL.

Remote filesystems possible: curlfs plugin maps remote HTTP(S) server into local filesystem.

However, existing SlashGrid implementation uses coda kernel module (Mostly) Linux specific.

Difficult to permit partial reads of remote files.

Various options for other kernel->SlashGrid connectors considered: In particular, OpenAFS kernel module and NFS.


mod_slashgrid Old SlashGrid daemon has to:

listen on a socket for filesystem operations (from kernel)

manage a hierarchy of files, including access control

support third party plugins in C, Java, other languages

This sounds very like a web server.

Apache 2.0 transports/filters stack allows non-HTTP protocols eg mod_ftp and even mod_pop3 has been written.

Rework SlashGrid as an Apache module, exporting GridSite web server “filesystem” via local TCP NFS rather than HTTP.

We get remote filesystems “for free” via mod_proxy and mod_cache

Access control already done, via mod_gridsite.

Can now write third-party filesystem plugins in C/C++, Perl, Python, Java, PHP, Bash - anything you can write web server CGI/dynamic content in.


mod_gridsite + mod_slashgrid

mod_ssl: plainHTTPS > env vars

mod_gridsite: GACL access control + GACL > env vars

mod_perl,CGI, PHP

mod_jk:JSP withTomcat

HTTP

mod_gridsite:PUT, DELETE,

MOVE

mod_ssl-GSI: HTTPS withGSI+VOMS+CAS > env vars

mod_proxy,mod_cache:

remote servers

mod_slashgrid: NFS with envvars according to UID credentials

kernel: NFS localmount of /grid


Usage Control: PBS and Unix quotas Of Security’s “Authentication, Authorization and Accounting”, we

have made significant progress with the first two. But without Accounting, individual users can monopolise resources.

First step towards Accounting is local Usage Control: “quotas” etc.

Can already implement basic usage control using PBS and Unix quotas, resource limits etc.

Since users allocated to one of a pool of accounts for their VO, could set up pool accounts with appropriate Unix groups, quotas etc.

This has been investigated by some Testbed sites in various ways.

However, this is quite inflexible and imposes static upper limits rather than allocating some amount of resources for the job duration.

Ideally should be integrated into the job description and management somehow, so know how much is allowed and to clean up afterwards.


“Usage Peering” and retrospective targets

On what accounting basis will sites put genuine resources of their own into the Grid?

(This is much simpler if resources are earmarked for a specific user community - eg Tier 1A partitions - but difficulty is for Tier 2 sites.)

One way is for sites (or groups of sites) to peer with each other in terms of usage over some accounting period.

For example, University A peers with College B, agreeing that during the accounting period, members of A and B will get equal amounts of usage of each others sites.

Could also do this with groups/collaborations: eg University A joins “C-Grid” by making a certain amount of its resources available to other “C-Grid” sites in return for the same total use of other “C-Grid” sites.

Can do this with existing technology by putting non-local members of “College B” or “C-Grid” into Unix groups and manually throttling CPU, disk etc use during accounting period to fit agreed targets.


Genuine accounting Genuine accounting may include: per-user measurement of use,

enforcement of “credit limits”, charging, getting a price for a job and brokering based on price.

Would be possible to do things purely economically with this in place: eg University A gets £1,000,000 of equipment from SRIF and rents it out

to users on the open market. Uses the income to buy access to resources when its own users need it.

(Money was invented to save us from “peering” a.k.a “a barter economy.”)

In that kind of Grid, can choose how to operate between that and the other extreme position: “our equipment that only we use.”

Even though optimisation / brokering / ”marketing” outside of the scope of Security, but we need to provide the local accounting tools needed.

The “choke points” we’ve put in place for Access Control are very suited to Usage Control and usage recording.


Future Developments

EU DataGrid and GridPP-1 nearing end of lifespans

Security part of GridPP-2 proposal includes completion of Authorization work and implementing systems required for Accounting.

This will need to be co-ordinated with: LCG requirements - already recognised the need for Usage Control

as an urgent requirement from applications.

EGEE work - again, Security Taskforce recognised Usage Control and Accounting as significant area that is missing.

GGF - various accounting and economic models working groups already running, with large UK contributions from Manchester and London e-Science centres.


Summary

VOMS provides users with authorization credentials more scalable than current VO-LDAP system

GACL represents Grid access control policies (“access control lists”) in XML.

GridSite enforces these for web/fileservers.

SlashGrid being brought into this system as Apache module more portable and better able to handle partial remote file access.

Basic Usage Control possible using Unix mechanisms.

“Usage Peering” with retrospective targets would provide a way of doing accounting in the near term.

Aim to provide more advanced accounting tools for LCG etc in GridPP-2.

Documents

Andrew McNab - Security - 1 July 2003 Security: Authorization, Access Control and Usage Control Andrew McNab, University of Manchester [email protected]