This repository has been archived by the owner on Sep 23, 2020. It is now read-only.
/
service-authz.html
312 lines (266 loc) · 9.26 KB
/
service-authz.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
m4_include(/mcs/m4/worksp.lib.m4)
_NIMBUS_HEADER(2.8 Extensibility Guide)
_NIMBUS_HEADER2(n,n,y,n,n,n,n,n)
<style type="text/css">
ul.nobullets {
list-style: none;
}
</style>
_NIMBUS_LEFT2_COLUMN
_NIMBUS_LEFT2_DEV2_SIDEBAR(n,y,n,n,n,n,n,n,n)
_NIMBUS_LEFT2_COLUMN_END
_NIMBUS_CENTER2_COLUMN
_NIMBUS_IS_DEPRECATED
<h2>Request authorization</h2>
<h4>* Summary:</h4>
<p>
The <a href="service-reqintake.html">Creation</a> process in the
<a href="../faq.html#workspace-service">workspace service</a>
makes an optional callout to authorize the request further than the basics.
</p>
<p>
<b>NOTE</b>: (see the end of this page for an overview of
Nimbus authorization flow)
</p>
<hr />
<h4>* Java interface:</h4>
<ol>
<li>
<p>
The basics are authorized by an implementation of this interface:
<b>org.globus.workspace.service.binding.GlobalPolicies</b>
</p>
<p>
Source code: <i>service/service/java/source/src/org/globus/workspace/service/binding/</i>
</p>
<p>
Activated by way of the <i>$GLOBUS_LOCATION/etc/nimbus/workspace-service/other/main.xml</i>
file -- see the "nimbus-rm.service.binding.GlobalPolicies" Spring bean.
</p>
</li>
<li>
<p>
If configured, further authorization can be done by an implementation of this interface:
<b>org.globus.workspace.service.binding.authorization.CreationAuthorizationCallout</b>
</p>
<p>
Source code: <i>service/service/java/source/src/org/globus/workspace/service/binding/authorization/</i>
</p>
<p>
Activated by way of the <i>$GLOBUS_LOCATION/etc/nimbus/workspace-service/other/main.xml</i>
file -- see the "nimbus-rm.service.binding.Authorize" Spring bean.
</p>
</li>
</ol>
<hr />
<h4>* Default implementation:</h4>
<p>
<b>org.globus.workspace.service.binding.defaults.DefaultGlobalPolicies</b>
</p>
<p>
Source code: <i>service/service/java/source/src/org/globus/workspace/service/binding/defaults/</i>
</p>
<p>
(there is no default CreationAuthorizationCallout, it is <b>optional</b>)
</p>
<br />
<a name="groupauthz"> </a>
<h2>Group authorization plugin _NAMELINK(groupauthz)</h2>
<p>
One implementation of <i>CreationAuthorizationCallout</i> is the groupauthz
plugin.
</p>
<p>
The plugin can enforce the following policies. The request data
to check is determined on a per-request, per-client basis.
The <b>limits</b> are defined on a per group basis (every caller
identity must be a part of a group).
</p>
<ul>
<li>
Maximum currently reserved minutes at one point in time. If the
caller has two other workspaces with 10 hours scheduled for each,
the value being checked against this policy would be 20 hours
plus whatever time the current request is.
</li>
<li>
Maximum elapsed and currently reserved minutes at one point in
time. If the caller has one other workspace with 10 hours
scheduled and 80 hours of recorded past usage, the value being
checked against this policy would be 90 hours plus whatever time
the current request is. This is the all-time maximum usage cap.
</li>
<li>
Maximum number of running workspaces at one point in time.
</li>
<li>
Maximum number of workspaces per request (the largest group
request possible).
</li>
<li>
The image node that must be specified.
</li>
<li>
The image node base directory that must be specified.
</li>
<li>
Support for identity-hash based image subdirectories
(see the cloud setup documentation to understand this
convention).
</li>
</ul>
<p>
Each policy can be set to disabled/infinite for specific groups
if you desire.
</p>
<br />
<a name="pythonauthz"> </a>
<h2>Python authorization plugin _NAMELINK(pythonauthz)</h2>
<p>
We also distribute a Python based authorization plugin that allows an
administrator to provide only a simple Python script to express policies
(using the "Jython" library).
</p>
<p>
This plugin is compatible with both
<a href="http://dev.globus.org/wiki/VOMS">VOMS</a>
and <a href="http://gridshib.globus.org/about.html">GridShib</a>
attribute based authorization if either is enabled to protect the
factory service create operation in the GT4 configuration.
</p>
<br />
<h2>Authorization flow</h2>
<p>
Understanding the authorization possibilities requires some understanding
of the factory service's <i>create</i> process, so the explanation below
includes extra information that is not authorization related <i>per se</i>.
</p>
<h3>Default: gridmap setup</h3>
<p>
The default installation is configured with gridmap authorization,
a DN access control list, that allows only clients in the gridmap
file to call the factory create operation.
</p>
<ul class="nobullets">
<li>
<img src="../img/1.png" alt="1" border="0">
If the client's DN is not in the grid-mapfile list, the operation will
will return a fault with the authorization error explained.
</li>
</ul>
<p>
The request is then validated and default values are filled in if not
supplied by the client. This is also where network addresses are leased
if necessary.
</p>
<ul class="nobullets">
<li>
<img src="../img/2.png" alt="2" border="0">
If the request is simply invalid, it will be denied and a
WorkspaceMetadataFault will be returned.
</li>
<li>
<img src="../img/3.png" alt="3" border="0">
If the request is asking for network allocations and there are not
enough, the request will be denied and a
WorkspaceResourceRequestDeniedFault will be returned.
</li>
</ul>
<p>
Then the request is compared against the master policies configured
in the factory.
</p>
<ul class="nobullets">
<li>
<img src="../img/4.png" alt="4" border="0">
A violation will cause a WorkspaceResourceRequestDeniedFault to be
returned.
</li>
</ul>
<p>
<br>
<img alt="authorization flow 1" src="../img/authorization1.jpg"/>
</p>
<br />
<h3>Attribute based authorization</h3>
<p>
The VOMS and GridShib modules run <i>before</i> the Workspace
Factory Service is ever invoked, just like the gridmap authorization:
</p>
<p>
<br>
<img alt="authorization flow 2" src="../img/authorization2.jpg"/>
</p>
<p>
As mentioned above there is a plugin interface for creation time
authorization. All relevant information about the request is passed
to the plugin including client identity and attributes (if available)
as well as the workspace description and resource request. The
callout to this plugin occurs <i>after the validation process</i>:
</p>
<p>
<br>
<img alt="authorization flow 3" src="../img/authorization3.jpg"/>
</p>
<p>
The supplied Python based plugin allows an administrator to configure
a much richer policy than the factory policies allow for. For example,
any arbitrary combination of <b>resource allocation</b> request (such as
RAM), <b>network</b> settings, deployment <b>duration</b>,
client <b>DN</b>, and client <b>attributes</b> can be taken into account.
</p>
<p>
This implementation of the authorization callout can present both VOMS
credentials and SAML attributes (via GridShib) to the policy evaluation.
But before they can be consulted, the "PIP" (Policy Information Point)
portion of those modules must be configured. The PIP is what collects
the attributes, the PDP (Policy Decision Point) is what enforces policy.
This distinction is being mentioned because the PIP can be
configured <i>without the PDP</i> in the VOMS and
GridShib packages. Bear in mind that this might be an option if you
are using the workspace authorization callout and want to handle all
attribute policy there instead of <i>before the factory service</i> which
is when the VOMS and GridShib modules are run. Thus, the PIP modules
can collect the attributes about the client and then the detailed policy
about those attributes can be expressed in the workspace creation time
authorization callout.
</p>
<br />
<h3>Finally</h3>
<p>
In all cases, <b>after the default policy check succeeds</b>, the request
is currently passed next to the scheduling/resource management plugin where
problems will also lead to a WorkspaceResourceRequestDeniedFault.
</p>
<p>
<b>After scheduling succeeds</b>, the only thing stopping success at this
point is an internal error (for example, a database connection problem).
</p>
<br />
<h3>Once deployed</h3>
<p>
<i>Note:</i> Once deployed, a workspace can be managed and inspected
via <a href="../interfaces/service.html">Workspace Service</a>
or <a href="../interfaces/groupservice.html">Workspace Group Service</a>
operations. Also, destruction may be run when using groups of groups,
Workspace Ensemble Service.
</p>
<p>
Currently, no matter what authorization scheme is in use, once a workspace
(or group of them) is deployed, al lof these operations are protected by a
DN access control list consisting of the creator DN. <b>Only the deployer
can remotely manage or inspect the workspace</b>.
</p>
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
_NIMBUS_CENTER2_COLUMN_END
_NIMBUS_FOOTER1
_NIMBUS_FOOTER2
_NIMBUS_FOOTER3