This affects applications and accounting

Download Report

Transcript This affects applications and accounting

GUMS status
Gabriele Carcassi
PPDG Common Project
12/9/2004
Outline
• GUMS description
• Status
• Issues encountered during development
and other open issues
What is GUMS?
• GUMS allows a site to centrally manage
the mapping between Grid Identity to local
identity according to a site wide policy
/DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi
Grid
resource
BNL
GUMS
carcassi
<xmlPolicy>
On *.usatlas.bnl.gov allow:
Members of Grid3 VO mapped with
accounts taked from a pool
Members of a special list from a
database mapped to ‘special’
…
</xmlPolicy>
Features planned for OSG-0
• Account pooling
• Service implementation
• Role based authorization
Account Pooling
• A generic grid user will be assigned a generic grid
account (no recycling) from a pool of pre-created
accounts -> This affects applications and accounting
…
grid0009
grid0010
grid0011
grid0012
grid0013
grid0014
grid0015
grid0016
grid0017
…
/DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi
/DC=org/DC=doegrids/OU=People/CN=Dantong Yu
/DC=org/DC=doegrids/OU=People/CN=Razvan Popescu
/DC=org/DC=doegrids/OU=People/CN=Dantong Yu
Will allow BNL cybersecurity to perform auditing
To go in production we need:
1. Assign the group id after the assignment
2. Make sure it doesn’t disrupt accounting
and applications
GUMS service
• Use gatekeeper call-out to contact GUMS
directly
…
PHENIX
STAR
ATLAS
VO
VO
VO
VO
Grid
resource
Grid
resource
Grid
resource
GUMS
server
GUMS
DB
A client on the gatekeeper can contact GUMS to
retrieve the grid-mapfile or other maps.
No role-based authentication in that case.
Role based authorization
• Use of callout and of VOMS extended
proxy
/DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi
Grid
resource
BNL
GUMS
carcassi
/DC=org/DC=doegrids/OU=People/CN=Gabriele Carcassi
/VO=ATLAS/Group=USATLAS/Role=production-leader
Grid
resource
BNL
GUMS
usatlasprod
Components
• Gatekeeper call-out implementation (C client) –
Markus Lorch, Privilege Project
• GUMS GT3 service that implements callout
protocol – Java implementation over GT3
• GUMS service (WebService and UI interface for
admin commands) – Separate Java web
application, no GT3
• GUMS Admin – Command line client for
WebService door (Java)
• GUMS Host client – Command line client to
retrieve host maps (Java)
Components
Web
Browser
GUMS
Server
GUMS
Service
GUMS
GT3
Contact VO server
and refresh user lists
Retrieve map
for this host
Map this user
GUMS
Admin
GUMS
client
GK
Callout
GRID
Resource
Status
• GUMS components are essentially complete. Just needs
consolidation.
• Account pooling: at BNL we have a grid3dev gatekeeper
implementing account pools managed by GUMS (through gridmapfile) since the end of August. It’s suitable to test accounting and
applications. No tests have been yet performed so far.
• Role based authentication working on the testbed.
–
–
–
–
User retrieves VOMS extended proxy
Submits job to gatekeeper
Gatekeeper call-out contacts GUMS
GUMS returns local user (according to policy)
• Problems in using GT3 security within the C client (gatekeeper callout) – not a major issue as we can always use plain web services
• Implementation for storage callout hasn’t started yet
Security
• We performed a set of tests to compare GT3 message
level security and EGEE (glite) transport level security
(plain WS)
– req/sec was 17 times better with transport level security
• For the GUMS Admin Web Services interface, we are
using plain SOAP (Axis) with glite transport level
security.
• The Web UI also uses glite transport level security (web
interfaces can’t be used with message level security).
• The interface for the call-out is still targeted to GT3 with
message level security, but: problems in C client.
• What are other people doing?
Logs
• Not using GT3 logging: not flexible enough
– Hides the Log4j implementation, and doesn’t allow to use
Syslogd or Mail appenders to forward logs by mail or to syslogd
– Not usable for Web UI, which doesn’t use GT3
• Different logs for different audience
– Developer log: used for debugging, logs internals of the code.
– GUMS admin log: logs activity at the functionality level.
Complete log is saved to a file, error level entries are sent
through mail to the admin.
– CyberSecurity log: logs access (read at different level than
writes), uses syslogd to integrate with facility logging.
• For example, if ATLAS VOMS returns no members for a
group set in GUMS configuration, no problem at the
developer level, but very likely a problem at the admin
level.
Experience with GT3
• Performance problems in message level security
• Had to eliminate logging implementation
• Difficult to integrate:
– Configuration files are bundled in libraries, multiple
axis libraries when accessing web services
• Build-process from the tutorial is suitable only for
the tutorial (no other examples)
• Spreads files in various tomcat directories
(probable legacy from httpg)
Clustering
• We are investigating clustering to provide
high availability with GUMS.
– Tomcat 5 includes a load balancer.
– We are also investigating fail-over
mechanisms.
• Still in investigation phase.
Other issues
• Packaging for OSG
– How should the service be packaged? Which
type of package, PACMAN?
• Interaction with accounting service