received one) to belong to inactive
branches, hence ignore them even for update of job state attributes.
+\subsubsection{\LB data protection}
+Events passed between the \LB components as well as the results of their
+processing provide detailed information about the corresponding job and its
+life and users obviously expect the job data provided by the \LB server to
+be credible, reflecting the real jobs' operation on the Grid. Therefore, the
+data must be based solely on authentic information generated by legitimate
+grid components. The job data also provides information about user's
+activities, which many users want to keep private. In order to provide a
+sufficient level of security, the \LB infrastructure implements a security
+mechanism that provides data protection and access control to the data.
+
+All the \LB components communicate solely over secure channels whenever they
+send data over a network. The TLS protocol~\cite{tls} is used for both mutual
+authentication of the client and server and also encryption of the
+communication. All the \LB components as well as the clients must possess a
+digital certificate that they use to prove their identity. The \LB
+infrastructure supports both standard X.509 certificates or proxy
+certificates~\cite{proxycert} that are standard authentication mechanism in
+the gLite environment. Depending on the server configuration and action
+requested, the users may be required to present VOMS attributes in their
+proxy certificates.
+
+By default, access to information about a job is only allowed to the user
+who submitted the job (\ie the job owner). The job owner can also assign an
+access control list to his or job in the \LB specifying other users who are
+allowed to read the data from \LB. The ACLs are internally represented in
+the GridSite GACL format~\cite{gacl2} and are stored in the \LB
+database along with the job information. The stored ACL are checked on each
+query requesting the data. The ACLs are under control of the job owner, who
+can add and remove entries in the ACL arbitrarily using the \LB API or
+command-line tools. Each entry of an ACL can specify either a user subject
+name or a name of a VOMS group.
+
+Besides of using the ACLs, the \LB administrator can also specify a~set of
+privileged users with access to all job records on a particular \LB server
+(\emph{super-users}). These privileged users can \eg collect information on
+usage and produce monitoring data based on the \LB information.
+
+%Data trustworthiness - the events aren't signed, no real non-reputability or
+%traceability of the event sources.
+
+
\subsection{User interaction}
\begin{figure}
\centering
\end{itemize}
-\subsection{Security issues}
-The events passed between the \LB components as well as the results of
-their processing provide detailed information about the corresponding job and
-its life. Being used by the users to check status of their jobs and also by
-other Grid components to control the job, the information on jobs has to be
-reliable and reflect the real jobs' utilization of the Grid. Also, some user
-communities (\eg biomedicine researchers) often process sensitive data and
-require the information about their processing is kept private so that only the
-job owner can access not only the result of the computation but also all
-information about the job run. Last but not least, according to legislation of
-some countries the information on users' jobs can be treated as the user
-private data, which requires an increased level of protection. \LB therefore
-must pay special attention to security aspects and access control to the data.
-
-All \LB components communicate solely over authenticated channels. The TLS
-protocol~\cite{tls} is used as the authentication mechanism and each of the
-\LB uses an X.509 public key certificate to establish a mutually
-authenticated connection. The users usually use their proxy
-certificates~\cite{proxycert} when accessing the \LB server and retrieving
-information about jobs.
-\ludek{Proxy certificates were introduced by the Grid Security
-Infrastructure\~cite{gsi} from the Globus project and extend the concepts of
-standard public key certificates and identity providers and allows a user to
-issue a certificate for herself. Such a proxy certificate is used as a means
-for Single Sign-On and rights delegation~\cite{delegation}.}
-The proxy
-certificate can also contain other information necessary to create a secure
-connection, \eg information used for authorization. The \LB security layer is
-implemented using the the Generic Security Service API~\cite{gssapi}, which
-makes it easier to port the application to an environment using mechanism other
-than PKI (\eg Kerberos).
-
-Apart from providing an authentication mechanism, the TLS protocol also allows
-the communicating parties to exchange an encryption key that is used to encrypt
-all subsequent communication. The \LB components encrypt all network
-communication to keep the messages private. Therefore, together with the access control
-rules implemented by the \LB server, the infrastructure provides very high
-level of privacy protection.
-
-By default, access to a job information is only allowed to the user who
-submitted the job (the job owner). The job owner can also assign an access
-control list to her job in the \LB specifying other users who are allowed
-to read the
-data from \LB. The ACLs are represented in the GridSite GACL
-format~\cite{gacl1,gacl2}, which is a simplified version of common Extensible
-Access Control Markup Language (XACML)~\cite{xacml}. The ACLs are stored in
-the \LB database along with the job information and are checked at each access to
-the data. The GridSite XML policy engine is used for policy evaluation. The
-ACLs are under control of the job owner, who can add and remove entries in the
-ACL arbitrarily using the \LB API or command-line tools. Each entry of an ACL
-can specify either a user subject name or a name of a VOMS group. The
-VOMS~\cite{voms2} is a VO attribute provider service, which is maintained
-by the EGEE project. It allows to assign a user with groups and roles
-membership and issues to the users attribute certificates containing
-information about their current attributes. These attribute certificate are
-embedded in the user proxy certificate and checked by the \LB server at each
-user request handling.
-
-%Only the Read semantics is implemented so far, for the
-%future we consider more complex access control, \eg implementing the access
-%control for Write operations (per event) so that particular events could be
-%only logged by allowed components. That would allow to generate more
-%trusted results since currently each components can log arbitrary events.
-%Malicious component can make the \LB server produce inappropriate results.
-
-Besides of using the ACLs, the \LB administrator can also specify a~set of
-privileged users with access to all job records on a particular \LB
-server. These privileged users can \eg
-collect information on usage and produce a monitoring data based on the \LB
-information.
-
-%Data trustworthiness - the events aren't signed, no real non-reputability or
-%traceability of the event sources.
-
-Since the hostname of the \LB server is part of the job identification, it is
-easy for the user to check that the correct \LB server was contacted and no
-server spoofing took place and thus the data received from the server can be
-trusted. The \LB server on the other hand has no means of checking that the
-logged events originated from an authorized component. Everyone on the Grid
-possessing a valid certificate from a~trusted CA can send an event to the \LB and
-let it store and process the event and possibly change the status of the
-corresponding job. This way a malicious user or service can confuse the \LB
-server by a forged events. This behavior is not a critical issue in the current
-model and the way in which \LB is used, however, we are designing a solution
-addressing this weakness. We plan to use the VOMS attributes issued to a
-selected components. These VOMS attributes must be presented when critical
-events are logged to the \LB server.
-
\ludek{\subsection{Performance and scalability}
The \LB service was designed with performance and
scalability issues in mind. We have developed a series of tests of the
git://scientific.zcu.cz / jra1mw.git / commitdiff