4 short pieces on: Virtual Organisations and VOMS

Combining the strengths of UMIST and
The Victoria University of Manchester
4 short pieces on:
Virtual Organisations and VOMS
Mike Jones

Overview

An introduction
• exactly what are we trying to solve with VOMS?
– movement from the individual authorisation
– to virtual organisation based authorisation
– let the virtual organisations manage themselves
– ease the burden on the resource owners

Contents
• historical introduction
– authentication and authorisation
– the emergence of the Virtual Organisation
– following suit in practice – what are grids doing about VOs
• VOMS overview
– introduction
– tools for the user, the VO, and the system administrator
• VOMS in production
– adoption by the UK NGS, GridPP and the LCG
• topics on federated identities

A Brief History of Grid Authorisation

Access to resource: what?
• objective
– to enable all those deemed worthy to find and use services on the internet
• what services?
– compute
– storage
– metadata
• data about available data and compute resources, ...
– peripherals
• telescopes, lab equipment, printers ...
– services

Access to resource: how?
• compute/storage
– assertion by daemon (password, fingerprint, asymmetric keypair)
– Access control lists based upon session's UID:GID
• compute is controlled by attributes of executable file
• data access depends on attributes of stored file and executable used to read it
• administration is expressed within the same system
• services
– translation somehow into the above
– depends upon UID:GID of who is running the service
• peripherals
– translation away from the above

Authentication and Authorisation
How does the system decide who's allowed to do what?
get information
process information
act upon information

Authentication & Authorisation
• authentication
– all about establishing authenticity
– everything else are attributes
• attributes
– information about a thing
• authorisation
– giving a thing the authority to do something
– often split up into:
• decision point – a translation of abstract attributes > native attributes
• enforcement point – a run time evaluation native attributes
often endlessly debated!

• authentication
– you're the person on this coin aren't you?
• attributes
– “has likeness on a coin”
– “wears a helmet”
– “has funny ears”
– is called “”
• authorisation
– is authorised to rule & rules.
– is equipped for battle & burns down temples.
example1: I have a coin.

• authentication
– An expert identifies that it is an authentic scroll
• attributes
– It is from the Mediterranean region and says: “This hereby certifies that
Nebuchadnezzar is ruler of all Babylon between 605 and 562 BC!”
• authorisation
– To a Babylonian: this might mean that Nebuchadnezzar, being their king, is
authorised to burn down temples. And the Babylonian might give him a torch to
do so.
– To an Israelite: these attributes give Nebuchadnezzar no such authority.*
example2: I'm given an ancient scroll.
*Illustrating validity of assertion

• BEWARE! that's not the conventional view
• authN and authZ are interpreted quite differently by different communities:
– the federated identity community:
• there's no effective separation between authentication and authorisation it's
all authorisation ... All authentic tokens are attribute assertions which are
used for authentication.
– the PKI community (and most of the Grid community):
• the deriving of a name based on attributes associated with a context. But are
“names” unique and do they map 11 with individuals?
• so it's confusing and the experts still argue about it.
we'll ignore this rift for the moment and concentrate on current grid practices...
eh?

Authentication according to Globus
• X.509 certificates
– PKI based authentication assertions
• certificate authorities (CAs)
– a breadcrumb trail back to the CA, a trusted source of authority (SOA)
– installed as CA files on the resources and clients for mutual authentication
– CAs usually also provide certificate revocation lists (CRLs)
• GSI extensions to the X.509 certificate format (RFC3820)
– delegation (of identity!)
– single signon

Authentication according to Globus
• X.509 certificates
– like the coin in the first example
• certificate authorities
– like The Mint
• GSI extensions to the X.509 certificate format (RFC3820)
– like getting small change – not really
– more like taking a rubbing or a cast of the coin.
• Globus identifies the person with a distinguished name attribute
like the coin analogy

Authorisation according to Globus
• local policy is stored in a gridmapfile
– this stipulates that the user credential's distinguished name (DN), in quotes, in
particular representation, may assume any local identity of the comma separated
values on the same line.
– only one match is made to the first distinguished name found
“/C=UK/O=eScience/OU=Manchester/L=MC/CN=michael jones” user1,user2
“/C=UK/O=eScience/OU=Manchester/L=HEP/CN=alessandra forti” user3
“/C=UK/O=eScience/OU=Manchester/L=HEP/CN=sergey dolgobrodov” user4
...
• policy enforcement is the call to fork+su+exec
– this is done by the gatekeeper and the gridftp server
– further policy enforcements are made by the underlying system

