VO Management
with VOMS

Ákos Frohner

Károly Lőrentey

Registration Flow

Undecided

Done

New

perform action
notify client

creation

confirm
email

send cookie
to client

notify
admins

accept

deny

Denied

notifyclient

Nolwen Fnord as admin

Create new user as local admin (local DB maintenance mode)

Assign Nolwen to the /Fnord/Role=VO-Admin role

Other admin functions:

group, role and capability creation and deletion

add/remove users from these containers

modify user details

Alain Guin as user

Request for VO membership

Receiving the confirmation email

Confirmation of the address

... waiting for Nolwen

Chris Grub as luser

Request for VO membership

Receiving the confirmation email

Confirmation of the address

... waiting for Nolwen

Pending requests

Allow/deny decisions at once

Nolwen making decisions

Other functionalities:

All requests (“resurrect”)

Incomplete requests

Details of a request

Happy Alain

Receives notification

Looks at the info page

Starts using the VO resources by using edg-voms-proxy-init every day...

Tries to add a group, but fails

Sad Chris

Receives notification

Tries to use the info page, but fails

Plans for Registration

Request for group or role membersip

Request for the creation of a new group or role

Change of DN old certificate expires and has to be replaced by a new one

Pre-registration hooks

Email address confirmation (done)

DN/CA check against the LCG guidelines database

Contact sites (to vote against)

Post-registration hooks

Notify sites in addition to the client

VOMS plans

Attribute Certificates (just arrived)

Replication of the service

History interface

Change of user info:

Phone number, institute

Email address (confirmation required)

... etc.

... improving the documentation! :-)

edg-voms-admin internals

SOAP interface for all functionality
currently with Java and Perl bindings, but can be extended to C/C++ clients stubs upon demand

Command line and web interface (using the SOAP API)

Complete audit logs for all events (at database level)

Fine grained access control on all containers (role/group/cap)

Extensible request flow engine with notifications

Internals 2: Overview

Layered architecture

Most SOAP calls are converted into Operation objects

Questions and Actions

Can be stored for delayed execution (requests)

Separate Authorization and execution

Expressed as a series of manipulations on domain objects

Active records

No transaction handling

High-level Operations

Low-level database
manipulations on
active records

Internals 3: Operation example

Operation example: create user

public class CreateUserAction extends ActionHelper {

private User user;	// Parameter

public User getUser () { return user; }

public void checkPermission() throws VOMSException {

DBGroup.getVOGroup().checkPermission (Operation.CREATE);

}

public void perform() throws VOMSException {

DBUser u = DBUser.create (user);

log.info (“User ” + u.getDN() + “ created”);

}

public CreateUserAction (User user) {

this.user = user;

}

}

Internals 4: Execution of Operations

Transaction handling is separated into a simple façade class

Allocates a database connection

Starts a new transaction

Checks permission

Performs the operation

Commit/rollback

Supports transaction restarts

Cures database deadlocks

Reliability under high load

Example: (from the SOAP implementation)

public createUser (User user) {

log.info (“createUser (...)”);

Database.perform (new CreateUserAction (user));

}

Request flow engine

Requests are entities requesting the execution of an Operation

Stored in the database as serialized Java objects

Flexibility

The most important values are indexed for speedy access

Each request has a request type that defines its workflow

State machines

Highly reusable components (states, events)

The workflow is independent of the operation type

Easily extendable

The SOAP API need not be changed for a new request type

Exception: new events need a new API function

Requests maintain a chronicle of what happened to them

Predefined request types

Automatic requests

Checked requests

Confirmed requests

(Timeout and Delete events not shown)

Done

creation

perform action

Undecided

Done

Done

Denied

perform action
notify client

creation

notify
admins

accept

notifyclient

deny

Undecided

Done

New

perform action
notify client

creation

confirm
email

send cookie
to client

notify
admins

accept

deny

Denied

notifyclient

Request examples

Creating a new request:

Processing an event:

public long newCreateRequest (final User user, final String comment) {

log.info (“newCreateRequest (...)”);

Object result = Database.perform (new ActionHelper() {

// An inline operation:

public void checkPermission();

public Object performWithResult() throws VOMSException {

Action action = new CreateUserAction (user);

Request request = ConfirmedRequest.createRequest

(action, comment);

return new Long (request.getId());

}

});

return ((Long) result).longValue();

}

public void allowRequest (final long id, final String comment) {

log.info (“allowRequest (...)”);

Database.perform (new ActionHelper() {

public void checkPermission() {} // done by the request type

public void perform() throws VOMSException {

Request r = Request.getInstance (id);

r.processEvent (new DenyEvent (comment));

}

});

}

user requests a certificate (once in every two-three years)

user sends the requests to the CA, which sends back the signed certificate

conversion to browser digestable PKCS12 format

registration in the EDG LDAP-VO (once for the lifetime of the VO – you may change the certificate keys!)

generats a proxy certificate (24 hours lifetime)

host/service requests a certificate

host/service sends the requests to the CA, which sends back the signed certificate

retrival of the trusted CA certificates and their CRLs (automatically updated every night/week)

generating a gridmap file from the LDAP database for authorization and mapping (automatically updated every night/week)

user contacts a service: they exchange their certificates to authenticate each other; the service bases its authorization decision on the gridmap file (... currently)

Real life example:

The traveller goes to the destination country and shows up his passport at the border. The officer checks its validity by comparing it to the example passport from the issuing country. He also looks at the list of revoked passports (coming from the originating country) and the visa, which allows the traveller to enter the country.

The traveller may also ask the officer to identify itself, so the authentication is also symmetric in the real life.

2003-12-14T21:12:22