From 5f334dd7e8809b980323b81247369b7dad7d8dd6 Mon Sep 17 00:00:00 2001 From: =?utf8?q?Daniel=20Kou=C5=99il?= Date: Wed, 7 Apr 2010 19:34:33 +0000 Subject: [PATCH] Description of the new authorization functions --- org.glite.lb.doc/src/LBAG-Installation.tex | 141 ++++++++++++++++++++++------- org.glite.lb.doc/src/LBAG-Running.tex | 5 +- org.glite.lb.doc/src/definitions.tex | 1 + org.glite.lb.doc/src/lbjp.bib | 2 +- 4 files changed, 113 insertions(+), 36 deletions(-) diff --git a/org.glite.lb.doc/src/LBAG-Installation.tex b/org.glite.lb.doc/src/LBAG-Installation.tex index 7e61a5e..82e899a 100644 --- a/org.glite.lb.doc/src/LBAG-Installation.tex +++ b/org.glite.lb.doc/src/LBAG-Installation.tex @@ -294,44 +294,119 @@ See Section~\ref{maintain:index} for instructions on changing \LB server index configuration afterwards in order to meet specific needs. +\subsubsection{Authorization policy} +\label{inst:authz} +Certain operations on the \LB server are considered privileged and +special authorization is required to invoke them. For example, a privileged +user can access data about jobs owned by other users, bypassing the default +\LB access control mechanism. \LBver{2.1} specifies several categories of +rights that can be granted to the users: + +\begin{itemize} +\item \verb'ADMIN_ACCESS' +\item \verb'STATUS_FOR_MONITORING' +\item \verb'GET_STATISTICS' +\item \verb'REGISTER_JOBS' +\item \verb'LOG_WMS_EVENTS' +\item \verb'LOG_CE_EVENTS' +\item \verb'LOG_GENERAL_EVENTS' +\end{itemize} + +While the first three categories concern with acquring data from the \LB +server, the other ones make it possible to define a web of trusted sources +passing events to the \LB server. + +\verb'ADMIN_ACCESS' is the most powefull privilege allowing to bypass any +authorization controls on the server. It replaces the superuser role, which +existed in \LBver{2.0} and older. Note, that the \verb'--super-users' +command-line option still exists and translates internally into granting +\verb'ADMIN_ACCESS'. + +When granted to a user, the \verb'STATUS_FOR_MONITORING' right allows the user to +query statuses of all jobs maintaned by the server, however only a small +subset of the status fields is returned to back. For example, the caller +does not obtain the identity of the job owner. The purpose of this right is +to provide a way to collect information necessary for overall monitoring +while preserving a basic level of privacy. + +\verb'GET_STATISTICS' allows its bearers to query for on-line statitistics +generated by the \LB server. See~\ref{maintain:statistics} for more +information about the purpose of the function. -\subsubsection{Server superusers} -\label{inst:superusers} - -Certain administrative operations (identified below when appropriate) on \LB -server are privileged and special authorization is required to invoke them. -Privileged user can also access job data owned by other users, bypassing the -standard \LB access control mechanisms. By default, the \LB server identity -(X509 certificate subject name) is considered privileged. Additional -administrator identities can be specified in a \emph{superusers file}, -specified by the \verb'--super-users-file' server option. A client is granted -superuser privileges if they present credentials matching the superusers -specifications in the file. The file consists of one or more lines, each one -containing either a subject name or VOMS attribute(s) in the FQAN format (in -the latter case the line must start with \verb'FQAN:'). Note that VOMS anchors -must be configured properly on the \LB machine when FQANs are used. After -changing the file, the server has to be restarted. - -The default startup script checks for existence of -/opt/glite/etc/LB-super-users and uses it eventually. - -\subsubsection{Authorization of event originators} \LBver{1.x} allowed anyone possessing a trusted digital certificate to send an arbitrary event to the \LB server. While enabling an easy setup, such an arrangement does not comply with some contemporary requirements, \eg job traceability, since the data could be distorted by a malicious user. In order -to strengthen trustworthiness of data provided, the \LBver{2.0} server has -introduced an authorization mechanism to control the originators of events. -The authorization model presumes a set of trusted components that are only -allowed to send some types of events, while other types can be logged by any -user. Being based on the LCAS schema~\cite{lcas}, the authorization mechanism -allows to make use standard LCAS plugins, \eg to ban particular users or limit -the service to a specific virtual organization. The \LB server is shipped with -an LCAS plugin providing more fine-grained access control based on event types. - -The LCAS-based authorization must be enabled in the \LB configuration. - -\TODO{policy format} +to strengthen the trustworthiness of the data provided, the \LBver{2.1} +server has introduced an authorization mechanism to control the originators +of events. The authorization model presumes a set of trusted components +that are only allowed to send ``important'' events, while other types can be +logged from any source. The \verb'REGISTER_JOBS' authorization category +specifies clients allowed to register jobs with the \LB server. The +\verb'LOG_CE_EVENTS' category makes it possible to define a set of trusted +CEs that are allowed to log events originating from within sites (in +particular \verb'RUNNING', \verb'REALLYRUNNING', and \verb'DONE'). +Similarly, the \verb'LOG_WMS_EVENTS' category defines a web of trusted WMS +nodes. The \verb'LOG_GENERAL_EVENTS' category comprises events that can be +sent from any place on the grid, namely \verb'CURDESC', \verb'USERTAG', and +\verb'CHANGEACL'. It is important to understand that these access control +rules provides additional level to the existing authorization routines. +Especially, being granted the \verb'LOG_GENERAL_EVENTS' right is not sufficient to +change ACLs on jobs of other people, etc. + +The \LB policy is specified in a policy configuration file that must be given +in the server configuration. The format of the policy is a subset of the +Simplified policy langauge introduced by the Argus gLite authorization +service\footnote{\url{https://twiki.cern.ch/twiki/bin/view/EGEE/SimplifiedPolicyLanguage}}. +Unlike the Argus language, the \LB policy supports only certificate subject +names and VOMS fully qualified attribute names (FQANs) to describe the users +and do not support 'deny'ing of rights. Also, general regular expressions +cannot be used in the argument, only the \verb'".*"' wild card is supported. An +example of the policy file follows: + +\begin{lstlisting} +resource "LB" { + action "ADMIN_ACCESS" { + rule permit { + subject = "/DC=cz/DC=cesnet-ca/O=CESNET/CN=Daniel Kouril" + } + rule permit { + fqan = "/vo/Role=Manager" + } + } + action "STATUS_FOR_MONITORING" { + rule permit { + fqan = "/vo/monitoring" + } + rule permit { + fqan = "/TEST/rtm" + } + } + action "LOG_WMS_EVENTS" { + rule permit { + subject = "/DC=cz/DC=cesnet-ca/O=CESNET/CN=wms01.cesnet.cz" + } + } + action "LOG_GENERAL_EVENTS" { + rule permit { + subject = ".*" + } + } + action "REGISTER_JOBS" { + rule permit { + subject = ".*" + } + } +} +\end{lstlisting} + +After changing the file, the server has to be restarted. + +In order to provide yet additional level of authorization, the LCAS +schema\cite{lcas} is still used in the server. If enabled in configuration, +it can be used to specify more general settings using the standard LCAS +modules and e.g. blacklist particular users. The standard LCAS documentation +should be followed to set up the LCAS layer properly. % \subsubsection{Notification delivery}\TODO{co tu ma byt?} diff --git a/org.glite.lb.doc/src/LBAG-Running.tex b/org.glite.lb.doc/src/LBAG-Running.tex index cec19ac..550fdb8 100644 --- a/org.glite.lb.doc/src/LBAG-Running.tex +++ b/org.glite.lb.doc/src/LBAG-Running.tex @@ -198,7 +198,7 @@ and the server started up. Then the dump files can be loaded back with complementary \verb'glite-lb-load' utility. -Server superuser privileges (see section~\ref{inst:superusers}) are required to run \verb'glite-lb-dump' and \verb'glite-lb-load'. +Server privileges granting \verb'ADMIN_ACCESS' (see section~\ref{inst:authz}) are required to run \verb'glite-lb-dump' and \verb'glite-lb-load'. Dumping the events does not interfere with normal server operation. This backup strategy can interfere with too aggressive setting of old @@ -246,7 +246,7 @@ It is recommended (and the default YAIM setup does so, via the \verb'glite-lb-export.sh' wrapper) to run the purge command periodically from cron. -Server superuser privileges (see section~\ref{inst:superusers}) are required to run \verb'glite-lb-purge'. +Server privileges granting \verb'ADMIN_ACCESS' (see section~\ref{inst:authz}) are required to run \verb'glite-lb-purge'. If the server database has already grown huge, the purge operation can take rather long and hit the \LB server operation timeout. At client side, \ie the @@ -339,6 +339,7 @@ wiki page: \url{http://egee.cesnet.cz/mediawiki/index.php/LB_purge_and_export_to_JP}. \subsubsection{On-line monitoring and statistics} +\label{maintain:statistics} \paragraph{CE reputability rank} diff --git a/org.glite.lb.doc/src/definitions.tex b/org.glite.lb.doc/src/definitions.tex index 9369125..fdca0d7 100644 --- a/org.glite.lb.doc/src/definitions.tex +++ b/org.glite.lb.doc/src/definitions.tex @@ -18,6 +18,7 @@ \usepackage{xspace} \usepackage{ifthen} \usepackage{comment} +\usepackage{listings} % useful definitions \def\LB{L\&B\xspace} diff --git a/org.glite.lb.doc/src/lbjp.bib b/org.glite.lb.doc/src/lbjp.bib index 37accd2..f92fa1b 100644 --- a/org.glite.lb.doc/src/lbjp.bib +++ b/org.glite.lb.doc/src/lbjp.bib @@ -775,6 +775,6 @@ Applications Workshops (AINAW'07)", @Misc{ lcas, title = "{Site Authorisation and Enforcement Services: LCAS, LCMAPS, and gLExec}", - howpublished = "\url{http://www.nikhef.nl/grid/lcaslcmaps/}", + howpublished = "\url{https://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/LCAS}", } -- 1.8.2.3