Makes CTA Front End Auth doc more understandable

doc/latex/CTA_Admin_Install.tex

@@ -287,12 +287,30 @@ Create the CTA user:
 \begin{lstlisting}
 # useradd cta
 \end{lstlisting}
+The CTA Front End requires both Kerberos and SSS authentication: Kerberos is used to authenticate user archive\slash
+retrieve commands and admin commands. SSS is used to authenticate communication between the Front End and CTA/EOS
+\texttt{mgm}.
 
-\subsection{CTA Front End Authentication}
+\subsection{CTA Front End Kerberos Authentication}
 
-CTA will receive archive and retrieve requests from multiple EOS instances, one per User (Atlas, CMS, etc.) There will
-be a Simple Shared Secret (SSS) key for each EOS instance\footnote{In principle, each instance can have a unique key. In
-practice, it may be that all instances use the same key.}
+CTA uses one of the Kerberos keys from \texttt{/etc/krb5.keytab}. If this file does not exist, see
+Appendix~\ref{install_eos_create_kerberos_keytab} for details of how to create it. This file should be copied to the CTA
+Front End keytab which should be owned by the user\slash group which will run the CTA Front End XRoot daemon:
+\begin{lstlisting}
+# cd /etc
+# cp krb5.keytab krb5.keytab.cta
+# chown cta:cta krb5.keytab.cta
+\end{lstlisting}
+Check the contents of the new keytab:
+\begin{lstlisting}
+# echo -e "read_kt krb5.keytab.cta\nlist\nquit" | ktutil
+\end{lstlisting}
+
+\subsection{CTA Front End SSS Authentication}
+
+There will be one EOS instance per User (Atlas, CMS, etc.), each of which can send archive and retrieve requests to the
+CTA Front End. Each EOS instance should have its own Simple Shared Secret (SSS) key\footnote{In principle, each instance
+should have a unique key. In practice, it may be that all instances share the same key.}.
 
 The EOS instance name is used as the user name for the SSS key. In the case of a local EOS instance (See
 Appendix~\ref{install_eos}), this can be found in the \texttt{eos\_env} configuration file:
@@ -316,12 +334,12 @@ applied to, overriding the default \texttt{nobody/nogroup}.
 
 If the keyname ends with \texttt{+}, SSS tokens may be forwarded when encrypted by the associated key, i.e. the key can
 be used by a different host from the one that encrypted the SSS token. This is required in certain situations, for
-example when tunnelling through a NAT device and---notably---when creating keys for use in the Kubernetes environment.
+example when tunnelling through a NAT device or when creating keys for use in the Kubernetes environment.
 
 In production, the \texttt{+} should be omitted, as forwardable keys are inherently less secure. Allowing forwarded
 tokens makes it impossible to detect man-in-the-middle attacks or stolen SSS tokens.
 \end{alertbox}
-The SSS key that we have just created also needs to be available to the EOS client, so we can copy the server keytab
+The SSS key that we have just created also needs to be available to the EOS client, so we copy the server keytab
 into the client keytab:
 \begin{lstlisting}
 # cp ctafrontend_server_sss.keytab ctafrontend_client_sss.keytab
@@ -329,15 +347,13 @@ into the client keytab:
 # chown cta ctafrontend_client_sss.keytab
 \end{lstlisting}
 \begin{alertbox}
-In principle there can be one key per EOS instance, so it is possible that \texttt{ctafrontend\_client\_sss.keytab}
-contains more than one key\footnote{In practice, it may be that all EOS instances share the same key.}. However, the
-XRoot client always uses the last key added the keytab, so the entire keytab can be safely copied to the client so
-long as the correct key for that instance is the last one that was added.
+As mentioned above, in principle there should be one key per EOS instance, so \texttt{ctafrontend\_client\_sss.keytab}
+may contain more than one key. However, as the XRoot client only uses the \textbf{last} key added the keytab, the entire
+keytab can be safely copied to the client (so long as the key for that instance is the last one that was added).
 \end{alertbox}
 
-\noindent The CTA Front End needs both Kerberos and SSS authentication. Kerberos is used to authenticate user
-archive/retrieve commands and admin commands to the Front End. SSS is used to authenticate communication between
-the Front End and CTA/EOS \texttt{mgm}.
+\subsection{CTA Front End XRoot Configuration}
+
 Edit \texttt{/etc/xrootd/xrootd-cta.cfg} and ensure that both Kerberos and SSS are enabled and using the correct keys.
 This is specified using the \texttt{sec.protocol} and \texttt{sec.protbind} configuration lines. The file should finish
 looking something like this:
@@ -366,18 +382,6 @@ xrootd.async off
 # Use a port other than 1094, already used by EOS xroot server
 xrd.port 10955
 \end{lstlisting}
-\texttt{/etc/krb5.keytab.cta} is a copy of \texttt{/etc/krb5.keytab} (If this file does not exist, see
-Appendix~\ref{install_eos_create_kerberos_keytab} for details of how to create it). It must be owned by the user/group
-which will run the CTA Front End XRoot daemon.
-
-It should be created as follows:
-\begin{lstlisting}
-# cd /etc
-# rm -f krb5.keytab.cta
-# cp krb5.keytab krb5.keytab.cta
-# chown cta:cta krb5.keytab.cta
-# echo -e "read_kt krb5.keytab.cta\nlist\nquit" | ktutil
-\end{lstlisting}
 
 \begin{alertbox}
 Why do we have some XRoot configuration files under \texttt{/etc/xrd.cf.<daemon>} and some under \texttt{/etc/xrootd/<daemon>.cfg}?