Skip to content

CTA Frontend#

The CTA frontend is responsible for serving two different types of requests:

  • Workflow events, responsible for faciliating things such as archival and retrival of files.
  • cta-admin commands, which can be used to perform various operations.

The frontend acts as the public interface to CTA.

CTA XRootD SSI Frontend#

The XrootD/SSI frontend uses the XrootD/SSI framework for client-server communication.

Per the XrootD/SSI documentation, some of the key concepts involved are the Service Provider, the Request and Response types.

Presently, the code for the XrootD SSI frontend is found in two places:

  1. the submodule xrootd-ssi-protobuf-interface
  2. the xroot_plugins directory in CTA

The xrootd-ssi-protobuf-interface submodule binds the google protobuf definitions to the XrootD/SSI Request and Response (Metadata) types. The xroot_plugins directory instantiates the Service Provider and also contains the request processing code.

For authentication, the XrootD/SSI frontend uses SSS (Simple Shared Secrets) to authenticate.

Request Processing#

The request processing flow is presented in the following diagram:

flowchart LR
   A["XrdSsiPbService::ProcessRequest()"]-.-> B["RequestProc<>::Execute()"]-.-> C["RequestProc<>::ExecuteAction()"]-.-> D["RequestMessage::process()"]-.-> E["WorkFlowEvent::process()"] & F["AdminCmd::process()"] & G["AdminCmdStream::process()"]

Physics workflow events#

The client (EOS) sends a request to the server (CTA) for each workflow event. Processing the request message is done by the process method of the RequestMessage class (defined in XrdSsiCtaRequestMessage) and handling of the request is done by the methods defined in the WorkFlowEvent class, which fill in the response: 

classDiagram
class WorkFlowEvent {
  - const eos::Notification m_event
  - SecurityIdentity m_cliIdentity
  - cta::Catalogue &m_catalogue
  - cta::Scheduler &m_scheduler
  + void processOPENW (xrd::Response &response)
  + void processCREATE (xrd::Response &response)
  + void processPREPARE (xrd::Response &response)
  + void processCLOSEW(xrd::Response &response)
  + void processABORT_PREPARE(xrd::Response &response)
  + void processDELETE(xrd::Response &response)
  + void processUPDATE_FID(xrd::Response &response)
}

CTA-Admin commands#

Processing the request message is done by the process method of the class AdminCmd in the case of non-streaming commands or the AdminCmdStream class in the case of streaming commands. Non-streaming admin commands are implemented as methods of the CtaAdmin class while streaming admin commands are implemented as methods of CtaAdminStream.

classDiagram
class AdminCmd {
  xrd::Response process()
  void processAdmin_Add(xrd::Response &response)
  void processAdmin_Ch(xrd::Response &response)
}

class AdminCmdStream {
  xrd::Response process()
  void processAdmin_Ls(xrd::Response &response)
  void processArchiveRoute_Ls(xrd::Response &response)
}

AdminCmd <|-- AdminCmdStream

CTA gRPC Frontend#

The gRPC frontend is mean to be the successor of the XRootD SSI frontend. It is currently undergoing development. The gRPC frontend uses Google's Remote Procedure Calls framework for client-server communication.

Currently the gRPC frontend only serves the physics workflow event requests. The admin commands implementations will be added soon. The gRPC methods wrap the corresponding WorkFlowEvent class methods, as shown in the table below.

gRPC method common method
CtaRpcImpl::Create() processCREATE()
CtaRpcImpl::Archive() processCLOSEW()
CtaRpcImpl::Delete() processDELETE()
CtaRpcImpl::Retrieve() processPREPARE()
CtaRpcImpl::CancelRetrieve processABORT_PREPARE()

Authentication#

The gRPC frontend supports JWT (JSON Web Token) authentication, using JWKS (JSON Web Key Set) for public key validation. The client submitting WFE requests with gRPC should attach the JWT token to the call credentials. In general, client authentication is expected to work as follows:

  1. Obtain JWT Token: Get a valid JWT token from your identity provider
  2. Include Authorization Header: Add token to gRPC metadata: 
    Authorization: Bearer <jwt-token>
  3. Make gRPC Calls: All workflow operations (Create, Archive, Retrieve, etc.)

For more details one can refer to the implementation of the EOS client.

Expected Token Format#

The tokens are expected to be valid JWTs.

Additionally, the subject field ("sub" claim) must contain the name of the disk instance from which the request was submitted.

Dependencies#

The implementation uses the jwt-cpp header-only library for JWT decoding, validation, and signature verification. The only supported algorithm is RS256 (RSA with SHA-256). The library is added as a git submodule at common/jwt-cpp

Also, for fetching JWKS from remote endpoints the CURL library is used.

Configuring JWT Authentication#

JWT authentication is configured through the cta-frontend-grpc.conf file:

Required Settings#

A TLS encrypted connection is required by the gRPC framework in order to be able to make requests with an attached token. If JWT authentication is specified in the configuration file but TLS is not, then the frontend will fail to start and print a corresponding explanatory error message.

# Enable TLS (required for JWT)
grpc.tls.enabled true
grpc.tls.cert_path /path/to/server.crt
grpc.tls.key_path /path/to/server.key

# Enable JWT Authentication
grpc.jwt.enabled true

# JWKS Endpoint
grpc.jwks.uri http://auth-keycloak:8080/realms/master/protocol/openid-connect/certs
Optional Cache Settings#

A cache for the public keys is maintained so that the public keys used to validate tokens do not have to be looked up for every request. There are two configuration parameters associated with the cache:

  • The refresh interval (in seconds). If omitted, the default value is 600 seconds.
  • The key timeout (in seconds). The default behavior, if this is not set in the configuration file, is to have no expiration for they keys. 
    # Cache refresh interval (default: 600 seconds)
grpc.jwks.cache.refresh_interval_secs 600

# Public key timeout (default: no expiration if not set)
grpc.jwks.cache.timeout_secs 3600