Security, Identification and Authentication¶

As CTA has access to every EOS instance, it must prevent crosstalk between EOS instances belonging to different VOs. This is achieved by applying the least privilege principle, i.e. the ATLAS EOS instance should not be able to access (or even know about) files belonging to CMS.

The EOS--CTA Protocol Buffer identifies the instance sending the Request. The CTA Frontend must also be able to authenticate that the instance name is legitimate.

Simple Shared Secrets¶

XRootD uses Simple Shared Secrets (SSS) to authenticate Protocol Buffer requests. In order to authenticate the instance name, there must be a unique SSS key for each VO.

The EOS team say that the following SSS keys are in use:

Number Len Date/Time Created Expires  Keyname   User & Group
------ --- --------- ------- -------- -------   ------------
2      32  02/10/12 17:34:12 -------- eosalice  daemon daemon
2      32  12/10/10 15:22:01 -------- eoscms    daemon daemon
1      32  06/25/12 15:42:16 -------- eoslhcb   daemon daemon
1      32  02/14/13 16:20:06 -------- eospublic daemon daemon
3      32  10/06/14 12:04:59 -------- eosuser   daemon daemon

XRootD allows us to detect the user name of the key but not the keyname, and currently all key user names are set to the same value (daemon). However, when the key is communicated from client to server, only the key value is sent across the wire. The value for the u: (user) field is read from the keytab on the server side.

Therefore, the solution to the problem of using the SSS key to validate the instance name in the Protocol Buffer is simply to edit the u: field for all keys in the CTA Frontend keytab so that they match the expected instance names. This also needs to be implemented in the Frontend:

Determine EOS instance name from both the CTA frontend SSS keytab and the notification.instance().name() protocol buffer field

The u: field from the keytab is passed as a parameter to Service::ProcessRequest(). The g:~(group) field does not appear to be used. n:~(keyname) is a unique identifier within the keytab and appears to be used for key management only.

SSS key conflict resolution should be key-name based and not creation-date based

There is an XRootD bug affecting the generation of unique keys: if the keys are created within the same second, XRoot treats them as different versions of the same key. The workaround is to have at least a two-second delay between generating each key, so this is not really an issue in production.

Access Rules¶

Info

Redundant Rules?

The struck through rules below are probably not required.

A listStorageClass command should return the list of storage classes belonging to the instance from where the command was executed only

A queueArchive command should be authorized only if:

the instance provided in the command line coincides with the instance from where the command was executed
the storage class provided in the command line belongs to the instance from where the command was executed
~~the EOS username and/or group (of the original archive requester) provided in the command line belongs to the instance from where the command was executed<\del>~~

A queueRetrieve command should be authorized only if:

the instance of the requested file coincides with the instance from where the command was executed
~~the EOS username and/or group (of the original retrieve requester) provided in the command line belongs to the instance from where the command was executed<\del>~~

A deleteArchive command should be authorized only if:

the instance of the file to be deleted coincides with the instance from where the command was executed
~~the EOS username and/or group (of the original delete requester) provided in the command line belongs to the instance from where the command was executed<\del>~~

A cancelRetrieve command should be authorized only if:

the instance of the file to be canceled coincides with the instance from where the command was executed
~~the EOS username and/or group (of the original cancel requester) provided in the command line belongs to the instance from where the command was executed<\del>~~

An updateFileStorageClass command should be authorized only if:

the instance of the file to be updated coincides with the instance from where the command was executed
the storage class provided in the command line belongs to the instance from where the command was executed
~~the EOS username and/or group (of the original update requester) provided in the command line belongs to the instance from where the command was executed<\del>~~

An updateFileInfo command should be authorized only if:

the instance of the file to be updated coincides with the instance from where the command was executed