Castor Security Overview

The goal of this project is to provide

• Authentication and Authorization on all client protocols
• Authentication and Authorization on administrative services
• Authentication and Authorization among back-end service

Legend: Not working , Tested , Built

See the details!

User Guide

See CastorSecureUserGuide

Deployment

See CastorSecurityDeployment

Trouble-Shooting

See CastorSecureTroubleShooting

Roadmap

In the first phase we are focusing on the client protocols:

• interaction with the Request Handler (RH) to open a file BUG:46754
• Name Server (NS) connections BUG:46736
• interaction with the Disk Server via rfio BUG:46755

The authentication of these protocols will be provided for

• GSI (X509 grid certificates): to be compatible with the WLCG grid services
• KerberosV: every CERN user has a Kerberos principal and the authentication is faster, uses less CPU resources

We are also looking after providing consistent behavior on other protocols:

• SRM: GSI authentication
• gridftp: GSI authenticaiton
• xrootd: both GSI and KerberosV authentication

Authentication and Mapping

The authenticated client will be mapped into a uid/gid pair, which correspond to a real CERN user and group. We cannot use virtualized users and groups because of the Castor scheduler BUG:46759

Kerberos

The mapping from Kerberos principals to CERN uid is straightforward: there is a username corresponding to each principal for which there is a unique uid provided by the CERN user database.

Certificates

Currently we are generating a static gridmap-file for certificate based authentication in SRM and gridftp services from the content of VOMS database.

However automatic mapping of CERN X509 certificates would also straightforward like Kerberos: the username is included in the certificate distinguished name (DN) for which there is a unique uid provided by the CERN user database BUG:46757.

Mapping external certificates is slightly more complicated, however the CERN CA provides a possibility to external users to register their certificates with a CERN user account. From this database we can generate a gridmap-file, which can be used by the GSI based authentication modules (RH, NS, rfio, SRM, xrootd) to map to a unique uid. BUG:46758

Groups

The authorization will only be based on the primary group of the user, as we have to use the CERN user database to assign a group (the primary one) to each uid.

In GSI in combination with VOMS we could also associate multiple groups or dynamically replace the primary group based on the user's request. However we cannot yet pass this information through the current request handling infrastructure, so we will only support single group in the first stage. This is a limitation, which we might remove later BUG:46762.

Deployment Plans

We plan to deploy the secure services in parallel to the insecure endpoints for a transitional period and then gradually close insecure access as the extra deployment requirements for authentication become clear.

See also CastorSecurityDeployment for more details!

Status

The Request Handler, Name Server and rfio calls are secured via GSI and KerberosV, however there are some unexpected problems:

• The SLC4 Kerberos library (version 1.3.4) is not thread safe, so the multi-threaded Request Handler and Name Server is failing. We have tried to put locking around the Kerberos library calls, however it has degraded the performance of the GSI server as well to the level of a single-threaded server, thus we have abandoned the idea. The solution is to upgrade to SLC5, which has a thread-safe version of the Kerberos library.

• The MIT KerberosV replay cache uses fsync() calls after each change, which significantly degrades the performance of a multi-threaded server. We can disable this feature, to speed up request handling, in exchange for a potential vulnerability window of replay attacks. The other alternative is to implement an alternative replay cache for the Kerberos library. See more at KerberosReplayCachePerfomance.

The SRM service uses GSI since the beginning, mapping the users via the gridmap-file to uid/gid pairs.

The xrootd service is able to handle both KerberosV and GSI authentication with the above mentioned limitations.

You can also track the status of individual items as Castor security bugs in Savannah.

Tests

See CastorSecureTests

Documents and Presentations

• Presentation of the plans to FIO in 2008 Castor Security Plans

Last edit: AkosFrohner on 2009-05-28 - 10:37