What are the gLite Metadata Interface methods?

Download Report

Transcript What are the gLite Metadata Interface methods?

EGEE User Forum
Data Management session
Development of gLite Web Service Based Security
Components for the
ATLAS Metadata Interface
Thomas Doherty
GridPP 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 - [email protected]
– Jerome Fulachier - [email protected]
– Fabian Lambert - [email protected]
• 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 selfdescribing databases
• supports geographical distribution with the use of
web services and secure access with the use of
grid-certificates
Fundamental Architecture
of AMI
AMI
Compliant
Databases
Other AMI Compliant
databases
Atlas Production
Bookkeeping
JDBC
JAVA API for AMI Data bases
Command
classes used in
managing the
databases
BkkJDBC
Generic
Packages
Database
Specific
Packages
allows for connection
to MySQL, Oracle and
SQLite
AMI Packages
Other packages
Atlas_Production
Generic web
search page
for example
• Three-tier architecture - generic packages - middle layer
• command classes placed within generic packages key to
the implementation of the gLite metadata interface
methods
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?
Checking, retrieval and
setting of privileges
administration
privileges
creation or deletion
of datasets
Retrieval of
versions
get, set,
clear, list
or query
metadata
for
datasets
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 Interfaces
Web Service client
gLite Interface gLite Interface
Implementation
method
Result returned
in XML format
Controller class
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 proxycertificates 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