Authorisation according to Globus
• local policy is stored in a gridmapfile
– the scroll*, (authenticity preverified)
• policy enforcement was the call to fork+su+exec
– help him to carry out his edicts
– or deny him the privilege
like in the ancient scroll analogy
*Same idea for VOMS but VOMS is dynamic

How other grid middleware does it
• UNICORE
– policy decision based upon the resource having the user's X.509 certificate
locally stored (in the UNICORE User DataBase UUDB)
– enforcement by the Target System Interface, fork su and exec
– delegation by trusted schedulers resigning job objects (and some GSI support)
• GridSite
– policy decision based upon .gacl files and
– policy enforcement
• for the file distribution GridSite enforces the policy
• for the execution environment a modified suexec

Other authorisation middleware
• Akenti
– delegated policy based decision engine (JAVA)
– good model for systems with multiple online stakeholders
• PERMIS
– RBAC (role based authentication) decision engine (JAVA)
– support for hierarchical authorisation decisions
– support for plain language policy creation
– support for SAML* requests
• Shibboleth*
– browser based implementation of the SAML protocols
– sits between authentication and authorisation
– huge community uptake
*More a bit later

Enter the Virtual Organisation

What is a VO
• many definitions, the common points are that VOs:
– are groups of individuals and/or institutions and/or resources
– span multiple administrative domains
– in themselves form a new administrative domain
– should/can't be dynamic!!
• Other nongrid perspectives also suggest they should be
– transient by nature
– able to be setup and dismantled efficiently
– a cooperation of functionally and/or culturally diverse entities

Where does the concept fit into our grids
• dynamics/transient nature of our work:
– grids' resources have difficulty maintaining large changing lists of users
– grids' userbases have difficulty registering to the huge numbers of resources
• mapfile management is not scalable
• need to automate the authorisation process for our grids

Extending the functionality for Globus
• LDAP
– to effectively have online gridmapfiles
• pool accounts
– to allow leases of accounts on particular machines
• authorisation callouts
– since GT3.2 preWS there has been the ability to call out for authorisation
– in practice there are not many examples of this in use
The EDG approach

• CAS stores details about the user and resources and capabilities
• uses GSI proxy certificate with the CAS's identity
– CAS proxy certificate is treated essentially like a user certificate
– VO hidden from resource.
• community's CAS makes a policy decision to issue a proxy
• one account per community
– like account sharing and was frowned upon my many systems people
– some requirement evolved that the authentication must be with an individual
the old CAS (community authorisation server) approach

• Same community control over users, resources and capabilities
• a new type of GSI proxy certificate extension
– CAS assertion (SAML* assertion)
– assertions contain AuthorizationDecisionStatements bound to a name e.g.
• decision=“Permit” file:read file:write to /C=UK/CN=michael jones
• community's CAS makes a policy decision to issue an assertion
• server makes the policy decision and may also enforce it
– need not map the credential to a UID:GID
the new CAS approach

• VOMS stores details about a VO's structure and where its users lie within it
• a new type of GSI proxy certificate extension
– VOMS assertion (RFC3281)
– assertions contains group membership and role attributes bound to a name e.g.
• /C=UK/CN=michael jones is a member of ngs.ac.uk and is an administrator
• callout is made to a policy decision point (PDP)
– PDP translates the VOMS attributes into native attributes
the VOMS approach

CAS and VOMS
• described above is just a replacement for the gridmapfile
• using CAS or VOMS is designed to relieve the pressures on the site administrator
• choosing between CAS and VOMS
– code maturity and general adoption
– VO management – do you need/want the VO to control access to the resources

VOMS

So what is this VOMS thing?
• one or more databases of users, groups and roles
• a set of Web Services to query and administer the these databases
• a portal to interface to these Web Services
• a GSI service for obtaining “Attribute Certificates”
• a bundle of client and administration tools

