Skip to content
Snippets Groups Projects
Commit 60761cdc authored by Michael Davis's avatar Michael Davis
Browse files

Adds SSS and Kerberos use cases to main CTA doc

parent ffbbbd94
No related branches found
No related tags found
No related merge requests found
No preview for this file type
......@@ -51,7 +51,7 @@
\input{cta_TapeSessions.tex}
\input{cta_ObjectStore.tex}
\input{cta_CTA-EOS_ReconciliationStrategy.tex}
\input{cta_EOS-CTA_Authorization.tex}
\input{cta_Authorization.tex}
\input{cta_TODO.tex}
\appendix
......
\chapter{EOS-CTA Authorization Rules}
\chapter{CTA Authorization}
\section{\glspl{sss}}
\glspl{sss} are used to authenticate communications using the XRoot protocol, which is the case in the following
situations:
\begin{enumerate}
\item Internal communication between the EOS \texttt{mgm} and \texttt{fst} daemons.
\item Communication between the Tape Server and the EOS \texttt{mgm} daemon. (On the other hand, communication between
the Tape Server and the EOS \texttt{fst} daemon does not use SSS; this is handled by internal redirection within the
XRoot library layer.)
\item Communication between the EOS \texttt{mgm} daemon and the CTA Front End daemon.
\end{enumerate}
\section{Kerberos}
Kerberos authentication is used in the following situations:
\begin{enumerate}
\item Communication between the CTA Admin tool and the CTA Front End daemon. In this case, Kerberos is the only available
authentication mechanism.
\item Communication between EOS users (Atlas, CMS, etc.) and the EOS \texttt{mgm} daemon. In this case, Kerberos is one
of several options. Authentication can be performed by any mechanism which is supported by both XRoot and EOS, for
example SSS or standard UNIX authentication.
\end{enumerate}
\section{EOS-CTA Authorization Rules}
One of the requirements of CTA is to prevent crosstalk between EOS instances belonging to different \glspl{vo}, e.g.
the ATLAS EOS instance should not be able to access (or even know about) files belonging to CMS.
......@@ -7,7 +32,6 @@ the ATLAS EOS instance should not be able to access (or even know about) files b
Should we have a different shared secret for each VO, to explicitly prohibit access to files not belonging to that EOS
instance?
\end{alertbox}
\begin{alertbox}[Redundant Rules?]
The highlighted rules below are probably not required.
\end{alertbox}
......
......@@ -3,6 +3,7 @@
\newacronym{cta}{CTA}{CERN Tape Archive}
\newacronym{castor}{CASTOR}{CERN Advanced STORage Manager}
\newacronym{hsm}{HSM}{Hierarchical Storage Management}
\newacronym{sss}{SSS}{Simple Shared Secret}
\setacronymstyle{long-short-desc}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment