1 |
aramv |
650 |
\chapter{Grid authentication mechanisms} |
2 |
|
|
% 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 |
|
|
\section{Authentication \& Authorization} |
7 |
|
|
Grid computing requires a mechanism to authorize users' access to grid resources. This authorization can be granted at different levels depending on different types of credentials associated with - or supplied by - the user. |
8 |
|
|
|
9 |
|
|
The various grid middleware stacks rely heavily on x509 certificates as the 'lingua franca' for authenticating users. |
10 |
|
|
It's a personal SSL certificate that can be traced back to the issuer (Certificate Authority). |
11 |
|
|
Grid services have a push model that requires users to upload their certificate which is then verified by the service. |
12 |
|
|
Users should apply to a VOMS-server that handles authentication for their project and send in their grid certificate. |
13 |
|
|
A user can be authorized by tracing this (signed) information back to a trusted VOMS server certificate, which has in turn been signed by a trusted CA. |
14 |
|
|
% Mensen moeten zich via email aanmelden bij de VOMS-server |
15 |
|
|
% Alle grid services en VOMS servers hebben een push-model waarin je je certificate upload. De services moeten deze informatie verifieren. |
16 |
|
|
|
17 |
|
|
Different types of credentials that can be used are: |
18 |
|
|
\begin{itemize} |
19 |
|
|
\item Personal x509 certificate and personal host en service certificates % Wie ben je |
20 |
|
|
|
21 |
|
|
\labelitemi{Information like the Subject Distinguished Name and embedded VOMS credentials (Fully Qualified Attribute Name) are embedded in the x509 certificate. |
22 |
|
|
The DN information is used to query a certian VOMS server, which returns an attribute certificate in which each field and the whole certificate is signed by the VOMS server. |
23 |
|
|
Based on these signed attributes a user is authenticated to belong to a trusted project group in a certain role. |
24 |
|
|
} |
25 |
|
|
% Op basis van de info in het certificaat (je DN) en VOMS credentials (FQAN) worden user geauthoriseerd. |
26 |
|
|
% (Wie ben je, voor welke groep werk je, wat is je rol). |
27 |
|
|
|
28 |
|
|
%\item VOMS credentials (Fully Qualified Attribute Name) % Voor welke groep werk je en welke rol bekleed je |
29 |
|
|
% 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). |
30 |
|
|
\item SAML statements % Zie je terug in Shibolleth. Altijd terug te leiden naar x509 certificates. Andere niet-standaard authenticatiemethoden. Komt meer uit de web-hoek. |
31 |
|
|
|
32 |
|
|
\labelitemi{The Security Assesment Markup Language was devised as a web standard based on XML. These statements lead users back to a x509 certificate. |
33 |
|
|
The standard was devised for interoperability between Single Sign-on solutions.} |
34 |
|
|
\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). |
35 |
|
|
|
36 |
|
|
\labelitemi{The eXtensible Access Control Markup Language is a markup language used to describe security policies.} |
37 |
|
|
|
38 |
|
|
% scenario 1 |
39 |
|
|
% User interface (laptop) |
40 |
|
|
% -> job (J(S)DL) -> |
41 |
|
|
% WMS |
42 |
|
|
% -> job (JDL) -> (hangt af van CE - GRAM, BE) |
43 |
|
|
% Compute element |
44 |
|
|
% -> qsub:job -> |
45 |
|
|
% PBS server (zoekt beste node) |
46 |
|
|
% -> task -> |
47 |
|
|
% Worker node |
48 |
|
|
% voert uit |
49 |
|
|
|
50 |
|
|
% scenario 2 |
51 |
|
|
% User interface (laptop) |
52 |
|
|
% -> job (J(S)DL) -> |
53 |
|
|
% Pilot job framework repo |
54 |
|
|
% VO Production manager is iemand die pilot jobs inschiet bij het WMS. |
55 |
|
|
% WMS vindt het beste CE |
56 |
|
|
% Hier zoekt een compute element de beste workernode via PBS server |
57 |
|
|
% Pilot jobs kunnen hun payload van de Pilot Job Framework repo ophalen als ze eenmaal op de WN draaien. |
58 |
|
|
% Pilot job doet userswitch dmv glexec & scas en voert de job uit |
59 |
|
|
|
60 |
|
|
% Worker node in depth |
61 |
|
|
% WN krijgt een pilot job binnen van de PBS server |
62 |
|
|
% Pilot job haalt een job op uit de Pilot Job Framework Repository |
63 |
|
|
% Pilot job framework roept glexec aan |
64 |
|
|
% Glexec doet userswitch naar |
65 |
|
|
% Glexec pakt 2 certificates (het user certificaat zit inbegrepen bij de payload, het VO production manager certificaat wordt op de normale manier opgehaald) |
66 |
|
|
|
67 |
|
|
% scenario 3 |
68 |
|
|
% User interface (laptop) |
69 |
|
|
% -> job (J(S)DL) -> |
70 |
|
|
% Pilot job framework repo |
71 |
|
|
% VO Production manager is iemand die pilot jobs inschiet bij het WMS. |
72 |
|
|
% WMS vindt het beste CE |
73 |
|
|
% Hier zoekt een compute element de beste workernode via PBS server |
74 |
|
|
% Pilot jobs kunnen hun payload van de Pilot Job Framework repo ophalen als ze eenmaal op de WN draaien. |
75 |
|
|
% Pilot job doet userswitch dmv glexec & scas en voert de job uit |
76 |
|
|
|
77 |
|
|
% Job -> WMS |
78 |
|
|
% WMS zoekt resources en stuurt door naar compute element. |
79 |
|
|
% WMS heeft jou creds doorgegeven aan compute element. |
80 |
|
|
% Compute element authenticeert jou. |
81 |
|
|
% Compute element queriet de SCAS service met jouw credentials en dat hij een compute elementis. |
82 |
|
|
% Compute element = voordeur grid cluster. |
83 |
|
|
% Als antwoord van de SCAS service okay is kunnen er nog extra attributen worden teruggegeven die verwerkt moeten worden. |
84 |
|
|
% Voorbeelden van extra attributen die door de SCAS worden teruggegeven (XACML response) zijn: pool accounts (unix credentials die door de SCAS zijn gekoppeld aan de user en zijn huidige rol), incentives om bepaalde extra gegevens mee te kunnen geven aan de scheduler (zoals prioriteits informatie). |
85 |
|
|
% Bijv: Higgs groep bij LHC krijgt meer tijd dan de Muon groep. |
86 |
|
|
% Andere extra attributen die door de SCAS worden teruggegeven zijn: specifieke virtuele machines. |
87 |
|
|
|
88 |
|
|
% PEPd -> Policy Enforcement Point daemon |
89 |
|
|
% PDP -> Policy Decision Point |
90 |
|
|
% PAP -> Policy Administration Point |
91 |
|
|
|
92 |
|
|
\item Host-based credentials |
93 |
|
|
|
94 |
|
|
\labelitemi{In its simplest form, this is a whitelist of certificates that are signed by trusted hosts.} |
95 |
|
|
% Whitelist voor certificates die gesigned zijn door bepaalde hosts |
96 |
|
|
\end{itemize} |
97 |
|
|
% Basis van de authenticatie is gebaseerd op de persoonlijke certificaten. |
98 |
|
|
% Die zijn uitbreidbaar. |
99 |
|
|
% |
100 |
|
|
The reason multiple authentication mechanisms must be supported is due to the scale and breadth of the grid use cases. |
101 |
|
|
% Bepaalde technieken, evolutie ervan, adoptie/penetratie van technieken die we hebben. |
102 |
|
|
% Open standaarden die we zoveel mogelijk willen ondersteunen. |
103 |
|
|
% SAML is heel nieuw, PKI bestaat al heel lang, en daarbij: proxy delegations. |
104 |
|
|
% Door Delegation of credentials from your certificate to a WMS zodat die service functioneert als een agent. |
105 |
|
|
% 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. |
106 |
|
|
% Het proxy certificate is cryptografisch verbonden, omdat jij de signer bent. |
107 |
|
|
Support for these mechanisms has evolved over the past decade, and gradually got more pluggable over ther years. |
108 |
|
|
% 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. |
109 |
|
|
|
110 |
|
|
% End-to-end security: dat je de chain van de worker node kunt terugleiden naar de persoon die de job submitte. |
111 |
|
|
% Vanwege de schaalbaarheid maken we vooral authorisatie beslissingen op basis van groepen. |
112 |
|
|
% Mensen die in die groep zitten worden impliciet vertrouwd. |
113 |
|
|
% VOMS: Virtual Organisation staat min of meer 1:1 tot een experiment of een project. |
114 |
|
|
% Binnen de VO kennen we groepen, subgroepen en rollen. Aan ieder van deze kunnen personen worden toegewezen, en ook services en resources. |
115 |
|
|
% Individu moet zich registeren bij een VO, en als je geregistreerd bent kun je gesignede tokens ophalen. |
116 |
|
|
% User genereert een certificate en laat hem signen door een CA. |
117 |
|
|
% User kan een proxy certificate maken van z'n user cert. |
118 |
|
|
% Daarmee authenticeer je jezelfd bij de VOMS server (standaard mutual SSL authentication) en vraag je de groepen van jouw VO en evt. rollen. |
119 |
|
|
% 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. |
120 |
|
|
% Nu ga je een nieuwe proxy delegation maken, en tijdens het signing request worden de VOMS AC embedded in de CSR als x509v3 extensies. |
121 |
|
|
% Dit geheel wordt nu gesigned als een reguliere met jouw eigen private key. |
122 |
|
|
|
123 |
|
|
% VOMS AC's zijn gebaseerd op RFC 3281. |
124 |
|
|
% Certificates waren gebaseerd op RFC 3280, maar nu is dat RFC 5280 |
125 |
|
|
|
126 |
|
|
% Nu heb je een VOMS-enabled certificate (VOMS proxy). |
127 |
|
|
% Attributes in een VOMS proxy zijn: |
128 |
|
|
% Van de VOMS server die signed: de URI, de DN, de signer van de DN. |
129 |
|
|
% Dus je hebt twee dingen om te controleren: de cert van de VOMS (naar de CA) en de signer (ook CA) van de DN. |
130 |
|
|
|
131 |
|
|
% IGTF is een samenwerking van 3 grote grid (igtf.net) |
132 |
|
|
% PKI + personal certificates. |
133 |
|
|
% 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. |
134 |
|
|
% (Dan heb je ook nog een name-value pair voor mogelijk extra attributen.) |
135 |
|
|
|
136 |
|
|
|
137 |
|
|
% Nog 2 dingen die in je VOMS proxy kunnen zitten: |
138 |
|
|
% Public key van de voms service. |
139 |
|
|
% Serial number van jouw persoonlijke certificaat. |
140 |
|
|
% Jouw subject DN. |
141 |
|
|
|
142 |
|
|
|
143 |
|
|
% Zo is er een linkt te leggen tussen: |
144 |
|
|
% Jouw subject DN, jouw CA, en jouw serial number van jouw certificaat. |
145 |
|
|
% 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. |
146 |
|
|
|
147 |
|
|
% VOMS AC |
148 |
|
|
% DN, FQAN, CA, serial number, secret sauce. |
149 |
|
|
|
150 |
|
|
\section{Evolution of authorization mechanisms} |
151 |
|
|
|
152 |
|
|
\subsection{ADAM} |
153 |
|
|
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. It was not designed as a security middleware, but it does have a pluggable architecture to extend its functionality.}. \cite{adampage} |
154 |
|
|
\subsection{LCAS} |
155 |
|
|
LCAS is the \textit{Local Centre Authorization Service}. |
156 |
|
|
This component makes binary ('yes' or 'no') authorization decisions at the site and resource level. |
157 |
|
|
In making this decision, it can use a variety of inputs: the 'grid' name of the user (the Subject Distinguished Name), any VO attributes the user has (like VOMS (https://twiki.cnaf.infn.it/cgi-bin/twiki/view/VOMS) FQANs), the name of the executable the user intends to execute. |
158 |
|
|
It supports basic black and white list functionality, but also more complex VOMS-based expressions, based on the GACL \cite{gaclsite:home} language. \cite{nikhefwebsite:gridwikiindex} |
159 |
|
|
|
160 |
|
|
\subsection{LCMAPS} |
161 |
|
|
LCMAPS is the \textit{Local Credential Mapping Service}. |
162 |
|
|
It takes care of translating grid credentials to Unix credentials local to the site. |
163 |
|
|
Using the pool account mechanism \cite{gridmapdirsite}, extended to dynamic groups when needed, it takes case of ensuring that different individuals on the grid remain distinct unix accounts. |
164 |
|
|
Using group mappings based on the user's VO attributes, isolation and scheduling priority decisions can be made. |
165 |
|
|
It can also verify the validity and authenticity of the incoming grid credentials, just like when you would have established a TLS connection over a network. |
166 |
|
|
This 'verify-proxy' plugin can also enforce life time constraints on the proxy. \cite{nikhefwebsite:gridwikiindex} |
167 |
|
|
\subsection{SCAS} |
168 |
|
|
The \textit{Site Central Authorization Service} makes authorization and mapping decisions centrally. |
169 |
|
|
It uses HTTPS authentication to authenticate a client (as regular user or pilot job user) and present user credentials. |
170 |
|
|
These user credentials are generic user accounts that are mapped to the remote user based on the credentials in their certificate. \cite{nikhefwebsite:gridwikiindex} |
171 |
|
|
|
172 |
|
|
\section{Limitations of previous frameworks} |
173 |
|
|
\begin{itemize} |
174 |
|
|
\item Inability to facilitate a shared data store for plugins executed in the framework. |
175 |
|
|
\item Software design overly complex, difficult to maintain. |
176 |
|
|
\item Opaque and non-intuitive due to the above. |
177 |
|
|
\end{itemize} |
178 |
|
|
|
179 |
|
|
|
180 |
|
|
|