EGEE User ForumData Management session

Development of gLite Web Service Based Security Components for the ATLAS Metadata Interface

Thomas DohertyGridPP Physicist Programmer

Introduction

• Introduction– The AMI team– What is AMI?

• Fundamental Architecture and clients

– The gLite Metadata Interfaces– Adaptation of AMI Architecture for gLite– Securing and deploying the gLite Interfaces– The gLite search Interface– Authorisation and VOMs– Conclusion

The AMI Team

• The core of AMI was developed at LPSC Grenoble, by:– Solveig Albrand - solveig.albrand@lpsc.in2p3.fr

– Jerome Fulachier - jerome.fulachier@lpsc.in2p3.fr

– Fabian Lambert - fabian.lambert@lpsc.in2p3.fr

• The wrapping of AMI with gLite interfaces was my MSc. Thesis project and is found at:– http://ppewww.ph.gla.ac.uk/~tdoherty/MScThesis/MScThesis.pdf

• Since September I have been working full time in collaboration with the Grenoble team

What is AMI?

• It is a developing application, which stores and allows access to dataset metadata for the ATLAS experiment

• It fulfils the need of many database-backed applications by offering a generic web service and servlet interface, through the use of self-describing databases

• supports geographical distribution with the use of web services and secure access with the use of grid-certificates

Fundamental Architecture of AMI

• Three-tier architecture - generic packages - middle layer• command classes placed within generic packages key to

the implementation of the gLite metadata interface methods

Command classes used in managing the databases

allows for connection to MySQL, Oracle and SQLite

Generic web search page for example

Fundamental Architecture of AMI

and AMI clients• A controller class directly interfaces with the command classes in

the middle layer and with the client tier (illustrated later)• choose corresponding AMI command equivalent to the basic

requirements of each of the gLite Interface methods• There are three possibilities for the client:

• relevant client is Web Services client

• web services deployed on Tomcat with Axis framework plug-in

Why use gLite?

• Problem– Want AMI to be not only useful to

physicists but to any grid user

• Solution– Adapt AMI to handle the gLite Metadata

Interface.

What are the gLite Metadata Interface

methods?

administration privileges get, set,

clear, list or query metadata for datasets

creation or deletion of datasets

Checking, retrieval and setting of privileges

Retrieval ofversions

Adaptation of AMI Architecture for gLite

Interfaces

• What do we know so far?– AMI has a three-tier Architecture with command classes in

the middle tier– It is part of a client server model with the possibility of a

web service client– The gLite Metadata Interface methods can be matched to

AMI commands– Clients interface with a controller class on the server side

• What is the solution?– To have the implementation of the gLite interfaces on the

server side interfacing with the web service client and the controller class

Adaptation of AMI Architecture for gLite

InterfacesWeb Service client

gLite Interfacemethod

gLite Interface Implementation

Controller class

Result returned in XML format

Deploying and securing gLite web

service client• Note: This is covered in more detail in my Thesis.

Deployment• Deploy AMI in Apache Tomcat• Plug-in Apache AXIS (a soap engine) to Tomcat• Use AXIS tools to auto-create web service client classes

Authentication• Obtain a grid-certificate from a Certificate Authority• The user must be registered within AMI with specific privileges• A module called Trustmanager used in AMI extracts the

Distinguished Name (DN) from the certificate and AMI authenticates it

gLite Search Interface

• Within AMI data is organized in "projects". Each project can contain several namespaces

• namespace is "database" in MySQL terms, "schema" in ORACLE and "file" in SQLite

• When executing a search through AMI data – querying is done per “project”

• To be able to do a cascaded search across several projects of any type (MySQL, ORACLE or SQLite for example)

the gLite Search Interface was introduced• This can be done from one query

gLite Search Interface

• The EGEE grammar was transcribed so that we could use jflex for lexical analysis, and java_cup for syntax parsing.

• The parser translates the EGEE metadata query to an SQL query which is sent to all relevant AMI namespaces.

(For example if the “entity” to select is a dataset then we only send to namespaces where we know there is a dataset table.)

• The request is sent twice – the first time to know how many results would be obtained, and the second to get the results.

AMI Router Namespace and Authorisation

• AMI uses indirect connections to “namespaces”. Connections, authentication and authorization are handles by a special “namespace” called the “router”.

• Authorization is very finely grained. – Users have roles.– Roles have rights to execute commands.– Can be further limited by projects,– Or even records, – Or ad hoc controls (write special class & use java

reflection)• The router has the following structure.

Authorisation

A B

C

VOMS and Authorisation(at requirements analysis

stage)

• Obtain grid-certificate from CA• Request VOMs proxy certificate• Access AMI using this certifcate• User authenticated using

TrustManager• Authorisation achieved

depending on user task mapping correctly from their VOMS group/role to their registered user role within AMI

• This poses a problem for AMI

Problems with VOMS and possible solutions

• The main search interface for AMI is browser based

• Browsers at the moment cannot handle proxy certificates

• There are two possible solutions which will be tested as prototypes:– Mod_gridsite – this method fetches lists of DNs

from the VOMS system per group/role– MyProxy – this method allows for the storing of

proxy-certificates on a remote server

Conclusion

• Gave a brief overview of AMI design• An introduction to gLite Metadata Interface• How they where both integrated• An overview of how the interfaces were

deployed as secure web services• An introduction to AMI implementation of

gLite Search interface and VOMs

Result• Now have a secure and generic metadata

interface that supports a well defined API