What does VOMS buy me?
• the ability to create a database to represent a VO's user community
• the ability to administer it! add subgroups, roles
• delegate administration
• the ability to get attributes assertions (in AC format) to push
• the ability for relevant (authorized) parties to obtain lists of the VO's users

What happens now that we have a VOMS?
• with just those additions we don't really gain anything over the LDAP system
• need the VO's to become recognised on the grid servers
– setting up trust – effectively a VO registers on behalf of it's users
• need the grid services to be able to obtain and use VOMS information
– query VOMS servers
– consume VOMS attribute certificates

Attribute Certificates

So what exactly is an Attribute Certificate?
• RFC 3281: “An Internet Attribute Certificate Profile for Authorisation”
• DER encoded (just like your grid certificates (which are PEM wrapped DER files))
• containing
– version
– holder
– issuer
– serial number
– validity period
– attributes
– extensions
– signature

... and what's a VOMS one?
• built upon RFC3281, and is being reviewed in OGF
• holder:
– certificate issuer and certificate serial number
• serial number:
– code << sequence number (virtually unique)
• attributes:
– VOMS OID + VOMS Server URI + one or more of:
• /VO/subgroups/./././Role=Global Role/Capability=Deprecated Capability
• extensions*:
– critical: target URIs (optional)
– issuer certificates (optional)
– attribute issuer unique ID *See latest spec. for notyetinuse exts.

Delivering the Attribute Certificate
• one or more VOMS certificates can be placed inside a VOMS extension within an
X509/GSI certificate's extensions
– this is a noncritical extension (for backward compatibility)
– available to be extracted from the SSL context
• can be theoretically supplied other ways
– pulled perhaps
– cached perhaps

How can we actually make use of VOMS ACs?
• servers need to understand GSI for authentication
• we'd like to use the “push model”
– need to be able to extract ACs from SSL
• need to check AC is authentic
• need to check that AC is valid
• need to make authorisation decision
• need to realise that decision

The resources

What's out there to help the resources?
• the gLite way:
– LCAS (Local Centre Authorisation Service)
– LCMAPS (Local Credential MAPping Service)
• the Open Science Grid way:
– PRIMA (PRivilege Management and Authorization)
– GUMS (Grid User Management System)
– SAZ (Site Authorisation Service)

The OSG way

The gLite Way

VO Administration and VOMS

Building the VO
• configure the tomcat server (add a new servlet to represent the VO)
• configure and start the vomsd (GSI service)
• configure and build database using SQL
• vomsadminconfigure
– install | remove | update | upgrade

Building the VO database
• Admin specifies:
– database name, VOname, username, password, host, port, admin mail address
• vomsadminconfigure builds a DB with a complex structure:
– users: Distinguished Name + Certificate Authority
– groups table: references to the users
– role table: reference to users
– ACLs and actions
– credential sequence number
– VO information (host, port, code)
– logging
– tables to hold lots of other stuff java globs...

Building the VO daemon
– Database name, username, password, host, port, (code)
• vomsadminconfigure configures a demon usually listening on port ~15000
– configured to trust system's (grid) certificate authorities
– configured with access to the DB
• code is a way to ensure uniqueness of S/N of attributes if many servers serve ACs

Building the VO tomcat servlet
– Database name, username, password, host, port, (code)
• vomsadminconfigure configures a demon usually listening on port ~15000
– configured to trust system's (grid) certificate authorities
– configured to understand GSI
– configured with access to the DB

Building the VO
• Altering the VO in the VOMS
• Can be done using SQL ot the voms command tools
• BUT having built the VO instance it's really up to the VO to manage itself

VOMS and the Users

Administering the VO from within the VO
• authorisation to administer the VO based upon the ACL table and https context

Administering the VO from within the VO

Applying to join the VO

Interaction by the VO admin

user's view of the VO

