ViewVC logotype

Annotation of /trunk/grid-mw-security/ees/thesis/grid_auth.tex

Parent Directory Parent Directory | Revision Log Revision Log

Revision 946 - (hide annotations) (download) (as text)
Tue Oct 20 12:26:31 2009 UTC (12 years, 7 months ago) by aramv
File MIME type: text/x-latex
File size: 35856 byte(s)
Latest additions
1 aramv 943 \chapter{Grid computing \& Security}
2 aramv 671 % Authenticatie is gebaseerd op PKI
3     % Authorisatie is gebaseerd op DN's, VOMS
4     % Grid heeft dit en dat, maar onze basis is PKI.
5     % Authenticatie: persoonlijke certificaten, VOMS, SAML statements en
6 aramv 928 \section{Authentication \& authorization mechanisms}
7 aramv 943 Grid computing requires a mechanism to authorize users' access to Grid resources.
8     This authorization can be granted at different levels depending on different types of credentials supplied by - or associated with - the user and which service he or she tries to access.
9 aramv 671
10 aramv 943 \subsection{X.509 certificates}
11 aramv 787 The various Grid middleware stacks rely heavily on X.509 certificates \cite{rfc2459} as the 'lingua Franca' for authenticating users.
12 aramv 943 It's a personal public key certificate that can be traced back to the issuer, a \textit{Certificate Authority} (CA).
14     It contains:
15     \begin{itemize}
16     \item The subject \textit{Distinguished Name} (DN), which identifies the person, service or system that the certificate represents
17     \item The subject's public key
18     \item The identity of a CA that has signed the certificate, attesting to the authenticity of the subject DN and public key
19     \item The digital signature of the named CA
20     \end{itemize}
22 aramv 787 \glossary{name={CA}, description={Certificate Authority}}
23 aramv 943 \glossary{name={DN}, description={Distinguished Name}}
24     \glossary{name={GSI}, description={Grid Security Infrastructure}}
25 aramv 936 \glossary{name={SSO}, description={Single sign-on}}
26 aramv 787 \glossary{name={PKI}, description={Public Key Infrastructure}}
27 aramv 943
28     This creates a \textit{Public Key Infrastructure} (PKI) \cite{rfc3280} wherein the CA is trusted and can give users, systems and services access to Grid resources.
29     The \textit{Grid Security Infrastructure} (GSI) is a specification to support security between organisation boundaries, allow secure communication and enable "single sign-on" (SSO) solutions in Grid computing.
30     It can be used to enable a SSO solution through delegation of X.509 certificates.
32     The certificates used on Grid systems are \textit{Proxy Certificates} \cite{rfc3820} which are signed by the subject and are valid for shorter periods of time to diminish the value of stolen certificates.
33 aramv 936 These proxy certificates can be traced back to the user they belong to, providing end-to-end accountability.
34 aramv 671
35 aramv 943 % TODO ref GSI
37 aramv 936 % SSO, delegation -> trace
39 aramv 671 % VOMS doet registratie van gebruikers op basis van hun DN, groepsstructuur en rollen toekennen
40     % Signed attribute certificates uit te geven.
41     % FQANS zijn onderdeel van de VOMS attributes.
42 aramv 900 \subsection{Virtual Organizations}
43 aramv 787 Because of scalability issues Grid authentication is mostly based on group affiliation.
44     The group affiliations are expressed in several tiers, the most high level of which is a \textit{Virtual Organization} (VO).
45     \glossary{name={VO}, description={Virtual Organization}}
46 aramv 941 VOs appear to work like regular organizations, but are not explicitly connected by location, employer or other affiliation.
47     However they collaborate and present themselves as a unified organization, working towards a common goal
48 aramv 671
49 aramv 900 \subsubsection{Virtual Organization Management Service}
50 aramv 941 VOs can make use of a \textit{Virtual Organization Management Service} (VOMS) to manage and register their users.
51 aramv 787 \glossary{name={VOMS}, description={Virtual Organization Management Service}}
52 aramv 936 Users should apply to a VOMS with their Grid certificate, which must contain the name of the user in the certificate's Subject \textit{Distinguished Name} (DN).
53 aramv 671
54 aramv 787 Based on a user's Grid certificate credentials - specifically, the Subject DN - the VOMS service can give a user signed tokens to claim group membership when interacting with Grid services.
55     In this interaction the VOMS server acts as an \textit{Attribute Authority} (AA), which distributes signed attributes to the user in the form of an \textit{Attribute Certificate} (AC) \cite{rfc3281}.
56 aramv 936 The Attribute Certificate also specifies the group, subgroup, roles and capabilities of the holder.
57 aramv 787 \glossary{name={AA}, description={Attribute Authority}}
58     \glossary{name={AC}, description={Attribute Certificate}}
59 aramv 938 To create a VOMS AC, a VOMS service amends the user's proxy certificate with signed VOMS tokens, which include \textit{Fully Qualified Attribute Name}s (FQANs) \cite{fqan}.
60 aramv 787 \glossary{name={FQAN}, description={Fully Qualified Attribute Name}}
61 aramv 671
62 aramv 787 As an analogy, in this capacity the Grid certificate is like a passport that is used to obtain a membership card (AC) of a certain club (VO).
63     Once the identity of the holder has been verified, the membership card is all that is needed to access club facilities. Their identity can be established from these \textit{attribute credentials}.
65     A user can be authenticated to belong to a VO group by tracing this information back to a trusted VOMS server certificate (an \textit{Attribute Signing Certificate} \cite{rfc3281}), which has in turn been signed by a trusted CA.
66     Based on these signed attributes a user is authenticated to belong to a project group in a certain role.
67     This authentication solution requires the trusted VOMS server certificates to be available to all services that need to verify VOMS attributes.
69     %VOMS defines groups, roles and capabilities.
70     %These are completely independent of each other.
71     %Roles are meant to be global, associated directly with the AC holder, regardless of group membership.
72     %However, VOMS allows groups and roles to be bound together, using one as a qualifier for the other.
73     %While it is indeed possible to encode groups and roles inside the standard attributes in a format that could represent
74     %this information, there is no way to have the same format also be readable by other AC users without risking misunderstandings. \cite{ac-rfc}
76 aramv 900 \subsection{Pool accounts}
77 aramv 861 Pool accounts are part of a mechanism to map users' Grid certificate credentials to actual user accounts on compute clusters. \cite{gridmapdirsite}
78 aramv 936 These pool accounts are generic user accounts that are mapped to the remote user based on the credentials in their certificate.
79     The various sets of pool accounts are created by site administrators, which are then 'loaned' to users working in certain roles.
80 aramv 941 The pool accounts are not associated with a user in their initial setup.
81 aramv 936
82     When a pool account is in use, there is a strong link between the pool account and the user credentials that were mapped to it.
83     % pool accounts zijn niet geassocieerd met gebruiker totdat die is langsgekomen/gemapped
84     % gebruikers zijn op deze manier sterk verbonden met het UNIX account
85 aramv 861 %This facilitates late binding between users within a VO and the concrete UNIX accounts they use to do work on the Grid.
86     The role and associated capabilities a user takes on are determined by the signed VOMS attributes present in a user's proxy certificate. \cite{nikhefwebsite:gridwikiindex}
88 aramv 941 System administrators can disassociate pool accounts after a certain period of time, mostly due to inactivity of the user in the order of several weeks or months (depending on the site local policies).
89     The unassociated accounts are returned to the pool for reuse.
90 aramv 861
91 aramv 941
92 aramv 900 \subsection{Fully Qualified Attribute Names}
93 aramv 938 \textit{Fully Qualified Attribute Names} (FQANs) are explicit and unambiguous strings that can describe the group and subgroup a user is associated with.
94     These can be given out by a VOMS service through an Attribute Certificate.
95 aramv 936 Besides group affiliation, roles and capabilities can be attributed to the user.
96     By being affiliated with a certain group, a user can claim authorization at a grid service.
97 aramv 941 It is up to a service to take a local policy and the presented credentials into account, base authorization on them and allow a certain action.
98     The result can be different for every site and service type.
99     % TODO rewrite
101 aramv 936 %In VOMS AC's komen FQANS voor
102     %FQAN is 1 string die beschrijving geeft van de VO groepen, subgroepen, rollen en capabilities
103     % binnen iedere groep kun je aparte rollen aanwijzen
104     % als je die rollen bezit mag je de authorizatie claimen bij een service
105     % mag meer tekst bij
106 aramv 787
107 aramv 928 \begin{table}[h]
108 aramv 671 \begin{center}
109 aramv 936 \begin{tabular}{ | c | c | c | c | }
110 aramv 671 \hline
111 aramv 936 VO & group & subgroup & role \\
112 aramv 671 \hline
113 aramv 936 /fred.example.org & /production & /optimization & /Role=Admin \\
114 aramv 671 \hline
115     \end{tabular}
116     \end{center}
117 aramv 928 \caption[FQAN fields]{A table showing examples of the FQAN fields VO, group, subgroup, role and capability}
118     \end{table}
119 aramv 671
120     % Mensen moeten zich via email aanmelden bij de VOMS-server
121     % Alle grid services en VOMS servers hebben een push-model waarin je je certificate upload. De services moeten deze informatie verifieren.
123 aramv 787 %All Grid services have a push model that requires users to provide a certificate which is then verified by the service. This is done by tracing back the proxy certificate and all its signed credentials to the VOMS server certificate, and tracing the user certificate back to the issuing CA.
124 aramv 671
125 aramv 928 \pagebreak
127 aramv 900 \subsection{Grid credentials}
128 aramv 671 % Basis van de authenticatie is gebaseerd op de persoonlijke certificaten.
129     % Die zijn uitbreidbaar.
130     %
132 aramv 936 Multiple authentication mechanisms must be supported due to the scale and breadth of the Grid use cases.
133     Many different organizations worldwide develop Grid middleware, policies and infrastructure and each organization brings their own use cases, motivations and expertise to the table.
134     %breed -> veel verschillende groepen schrijven middleware en hebben ieder hun eigen use-cases te verwerken daarin EN diverse achtergronden en motivaties
135 aramv 671 % Bepaalde technieken, evolutie ervan, adoptie/penetratie van technieken die we hebben.
136     % Open standaarden die we zoveel mogelijk willen ondersteunen.
137     % SAML is heel nieuw, PKI bestaat al heel lang, en daarbij: proxy delegations.
138     % Door Delegation of credentials from your certificate to a WMS zodat die service functioneert als een agent.
139     % Alleen de private key van de delegation blijft over op de WMS. Je eigen private key van je op jouw naam staande certificate wordt niet overdragen aan de agent.
140     % Het proxy certificate is cryptografisch verbonden, omdat jij de signer bent.
141 aramv 938 Support for these mechanisms has evolved over the past decade, and gradually got more flexible.
142 aramv 671 % Het gebruik van de authenticatie technieken heeft relatie tot volwassenheid en evolutie van authenticatie technieken en de use cases (refereer naar delegation). Open standaarden zijn vereist.
144     % End-to-end security: dat je de chain van de worker node kunt terugleiden naar de persoon die de job submitte.
145     % Vanwege de schaalbaarheid maken we vooral authorisatie beslissingen op basis van groepen.
146     % Mensen die in die groep zitten worden impliciet vertrouwd.
147 aramv 787 % VOMS: Virtual Organization staat min of meer 1:1 tot een experiment of een project.
148 aramv 671 % Binnen de VO kennen we groepen, subgroepen en rollen. Aan ieder van deze kunnen personen worden toegewezen, en ook services en resources.
149     % Individu moet zich registeren bij een VO, en als je geregistreerd bent kun je gesignede tokens ophalen.
150     % User genereert een certificate en laat hem signen door een CA.
151     % User kan een proxy certificate maken van z'n user cert.
152     % Daarmee authenticeer je jezelfd bij de VOMS server (standaard mutual SSL authentication) en vraag je de groepen van jouw VO en evt. rollen.
153     % De server zoekt die credentials bij elkaar en signed ze met zijn private key. Vervolgens stuurt ie de gesignede blob (VOMS attribute Certificate of VOMS AC) terug naar de client.
154     % Nu ga je een nieuwe proxy delegation maken, en tijdens het signing request worden de VOMS AC embedded in de CSR als X.509v3 extensies.
155     % Dit geheel wordt nu gesigned als een reguliere met jouw eigen private key.
157     % VOMS AC's zijn gebaseerd op RFC 3281.
158     % Certificates waren gebaseerd op RFC 3280, maar nu is dat RFC 5280
160     % Nu heb je een VOMS-enabled certificate (VOMS proxy).
161     % Attributes in een VOMS proxy zijn:
162     % Van de VOMS server die signed: de URI, de DN, de signer van de DN.
163     % Dus je hebt twee dingen om te controleren: de cert van de VOMS (naar de CA) en de signer (ook CA) van de DN.
165     % IGTF is een samenwerking van 3 grote grid (igtf.net)
166     % PKI + personal certificates.
167     % Binnen de rest van VOMS certificate attributes heb je ook FQANS die vertellen welke groep en/of rol voor jou van toepassing is. Wordt ook gesigned door de VOMS service.
168     % (Dan heb je ook nog een name-value pair voor mogelijk extra attributen.)
171     % Nog 2 dingen die in je VOMS proxy kunnen zitten:
172     % Public key van de voms service.
173     % Serial number van jouw persoonlijke certificaat.
174     % Jouw subject DN.
177     % Zo is er een linkt te leggen tussen:
178     % Jouw subject DN, jouw CA, en jouw serial number van jouw certificaat.
179     % Zo ontstaat er een link tussen de persoon, de signature van de CA en het certificaat van de gebruiker. Dit gaat het stelen van voms-attributes tegen want voms attributes zitten als extensie in je proxy certificaat en dus hebben ze een sterke binding nodig met de eigenaar van het certificaat.
181     % VOMS AC
182     % DN, FQAN, CA, serial number, secret sauce.
183 aramv 787 Different types of credentials that can be used are:
184 aramv 928 \begin{description}
185     \item[Personal, host and service X.509 certificates] % Wie ben je
186 aramv 941 {The Subject \textit{Distinguished Name} (DN) is a field in an X.509 certificate.
187     It's composed of multiple RDNs.
188     %TODO reference RDN (rfc 2511)
189     This uniquely identifies a user, host or service through a Public Key Infrastructure (PKI) which includes identity vetting by a trusted third party.
190     The subject DN is mostly used in the OpenSSL oneline format.
191     Other less used formats are X.500 name (RFC 2253)
192     % TODO herschrijf
194     This uniquely identifies a user, host or service through a PKI infrastructure which includes identity-vetting by a trusted third party.
195 aramv 936 }
197     \item[VOMS attributes]{
198 aramv 942 The DN information is used to query a certain VOMS server associated with a project, which returns an \textit{Attribute Certificate} \cite{rfc3281} in which each field and the Attribute Certificate as a whole are signed by the VOMS server.
199 aramv 787 }
200 aramv 936
201 aramv 787 % Op basis van de info in het certificaat (je DN) en VOMS credentials (FQAN) worden user geauthoriseerd.
202     % (Wie ben je, voor welke groep werk je, wat is je rol).
204     %\item VOMS credentials (Fully Qualified Attribute Name) % Voor welke groep werk je en welke rol bekleed je
205     % Voorbeelden van VOMS rollen: VO-admins, software updaters / installateurs (Software area directories), production managers (verantwoordelijke voor het processen van de data en monte carlo productie).
206 aramv 928 \item[SAML statements] % Zie je terug in Shibolleth. Altijd terug te leiden naar X.509 certificates. Andere niet-standaard authenticatiemethoden. Komt meer uit de web-hoek.
207 aramv 787
208 aramv 938 {The \textit{Security Assessment Markup Language} \cite{saml} is an XML standard for exchanging authentication and authorization data between security domains.
209     Grid services try to translate SAML information back to an X.509 certificate, as it remains the 'lingua Franca'.
210 aramv 787 }
211     \glossary{name={SAML}, description={Security Assessment Markup Language}}
212     % Bedoeld om een claim te geven over identiteit
213     % These statements lead users back to a X.509 certificate.
214     % The standard was devised for interoperability between Single Sign-on solutions.}
215 aramv 936 % reference SSO
216     % reference SAML
217 aramv 787
218 aramv 928 \item[XACML queries] % Te maken met policies en queries op policies. Mag pietje puk gebruik maken van deze resource? XACML: Subject (aram + cert), Action (computing), Resource (storage), Environment (arbitraire omgevingsinformatie).
219 aramv 787
220 aramv 928 {The \textit{eXtensible Access Control Markup Language} (XACML) is a declarative access control policy language implemented in XML. \cite{xacml}
221 aramv 787 It can be used to define rules based on Subject, Action, Resource, and Environment values.
222 aramv 941 XACML is very expressive and therefore useful to create and evaluate complex authorization policies.
223 aramv 787 %\subsection{XACML fields}
224     \glossary{name={XACML}, description={eXtensible Access Control Markup Language}}
226 aramv 928
227     }
228 aramv 936 % reference XACML
229 aramv 928
230     \end{description}
232     \begin{table}[h]
233 aramv 787 \begin{center}
234     \begin{tabular}{ | c | c | c | c | }
235     \hline
236     Subject & Action & Resource & Environment \\
237     \hline
238     User Aram & wants cycles & on this server & which should run Linux \\
239     \hline
240     \end{tabular}
241     \end{center}
242 aramv 928 \caption[XACML concepts]{A table showing examples of the XACML concepts Subject, Action, Resource, and Environment}
243     \end{table}
244 aramv 787
246     %\section{XACML examples}
247     %Here's an example of how XACML requests can are used to represent Grid credentials.
248     %\subsection{Subject X.509 id}
249     %\begin{verbatim}
250     %<Attribute
251     %AttributeId="http://authz-interop.org/xacml/subject/subject-x509-id"
252     %DataType="http://www.w3.org/2001/XMLSchema#string">
253     %<AttributeValue>
254     %/O=dutchgrid/O=users/O=nikhef/CN=Oscar Koeroo
255     %</AttributeValue>
256     %</Attribute>
257     %\end{verbatim}
259     %\subsection{Subject X.500 issuer}
260     %\begin{verbatim}
261     %<Attribute
262     %AttributeId="http://authz-interop.org/xacml/subject/subject-x509-issuer"
263     %DataType="http://www.w3.org/2001/XMLSchema#string">
264     %<AttributeValue>
265     %/C=NL/O=NIKHEF/CN=NIKHEF medium-security certification auth
266     %</AttributeValue>
267     %</Attribute>
268     %\end{verbatim}
271     %\subsection{Subject VO}
272     %\begin{verbatim}
273     %<Attribute
274     %AttributeId="http://authz-interop.org/xacml/subject/vo"
275     %DataType="http://www.w3.org/2001/XMLSchema#string">
276     %<AttributeValue>gin.ggf.org</AttributeValue>
277     %</Attribute>
278     %\end{verbatim}
281 aramv 861 % PEPd -> Policy Enforcement Point daemon
282     % PDP -> Policy Decision Point
283     % PAP -> Policy Administration Point
284     % END USE CASES
285 aramv 900
286 aramv 928 \pagebreak
288 aramv 900 \section{Grid security middleware and services}
289 aramv 861 %\subsection{ADAM}
290     %% No longer used.
291     %ADAM stands for \textit{AmPS Data Analysis Method}, which as the name implies was first developed to process data generated by the AmPS \textit{Amsterdam Pulse Stretcher}.
292     %\glossary{name={ADAM}, description={AmPS Data Analysis Method}}
293     %\glossary{name={AmPS}, description={Amsterdam Pulse Stretcher}}
294     %It was not designed as a security middleware, but it does have a pluggable architecture to extend its functionality.
295     %The core component was a framework that got raw data as input from the detectors and used specific plug-ins to perform detector specific analysis. \cite{adampage}
297     \begin{figure}[hp]
298     \centering
299 aramv 671 \includegraphics[width=\textwidth]{scas}
300     \caption[SCAS diagram]%
301 aramv 861 {A diagram showing the architecture of a SCAS-based authenticating \& authorization installation}
302 aramv 671 \label{fig:scas}
303     \end{figure}
305 aramv 861 \subsection{gLExec}
306     %By the virtue of the pilot job framework use case a Worker Node has now become a new entry point to the cluster.
307 aramv 936 % reference naar suEXEC
308     gLExec is a pluggable suEXEC-like \cite{suexec} wrapper program that requests a mapping between Grid credentials and Unix user accounts and groups.
309 aramv 938 It can enforce this mapping to wrapped executables by modifying the \textit{uid} and \textit{gid}s of the executing process to the ones the user is mapped to, before passing execution to the wrapped binary.
310 aramv 900 gLExec will authenticate credentials using a callout to LCAS and LCMAPS.
311 aramv 907 It can act as both a light-weight 'gatekeeper' on the Compute Element or be used on the Worker Node for late-binding (pilot job) use cases. Please see appendix \ref{use_cases} for a description of possible use cases.
312 aramv 941 The callout to LCMAPS can procure a pool account by itself, but through the SCAS client in LCMAPS, a central mapping and authorization service like SCAS (or any interoperable SAML2XACML2 \cite{authzinterop} service) can be used. \cite{nikhefwebsite:gridwikiglexec}
313 aramv 787
314 aramv 671 \subsection{LCAS}
315     The \textit{Local Centre Authorization Service} (LCAS) makes binary ('yes' or 'no') authorization decisions at the site and resource level.
316 aramv 787 \glossary{name={LCAS}, description={Local Centre Authorization Service}}
317     %In making this decision it can use a variety of inputs, among which are:
318 aramv 671
319 aramv 787 %\begin{itemize}
320     %\item The 'Grid' name of the user. The user's X.509 certificate Subject, also known as the \textit{Distinguished Name} (DN)
321     %\item Any VO attributes the user has like VOMS \cite{vomssite} \textit{Fully Qualified Attribute Name}s (FQANs)
322     %\item The name of the executable the user intends to execute
323     %\end{itemize}
324 aramv 671
325     It supports basic black and white list functionality, but also more complex VOMS-based expressions, based on the GACL \cite{gaclsite:home} language.
326 aramv 787 The framework fetches data, stores it, and through static means offers structures to plug-ins that contain the following values:
328 aramv 671 \begin{itemize}
329 aramv 928 \item X.509 certificate chain string (in PEM \cite{rfc1421} format) \cite{rfc2459}
330 aramv 671 \item \textit{Resource Specification Language} (RSL) string \cite{globus-rsl}
331     \item \textit{Distinguished Name} (DN) string \cite{rfc5280}
332     \item Globus GSS Credential structure \cite{rfc2743}
333     \end{itemize}
334 aramv 787 \glossary{name={RSL}, description={Resource Specification Language}}
335 aramv 928 \glossary{name={PEM}, description={Privacy Enhanced Mail}}
336 aramv 787 \glossary{name={GACL}, description={Grid Access Control Library}}
337 aramv 671
338 aramv 928 \subsubsection{Plug-ins}
339     The plug-ins that LCAS executes must all exit successfully before authorization can continue. \cite{nikhefwebsite:gridwikiindex}
341     \begin{description}
342 aramv 936 %\item[Gridlist]{A plug-in that maps allowed users to pool accounts using the gridmapfile \cite{gridmapfile}}
343 aramv 946 \item[Timeslots]{A plug-in that makes authorization decisions based on the time of day a job request is received \cite{lcas_apidoc}}
344     \item[Userban]{A plug-in that checks a file that contains a list of Subject DNs of users to be banned from the site \cite{lcas_apidoc}}
345     \item[Userallow]{A plug-in that checks a file that contains a list of Subject DNs of users to be allowed to the site. \cite{lcas_apidoc}}
346 aramv 941 \item[Check executable]{A plug-in that checks if the executable requested is whitelisted by the service.}
347     % TODO reference Check executable
348     \item[LCAS VOMS]{Works like the userallow plug-in, except it verifies the FQANs present in a proxy certificate instead of the Subject DN. These were added to the certificate by a VOMS service. With this plug-in, more complex policies for authorization can also be expressed in the GACL \cite{gaclsite:home} language.}
349 aramv 928 \end{description}
351     \glossary{name={RSL}, description={Resource Specification Language}}
352     \glossary{name={GACL}, description={Grid Access Control Library}}
353 aramv 787 % i.e. the plug-ins must be true if logically AND-ed.
354 aramv 671
355     \subsection{LCMAPS}
356 aramv 787 %Unix (like) systems only understand Unix UID, GID and Secondary GID
357     %credentials. As the lingua Franca is X.509 (with VOMS credentials), these
358     %credentials will need to be translated to Unix credentials.
359     %Based on the Unix credentials, batch system schedulers can do their work as
360     %batch systems have never (yet) been Griddified to natively handle X.509
361     %and/or VOMS credentials.
362 aramv 671
363     LCMAPS is the \textit{Local Credential Mapping Service}.
364 aramv 787 \glossary{name={LCMAPS}, description={Local Credential Mapping Service}}
365 aramv 907 It takes care of translating Grid credentials to Unix credentials local to a Grid site.
366     It ensures that different individuals on the Grid maintain distinct, isolated Unix accounts using the pool account mechanism \cite{gridmapdirsite}.
367 aramv 787 This mechanism can be extended to dynamic groups when needed.
368     Using group mappings based on the user's VO attributes, scheduling priority decisions can be made.
369 aramv 671
370     The LCMAPS framework hosts a list of specific credential types in its core.
371 aramv 787 These are offered to the plug-ins via an API.
372     Each plug-in has a specific task to perform, like in the previous frameworks.
373     The plug-ins are able to write intermediate results or final results into the core memory of the framework.
374     The LCMAPS framework has two failover mechanisms in the execution of its loaded plug-ins that can be defined by the configuration file.
375     The first failover mechanism is similar to a state machine.
376 aramv 941 If a plug-in 'a' executes and its execution was a success, then progress to plug-in 'b'.
377     Otherwise progress to plug-in 'c'.
378 aramv 787 The state machine must end with a successful result.
379     The second failover mechanism is to define (execution) policies.
380     Each complete state machine is an execution policy.
381     If multiple policies are defined and if the calling application allows it, then on a failure of such policy the framework can select the next policy to execute.
382     Between policy switch the internal memory (with the intermediate results) will be erased. \cite{nikhefwebsite:gridwikiindex}
383 aramv 671
384     % BEGIN oscar
385 aramv 787 A set of user credentials, e.g. the DN and combination of group and role affiliations listed in the VOMS credentials, will be linked to a specific pool account.
386 aramv 941 A pool account is a regular Unix account that is already present on a system and is already setup to have certain particular privileges of a particular group of users that might also have a specific role e.g. a Production manager, Software Manager or regular user.
387 aramv 928 In its initial state a pool account is not associated to any user.
388 aramv 787 During the mapping process a user's credentials are mapped to a specific pool account which means that the selected free pool account is strongly tied to the set of user credentials.
389     When a user returns to the same site with the same set of credentials the user will be mapped to the same Unix account again.
390 aramv 671
391 aramv 928
392     \subsubsection{Plug-ins}
393     The plug-ins that LCMAPS executes must all exit successfully before authorization can continue. \cite{nikhefwebsite:gridwikiindex}
395     \begin{description}
396 aramv 936 %\item[Gridlist]{A plug-in that maps users to pool accounts using the gridmapfile \cite{gridmapfile}}
397 aramv 946 \item[Local account]{Maps the supplied user credentials (i.e. a Subject DN or VOMS-signed FQANs) to a local user account on a target system \cite{lcmaps_apido}}
398     \item[Pool account]{Maps the supplied user credentials (i.e. a Subject DN or VOMS-signed FQANs) to a pool account on a target system \cite{lcmaps_apidoc}}
399     \item[POSIX enforcement]{A plug-in that applies acquired credential information to procure a Unix user account on a target system. Verifies that the account was successfully attained. \cite{lcmaps_apidoc}}
400     \item[LDAP enforcement]{A plug-in that applies acquired credential information in a target LDAP database \cite{lcmaps_apidoc}}
401     \item[Verify proxy]{This plug-in can verify the validity and authenticity of the incoming Grid credentials, and enforce life time constraints on the proxy \cite{lcmaps_apidoc}}
402 aramv 928 \end{description}
404 aramv 900 \subsection{SCAS}
405     The \textit{Site Central Authorization Service} makes authorization and mapping decisions upon the presented credentials.
406     %It uses HTTPS authentication to authenticate a client, based on the credentials in their Grid certificate. %(as regular user or pilot job user) and present user credentials.
407 aramv 941 The service is a front-end to the LCAS and LCMAPS frameworks and uses HTTPS with mutual authentication to setup a session in which a SAML2-XACML2 \cite{authzinterop} request is sent.
408 aramv 900 \glossary{name={SCAS}, description={Site Central Authorization Service}}
411 aramv 907 The SCAS is specifically tailored to solve the use case involving pilot job frameworks. (Please see appendix \ref{use_case_pilot_job}.)
412 aramv 900 %This relatively new use case involves the late binding of the \textit{Worker Node} (WN) resources by sending pilot jobs to all the compute clusters by a production manager.
413     %When the pilot jobs come out of the queue and have started their run, they'll discover if the Worker Node on which they have acquired a job slot meets the criteria specified by the user.
414     %If the job slot criteria can be satisfied the pilot job framework will download the payload from a VO central job repository queue, unpack the payload and start executing the actual job.
416     %In this use case there are two actors: a user and a VO production manager.
417     %The VO production manager who has the responsibility to fill all the queues on the clusters according to the used quotas and taking into account what kind of data is stored nearby the compute cluster.
418     %The user had to submit their analysis jobs to the central queue.
419     %The pilot jobs submitted by the VO production managers will pick up the analysis jobs from the central queue.
421     %As this use case has two actors into play two sets of credentials will need to be authorized.
422     %The gLExec and SCAS are able to do this.
427 aramv 938 % cite OASIS standard saml2-xacml2 .
428 aramv 900 The SCAS will authorize the pilot job framework production manager and it will authorize the payload user using the LCAS framework.
429 aramv 938 Upon successful authorization the user credentials of the payload will be mapped to Unix credentials by LCMAPS and returned in a SAML2-XACML2 \cite{authzinterop} response.
430 aramv 900 In such response there is a binary authorization statement given and optionally XACML obligations can be returned.
432     Obligations are name-spaced identifiers that can contain attributes.
433     Returned XACML obligations are non-repudiable (undeniable) and must be handled by the client who receives them.
434 aramv 941 An possible obligation for gLExec to fulfil might be a Unix \textit{uid} and/or \textit{gid}s.
435 aramv 900 The XACML convention is to abort the authorization (and mapping) process if the client cannot meet the obligations set by the service.
436     % oscar
439 aramv 936
440     \subsection{Limitations of existing frameworks}
441 aramv 941 The framework lacks the (native) support to process and pass through anything other than X.509 related information, VOMS credentials and Unix \textit{uid}s/\textit{gid}s.
442     New use cases demand the possibility of passing other credentials and arbitrary information to operate.
443 aramv 928 \begin{description}
444 aramv 936 % Behalve de unix credentials zoals we die nu hebben doorgeven, we ook use-cases om dynamisch priority queues en priority scheduling te kunnen doen in verschillende typen batch systems met verschillende batch system scheduler.
445     %\item Software design overly complex, difficult to maintain.
446     % Alleen evaluation manager
447     %\item Strongly oriented towards existing use cases.
448     %\item Unable to handle new use cases.
449     \item[Strong binding to X.509 certificates, VOMS credentials, and Unix \textit{uid}s/\textit{gid}s.]{
450 aramv 942 This limits the types of systems and services the middleware frameworks can natively interact with.
451 aramv 941 For example mapping of user credentials to Virtual Machine images.
452 aramv 936 }
453     %\item[No facility to interact with scheduling services]
454 aramv 937 \item[Does not facilitate direct low-level interaction with batch systems and schedulers]{
455     A desired functionality is the on-demand creation of priority queues.
456     It should also be possible to manipulate existing scheduling configurations.
457 aramv 936 }
458 aramv 937 \item[No facility to interact with virtualization frameworks]{
459     %kijk naar sander's e-mail van vanochtend (15 oct. 11:11) onder taken.
460     %describe interaction
461     To enable the scheduling of Virtual Machine execution, a connection to existing virtualization frameworks must be made.
462     The \textit{Open Cloud Computing Interface} (OCCI) API \cite{occi} or OpenNebula toolkit \cite{opennebula} are frameworks that could be incorporated to enable scheduling of virtual machine execution.
463     % plug-in voor het batch systeem
464 aramv 936 }
465 aramv 671
466 aramv 936 \item[No facility to interact with batch-systems in an arbitrary way]{
467     % Op ieder cluster systeem heb je allerlei trucjes om je systeem in leven te houden, dit maakt een hook voor je.
468 aramv 937 %Het idee is dat je met perl/python scripts systeembeheerders mogelijkheden geven om systeem-specifieke handelingen uit te kunenn voeren. bijv. interacties met lokale accounting systemen
469     Because each cluster configuration is different it would be very beneficial to let system administrators hook their management scripts into the framework.
470 aramv 941 Adding support for high-level scripting languages like Perl or Python and providing them access to the internal plug-in API should be an effective way to allow this.
471 aramv 936 }
472     % We hebben een datastore. Datastore is toegespitst op X509,VOMS, en Unix credentials
473 aramv 787 %\item Inability to facilitate a shared data store for plug-ins executed in the framework.
474 aramv 671 % LCAS/LCMAPS hebbben wel een data store, om gegevens te delen
475     % Maar dat ze te specifiek zijn voor bepaalde toepassing
476     % Toegespitst op bepaalde use cases.
477     % Het moet generiek worden.
478 aramv 936
481 aramv 900 % Uitwijden over wat we van plan zijn
482 aramv 671 % Alles is georienteerd op x509 plus voms naar unix credentials.
485 aramv 787 %\item Opaque and non-intuitive due to the above.
486 aramv 936 \end{description}
487 aramv 671
488 aramv 925
489     %\chapter{The new authorization framework}
490     %\chapter{The EES Execution Framework}
491 aramv 928 \pagebreak
492 aramv 925 \section{Argus: the new authorization framework}
493     \subsection{Motivation}
494     Argus aims to improve interoperability between Grid services.
495     It is designed to be more modular than SCAS, and should be able to handle new use cases.
496 aramv 941 The interaction between systems is similar at a high level, but the Argus framework separates the roles and tasks as performed by the SCAS system into more granular and abstract services.
497 aramv 937 %, like what, why and how?
498 aramv 936 % Abstracter, meerdere componenten. duidelijke rolverdeling
499     % Waarom waarom waarom???
500     %
501 aramv 925
502     \subsection{Components of the Argus framework}
503     %\section{Architecture of the Argus Authorization Services}
504     \begin{figure}[hp]
505     \centering
506     \includegraphics[width=\textwidth]{argus}
507     \caption[Argus diagram]
508     {A diagram showing the architecture of Argus authorization framework}
509     \label{fig:argus}
510     \end{figure}
512     \subsubsection{Policy Enforcement Point (PEP)}
513 aramv 937 The \textit{Policy Enforcement Point} is the client to the authorization service.
514     It generates an authorization request and forwards it to the PDP for evaluation.
515     The PDP responds with a decision, and a set of obligations the PEP must fulfil.
516     %krijgt een beslissing terug, met obligations die 'ie moet verwerken
517 aramv 925
518     \subsubsection{Policy Decision Point (PDP)}
519 aramv 937 The \textit{Policy Decision Point} is a policy evaluation engine.
520     The PDP receives authorization requests from Policy Enforcement Points and evaluates these requests against authorization policies retrieved from the PAP.
521 aramv 941 It returns its response to the PEP, and interacts with an EES to procure (specific) execution environments.
522 aramv 925
523 aramv 937 %antwoord wordt teruggegeven aan een PEP
524 aramv 936
525 aramv 925 \subsubsection{Policy Administration Point (PAP)}
526 aramv 937 The \textit{Policy Administration Point} provides tools to author, store and manage authorization policies.
527     This service can interact with other PAPs, and can combine external policies with local ones.
528     Interaction with other PAPs can be useful to coordinate policies in dealing with security issues.
529     It provides managed policies to other authorization service components, such as the PDP.
530 aramv 925
531 aramv 937 % interact met externe (andere PAP's). (Bijv OSCT)
532 aramv 936 % Externe policies kan 'ie combineren met de lokale policies
534 aramv 925 \subsubsection{Execution Environment Service (EES)}
535 aramv 941 %The \textit{Execution Environment Service}.
536 aramv 937 The role of the EES is to ensure that an appropriate site-specific execution environment is procured based on the site-agnostic obligations and attributes it receives as input in the form of SAML2-XACML2 requests.
537 aramv 943 It responds to requests from the PDP, but can also act as a standalone service.
538 aramv 937 It should be able to interact with many kinds of services and systems, for instance:
539     \begin{itemize}
540     \item Mapping users to pool accounts on Unix systems
541 aramv 942 %\item Interacting with the Maui scheduler to reconfigure a queue (e.g. changing scheduling configuration, creating a queue with certain requirements and moving a queue)
542     \item Add or change batch system queues
543 aramv 937 \item Procuring a VM environment through a virtualization framework
544 aramv 941 \item Executing arbitrary scripts local to the site for management purposes, as an addition to site-specific tooling or to be able to support specific use cases for which native support is not available
545 aramv 937 \end{itemize}
546 aramv 925
547 aramv 937
548     % interacties met andere dingen
549 aramv 936 % Pool account mapping
550     % Maui queue
551     % VM procurement
552     % OpenNebula
553     % arbitrary script execution
554 aramv 928
555 aramv 925 %\subsection{Policy Information Point (PIP)}
556     %The \textit{Policy Information Point} ...
558     \glossary{name={EES}, description={Execution Environment Service}}
559     \nomenclature{EES}{Execution Environment Service}
561     \glossary{name={PDP}, description={Policy Decision Point}}
562     \nomenclature{PDP}{Policy Decision Point}
564     \glossary{name={PAP}, description={Policy Administration Point}}
565     \nomenclature{PAP}{Policy Administration Point}
567     \glossary{name={PIP}, description={Policy Information Point}}
568     \nomenclature[]{PIP}{Policy Information Point}

ViewVC Help
Powered by ViewVC 1.1.28