Authentication#
Globally, CTA supports multiple authentication methods: SSS (Simple Shared Secret), Kerberos, and JWT (JSON Web Token). In CTA we distinguish between three different catagories of authentication:
- The authentication between the disk buffer and the CTA frontend. The disk buffer will send workflow events to the frontend and needs to be authenticated in order to do so.
- The authentication between the tape servers and the disk buffer. The tape servers need to be able to read/write data from/to the Disk buffer directly.
- The authentication of users interacting with CTA via the
cta-admin
tool.
Authentication Methods by Interface#
XRootD/SSI Frontend#
The XRootD/SSI frontend uses SSS authentication for workflow events and Kerberos for admin commands.
gRPC Frontend#
The gRPC frontend supports JWT authentication for workflow events (see gRPC Frontend JWT Authentication). - The authentication of admin commands with the gRPC Frontend is currently a work in progress. The supported methods will be JWT and Kerberos.
Tape Servers#
The tape servers use SSS authentication when communicating with the disk buffer. In addition to the Kerberos authentication for the admin-client, the client is also expected to be registered in the Catalogue before they are authorized to execute commands. The primary motivation behind using SSS is that this is the authentication method of choice for the disk buffer we are currently using (EOS).
An overview of this can be seen in the diagram below:
flowchart TB
subgraph DISK BUFFER
disk["Disk Buffer"]
end
subgraph CLI
ctacli["CTA Admin Client"]
end
subgraph CTA
ssi-frontend["CTA XRootD/SSI Frontend"]
grpc-frontend["CTA gRPC Frontend"]
tpsrv["CTA Tape Server"]
end
disk -- SSS --> ssi-frontend
tpsrv -- SSS --> disk
ctacli -- KRB5 --> ssi-frontend
disk -- JWT ----> grpc-frontend