Date post: | 14-Jan-2016 |
Category: |
Documents |
Upload: | gladys-hutchinson |
View: | 214 times |
Download: | 0 times |
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 - [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 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