Getting Attribute certificates
• /etc/gridsecurity/vomsdir/*
• /etc/gridsecurity/vomses/vo.namevoms.server
• vomsproxyinit
– replacement for gridproxyinit
– Uses GSI
– calls out to the voms server
• vomsproxyinfo
– replacement for gridproxyinfo

VO configuration aid for the user and the resource provider

Using Attribute certificates
• VOMS proxy certificates are dropin replacements for the GSI proxy certificates.
• VOMS part invisible/opaque to everything except services that understand them.

Accepting Attribute certificates
• Difficult at the moment unless you're using gLite middleware.
• LCAS configuration files
• LCMAPS configuration files

VOMS and the developer

VOMS API
• There is a c/c++ API
– the installation of VOMS is heavyweight unless you plan to install the whole
gLite/Globus environment
• The current VOMS draft specification is not too bad
– The current implementations don't quite follow the specification as it is being
written in retrospect
– But openssl tools and the sevanah bug list is a good place to start when things go
wrong!

Break?
If we didnt have one already!

Deployment Overview
What we've done in the UK

Problem Space
• in Globus based grids users are listed within files on the grid resources.
– Users rely upon the resource to preregister users' authority.
– Preregistration is basic and does not allow a user any granularity of authz.
• authorisation: from the individual to the group
– gridmapfiles
• the baseline authorisation method for Globus based grids
– LDAP directories
• used to populate gridmapfiles
– VOMS (webservice) directory lookup
• interim solution to allow groups to migrate to VOMS
– VOMS Attribute Certificates
• to enable users to assert their group membership

Manchester to host VOMSes
• GridPP @ Manchester (High Energy Physics group)
– a level of gridsecurity expertise in the HEP community
– Gridsite middleware and gridPP website secure hosting
– LDAP server hosting
– colocation with GridPP Tier 2 site
• NGS @ Manchester (Manchester Computing and ESNW)
– NGS core data node
– UK grid support role
– a number of relevant gridsecurity projects
– colocation with eScience Centre
• collaborative effort between GridPP and NGS
– (a collaboratory to host VOMS servers within?)

Hardware & Configuration

VOMS servers specs
• hardware – shuttleboxes
– CPU: 3.2 GHz Intel Pentium
– cache size: 1024 KB
– memory: 1 GB
– disk space: 160 GB
• software
– OS: Scientific Linux 3
– kernel 2.4
– gLite 3.0 VOMS server with MySQL DB backend
– VOMS admin interface 1.2.16

front server on
eth0:0
voms01.gpp.hep.man.ac.uk
alias on eth0:1
voms.gridpp.ac.uk
backup server
on eth0:0
alias on eth0:1
voms.gridpp.ac.uk
public test
server
no alias
VOMS Server Machines – GridPP

Deployment

Kickstart
• use Scientific Linux kickstart mechanisms to bootstrap the OS
• use cfengine to manage VOMS secrets
• manually obtain VO & VO membership details from any previous backedup data
– create dummy VO (hardwired from configuration)
– insert the VO data into VOMS using mySQL tools
• use mySQL dumps of the database periodically to back up VO membership
How we install VOMS

Further kickstart development (testing with NGS VOMS)
• designed to install OS and VOMS from scratch and configure VOMS service
• part 1 security bootstrap
– create local administrator users
– install certificates and keys for the server
– install CA certificates and revocation lists
• part 2 install VOMS and babysitting software from remote verified sources
– VOMS and configuration files
– monitor scripts
• monitor VOMS server health
• assume VOMS server identity if necessary
• notification
• database backups
Automatic VOMS service setup for two machines and failover

GridPP and NGS philosophies
• both GridPP and NGS have to deal with small groups of users. VOMS allows 2 ways
to deal with this situation:
1) a unique Top VO which may or may not have subgroups.
• single administration if there are no subgroups
• delegated administration if there are subgroups
2) many independent VOs
• administration is each VO responsibility
• NGS is first implementing a single large VO with subgroups
– primarily expressing the membership to NGS
• GridPP has employed the independent VO approach
– following the already existing structures within the HEP community.

GridPP (through VOMS) currently supports:
• 11 VOs
– local: manmace, ralpp
– regional Tier2: ltwo
– national: babar, cedar, gridcc, gridpp, minos, pheno, supernemo, t2k
• 59 user
• VOMS roles
– VOAdmin: manages users
– lcgadmin: VO software managers
– production: VO production managers
– user: common VO user

Migration Plans

How LCG is moving towards VOMS
• LCG CE and RB support a combination of gridmapfile and lcas/lcmaps this allows a
smoother transition.
– during transition
• LDAP servers kept alive with the old users
• VOMS used as an LDAP server for the new users
– in the meantime
• new users register in VOMS
• old reregister in VOMS
– when all users are in VOMS LDAP gets dropped and CE uses only lcas/lcmaps

From LDAP to VOMS diagram

PreVOMS Architecture
VO
Server
VO
Server
VO
Server
Resource
Client

VOMS based Architecture
VOMS
VOMS
VOMS
Resource
Client

Towards VOMS for the NGS
• creation of a VOMS server
• population of VO Membership data
• integration with existing user lifecycle poses some interesting challenges
– user quotas
• currently extra fields in the LDAP Directory
– SRB registration
• integration with the NGS registration process
– currently a web form.
– VOMS offers an admin interface for registration.
– VOMS also offers several APIs for integrating existing registration systems.
• basic authorisation based upon VOMS webservice and gridmapfiles
• Globus authorisation callout to e.g. LCASLCMAPS

Usability & Supportability

VOMS: Issues
• VOMS is not prefect yet!
– vomsldapsync (a script to populate a VOMS)
• Guesses users' missing authentication data but not very well.
– list of bugs in savanna
• AC certificate format problems etc.
– stability
• hanging of previous versions of VOMSadmin (gLite 1.5 and 1.4)
– how to map X.509 and VOMS to UID and GID?
(it's not all plan9!)

Savannah – VOMS bugs submitted over the last 2 months
October 2006, http://savannah.cern.ch

VOMS: server side wishlist
• more explicit error messages
• easier configuration
• email notification to more than one VO administrator
• regular internal & well developed mechanism for backing up the database.
• more explicit error messages
• LCG rollout to make the roles LCGadmin & production optional

Ease of use for users
• adding users is straightforward
• VOMS registration WEB page are accessible to everyone as long as they have a
certificate released from a recognised CA
– the user fills the form
– the system sends a confirmation email with a link to click on
• pretty much like a mailing list
– the VO manager is forwarded the requests and just have to click on a tick box is
he wants to approve.
– the user is added to all the systems that have that VO enabled
– the user can now use vomsproxyinit voms myvo to access the VO resources

Ease of use for users

Federated Identity

Shibboleth
• many grids are looking for less complex, ways to authenticate its users
• Shibboleth is being adopted as a top down authentication infrastructure
– http://shibboleth.internet2.edu/
• reference examples of gridsshibboleth integration:
– SWITCH AAI   http://www.switch.ch/aai/
– GridShib   http://gridshib.globus.org/
– ShibGrid   http://www.oerc.ox.ac.uk/activities/projects/index.xml?ID=ShibGrid
– SHEBANGS   http://www.mc.manchester.ac.uk/research/projects/shebangs
• of which SWITCH and SHEBANGS have VOMS components

SHEBANGS
Basic Architecture:

SHEBANGS Credential Translation Service
• It is:
– Shibboleth Service Provider – Offering a Credential Translation Service
– grid “Identity Provider” – Certificate Authority
– “Virtual Organisation Membership” service – VOMS Attribute Authority
– MyProxy Client
• It requires:
– Shibboleth/SAML implementation
– CA tools – (written in perl VOMS::Lite)
– VOMS tools – (written in perl part of VOMS::Lite)
– MyProxy implementation – (written in perl part of VOMS::Lite)
= Shibboleth protected CGI script

SHEBANGS Walkthrough
• https://wallace.mvc.mcc.ac.uk/scgibin/CTS

Walkthrough

Walkthrough
• https://wallace.mvc.mcc.ac.uk/MockPortal/
• https://wallace.mvc.mcc.ac.uk/MockPortal2/
•
• Feel free to try these, but you'll need to register with an IdP in the federation e.g.
– The openIdP

Acknowledgements
• Sergey Dolgobrodov and Alessandra Forti:
– details of VOMS in GridPP
• Michael Parkin
– VO definitions
• Robert Frank
– details and maintenance of NGS VOMS

4 short pieces on: Virtual Organisations and VOMS

Recommended

Recommended

More Related Content

Featured

Featured (20)

4 short pieces on: Virtual Organisations and VOMS