Mercurial > hg > orthanc-book
annotate Sphinx/source/plugins/authorization.rst @ 919:5c1ce758f748
uclouvain
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Fri, 17 Mar 2023 12:58:14 +0100 |
parents | 8b48d42665c4 |
children | 1d9e0aa08fdd |
rev | line source |
---|---|
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
1 .. _authorization: |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
2 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
3 |
851
f282da89c1c1
auth plugin not deprecated anymore
Alain Mazy <am@osimis.io>
parents:
761
diff
changeset
|
4 Advanced authorization plugin |
f282da89c1c1
auth plugin not deprecated anymore
Alain Mazy <am@osimis.io>
parents:
761
diff
changeset
|
5 ============================= |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
6 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
7 .. contents:: |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
8 |
98 | 9 This **official plugin by Osimis** extends Orthanc with an advanced |
97 | 10 authorization mechanism. For each incoming REST request to some URI, |
11 the plugin will query a Web service to know whether the access is | |
98 | 12 granted to the user. If access is not granted, the HTTP status code is |
13 set to ``403`` (Forbidden). | |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
14 |
98 | 15 The `source code of this plugin |
449 | 16 <https://hg.orthanc-server.com/orthanc-authorization/file/default>`__ is |
361 | 17 freely available under the terms of the AGPLv3 license. |
97 | 18 |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
19 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
20 Compilation |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
21 ----------- |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
22 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
23 .. highlight:: bash |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
24 |
98 | 25 The procedure to compile this plugin is similar of that for the |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
26 :ref:`core of Orthanc <binaries>`. The following commands should work |
761 | 27 for most UNIX-like distribution (including GNU/Linux):: |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
28 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
29 $ mkdir Build |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
30 $ cd Build |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
31 $ cmake .. -DSTATIC_BUILD=ON -DCMAKE_BUILD_TYPE=Release |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
32 $ make |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
33 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
34 The compilation will produce a shared library ``OrthancAuthorization`` |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
35 that contains the authorization plugin. |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
36 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
37 Usage |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
38 ----- |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
39 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
40 .. highlight:: json |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
41 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
42 You of course first have to :ref:`install Orthanc <compiling>`. Once |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
43 Orthanc is installed, you must change the :ref:`configuration file |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
44 <configuration>` to tell Orthanc where it can find the plugin: This is |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
45 done by properly modifying the ``Plugins`` option. You could for |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
46 instance use the following configuration file:: |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
47 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
48 { |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
49 "Name" : "MyOrthanc", |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
50 [...] |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
51 "Plugins" : [ |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
52 "/home/user/OrthancAuthorization/Build/libOrthancAuthorization.so" |
97 | 53 ], |
54 "Authorization" : { | |
878 | 55 "WebService" : "http://localhost:8000/", |
56 "WebServiceUsername": "my-user", | |
57 "WebServicePassword": "my-password", | |
58 "WebServiceIdentifier": "my-id" | |
97 | 59 } |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
60 } |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
61 |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
62 Orthanc must of course be restarted after the modification of its |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
63 configuration file. |
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
64 |
97 | 65 |
66 Web Service | |
67 ----------- | |
68 | |
69 This section describes how a Web service suitable for the | |
70 authorization plugin can be designed. | |
71 | |
72 **Note:** The behavior described in this section is implemented by the | |
73 ``AuthorizationWebService`` C++ class in the source code. It is | |
74 possible to define a different authorization back-end by deriving | |
75 from interface ``IAuthorizationService``. | |
76 | |
77 | |
78 Incoming request | |
79 ^^^^^^^^^^^^^^^^ | |
80 | |
81 For each HTTP/REST request that Orthanc receives, the plugin will | |
82 issue a set of HTTP ``POST`` requests against the Web service that is | |
83 specified in the configuration file (in the basic configuration file | |
84 above, the Web service listening at ``http://localhost:8000/`` is | |
85 used). The body of each of those ``POST`` requests is a JSON file | |
86 similar to the following one:: | |
87 | |
88 { | |
89 "dicom-uid" : "123ABC", | |
90 "level" : "patient", | |
91 "method" : "get", | |
878 | 92 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8", |
93 "identifier": "my-id" | |
97 | 94 } |
95 | |
96 In this example, the user is accessing an URI that is related to some | |
98 | 97 DICOM resource, namely a patient whose DICOM identifier is |
98 ``123ABC``. In such a case, the following fields will be set in the | |
99 JSON body: | |
97 | 100 |
101 * The ``level`` field specifies which type of resource the user is | |
102 accessing, according to the :ref:`DICOM model of the real world | |
103 <model-world>`. This field can be set to ``patient``, ``study``, | |
104 ``series``, or ``instance``. | |
105 * The ``method`` field specifies which HTTP method is used by the | |
98 | 106 to-be-authorized request. It can be set to ``get``, ``post``, |
107 ``delete``, or ``put``. | |
97 | 108 * The ``dicom-uid`` field gives the :ref:`DICOM identifier |
98 | 109 <dicom-identifiers>` of the resource that is accessed. If the |
97 | 110 resource is a patient, this field contains the ``PatientID`` DICOM |
111 tag. For a study, it contains its ``StudyInstanceUID``. For a | |
112 series, it contains its ``SeriesInstanceUID``. For an instance, it | |
113 contains its ``SOPInstanceUID``. | |
114 * The ``orthanc-id`` field gives the :ref:`Orthanc identifier | |
115 <orthanc-ids>` of the resource. | |
878 | 116 * The ``identifier`` field contains the value of the ``WebServiceIdentifier`` |
117 configuration or ``null`` if this configuration is not defined. This allows | |
118 the WebService to identity which Orthanc instance is calling it (new in v 0.3.0). | |
97 | 119 |
120 When the user accesses a lower-level resource in the DICOM hierarchy | |
121 (a study, a series or an instance), the authorization plugin will | |
122 issue one separate call to the Web service for each level of the | |
123 hierarchy. For instance, here are the 3 successive requests that are | |
124 issued when accessing some series:: | |
125 | |
126 { | |
127 "dicom-uid" : "123ABC", | |
128 "level" : "patient", | |
129 "method" : "get", | |
130 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8" | |
131 } | |
132 { | |
133 "dicom-uid" : "1.3.51.0.1.1.192.168.29.133.1681753.1681732", | |
134 "level" : "study", | |
135 "method" : "get", | |
136 "orthanc-id" : "6e2c0ec2-5d99c8ca-c1c21cee-79a09605-68391d12" | |
137 } | |
138 { | |
139 "dicom-uid" : "1.3.12.2.1107.5.2.33.37097.2012041612474981424569674.0.0.0", | |
140 "level" : "series", | |
141 "method" : "get", | |
142 "orthanc-id" : "6ca4c9f3-5e895cb3-4d82c6da-09e060fe-9c59f228" | |
143 } | |
144 | |
145 It the user is accessing a URI that is not directly related to an | |
146 individual DICOM resource, the JSON body will look as follows:: | |
147 | |
148 { | |
149 "level" : "system", | |
150 "method" : "get", | |
151 "uri" : "/changes" | |
152 } | |
153 | |
154 In such a situation, the following fields are set: | |
155 | |
156 * The ``level`` field is always set to ``system``. | |
157 * The ``method`` field is the same as above. | |
158 * The ``uri`` field provides the URI that was accessed by the user. | |
159 | |
160 **Important note:** The plugin will transparently parse the URIs of | |
161 the core :ref:`REST API of Orthanc <rest>`, of the :ref:`Web viewer | |
162 plugin <webviewer>`, of the :ref:`DICOMweb plugin <dicomweb>`, and of | |
163 the :ref:`whole-slide imaging plugin <wsi>`. Unrecognized URIs (such | |
164 as those introduced by other plugins) will be handled as a ``system`` | |
165 call. It is possible to introduce parsing support for more plugins by | |
166 modifying the ``DefaultAuthorizationParser`` C++ class in the source | |
167 code of the plugin. | |
168 | |
169 | |
170 Expected answer | |
171 ^^^^^^^^^^^^^^^ | |
172 | |
173 The Web service must answer by sending a JSON file that tells whether | |
174 the access is granted or not to the user. Here is a sample answer:: | |
175 | |
176 { | |
177 "granted": true, | |
178 "validity" : 5 | |
179 } | |
180 | |
181 Here is a description of these two fields: | |
182 | |
183 * ``granted`` tells whether access to the resource is granted | |
184 (``true``) or not granted (``false``). In the case the user is | |
98 | 185 accessing a DICOM resource, the access to *all* the levels of the |
186 hierarchy above this resource must be granted (logical conjunction | |
187 over the levels). | |
97 | 188 * ``validity`` tells the authorization plugin for how many seconds the |
189 result of the Web service must be cached. If set to ``0`` second, | |
190 the cache entry will never expire. | |
191 | |
192 **Note:** The source code of the plugin contains a `basic example | |
449 | 193 <https://hg.orthanc-server.com/orthanc-authorization/file/default/Resources/TestService.js>`__ |
97 | 194 of such a Web service written in node.js. |
195 | |
196 | |
197 Authentication tokens | |
198 ^^^^^^^^^^^^^^^^^^^^^ | |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
199 |
98 | 200 It is obviously desirable to limit access to the resources depending |
201 on the user that is logged in. Real-life Web framework such as Django | |
202 would send the identity of the authenticated user either as an HTTP | |
203 header, or as an additional argument for ``GET`` requests. The | |
204 authorization plugin allows to forward these authentication tokens to | |
205 the Web service. | |
206 | |
207 To configure the authentication plugin to use some HTTP header, one | |
208 must provide the option ``TokenHttpHeaders`` the configuration file of | |
209 Orthanc as follows:: | |
210 | |
211 { | |
212 "Name" : "MyOrthanc", | |
213 [...] | |
214 "Authorization" : { | |
215 "WebService" : "http://localhost:8000/", | |
216 "TokenHttpHeaders" : [ "hello" ] | |
217 } | |
218 } | |
219 | |
220 .. highlight:: text | |
221 | |
222 In such a situation, if some HTTP client issues the following call:: | |
223 | |
224 # curl -H 'hello: world' http://localhost:8042/patients/6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8 | |
225 | |
226 .. highlight:: json | |
227 | |
228 Here is the JSON body the Web service would receive:: | |
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
229 |
98 | 230 { |
231 "dicom-uid" : "123ABC", | |
232 "level" : "patient", | |
233 "method" : "get", | |
234 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8", | |
235 "token-key" : "hello", | |
236 "token-value" : "world" | |
237 } | |
238 | |
239 .. highlight:: text | |
240 | |
241 Note how the key and the value of the authentication token stored as a | |
242 HTTP header are forwarded to the Web service. | |
243 | |
244 The same mechanism can be used if the authentication token is provided | |
245 as some ``GET`` argument by setting the ``TokenGetArguments`` | |
246 configuration option:: | |
97 | 247 |
98 | 248 # curl http://localhost:8042/patients/6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8?hello=world |
249 { | |
250 "dicom-uid" : "123ABC", | |
251 "level" : "patient", | |
252 "method" : "get", | |
253 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8", | |
254 "token-key" : "hello", | |
255 "token-value" : "world" | |
256 } | |
257 | |
258 **Note 1:** It is allowed to provide a list of HTTP tokens or a list | |
259 of ``GET`` arguments in the configuration options. In this case, the | |
260 authorization plugin will loop over all the available authentication | |
261 tokens, until it finds one for which the access is granted (logical | |
262 disjunction over the authentication tokens). | |
263 | |
264 **Note 2:** The cache entry that remembers whether some access was | |
265 granted in the past, depends on the value of the token. | |
266 | |
267 **Note 3:** The support of authentication tokens provided as ``GET`` | |
268 arguments requires a version of Orthanc that is above 1.2.1. | |
97 | 269 |
270 | |
271 Full configuration | |
272 ------------------ | |
273 | |
98 | 274 .. highlight:: json |
275 | |
276 Here is the list of all the configuration options:: | |
97 | 277 |
98 | 278 { |
279 "Name" : "MyOrthanc", | |
280 [...] | |
281 "Authorization" : { | |
282 "WebService" : "http://localhost:8000/", | |
878 | 283 "WebServiceUsername": "my-user", // new in v 0.3.0 |
284 "WebServicePassword": "my-password", // new in v 0.3.0 | |
285 "WebServiceIdentifier": "my-id", // new in v 0.3.0 | |
98 | 286 "TokenGetArguments" : [ "user" ], |
287 "TokenHttpHeaders" : [ "hello" ], | |
893 | 288 "StandardConfigurations": [ // new in v 0.4.0 |
289 "osimis-web-viewer", | |
290 "stone-webviewer" | |
291 ], | |
98 | 292 "UncheckedResources" : [ |
293 "/series", | |
294 "/instances", | |
295 "/patients", | |
296 "/studies", | |
297 "/plugins/explorer.js", | |
298 "/system" | |
299 ], | |
300 "UncheckedFolders" : [ | |
301 "/app/", | |
302 "/web-viewer/app/", | |
303 "/web-viewer/libs/", | |
304 "/wsi/app/" | |
305 ], | |
893 | 306 "CheckedLevel" : "studies", // new in v 0.4.0 |
307 "UncheckedLevels" : [ | |
308 "patients", | |
309 "series", | |
310 "instances" | |
311 ] | |
98 | 312 } |
313 } | |
314 | |
315 The following options have been described above: ``WebService``, | |
316 ``TokenGetArguments``, and ``TokenHttpHeaders``. Here are the | |
317 remaining options: | |
318 | |
893 | 319 * ``StandardConfigurations`` is a helper configuration to pre-populate |
320 ``UncheckedResources``, ``UncheckedFolders``, ``TokenGetArguments``, | |
321 and ``TokenHttpHeaders`` of well-known plugins. | |
322 Allowed values are ``osimis-web-viewer``, ``stone-webviewer``. | |
323 | |
324 * ``CheckedLevel`` may replace ``UncheckedLevels`` when authorization | |
325 is checked only at one level of the DICOM hierarchy. This is the most | |
326 common use-case. | |
327 | |
98 | 328 * ``UncheckedResources`` specifies a list of resources for which the |
329 authentication plugin is not triggered, and to which access is | |
330 always granted. | |
331 | |
332 * ``UncheckedFolders`` is similar to ``UncheckedResources`` for folders: | |
333 Access to all the URIs below the unchecked folders is always granted. | |
334 | |
335 * ``UncheckedLevels`` allows to specify which levels of the | |
336 :ref:`DICOM hierarchy <model-world>` are ignored by the authorization | |
337 plugin. This can be used to reduce the number of calls to the Web | |
338 service. Think for instance about an authorization mechanism that | |
339 simply associates its studies to a set of granted users: In this case, | |
340 the series and instance levels can be ignored. | |
274 | 341 |
342 | |
893 | 343 Here is a minimal configuration for the :ref:`Stone Web viewer <stone_webviewer>`:: |
344 | |
345 { | |
346 // disable basic authentication since it is replaced by the authorization plugin | |
347 "AuthenticationEnabled": false, | |
348 | |
349 "Authorization" : { | |
350 "WebService" : "http://localhost:8000/shares/validate", | |
351 "StandardConfigurations": [ | |
352 "stone-webviewer" | |
353 ], | |
354 "CheckedLevel" : "studies" | |
355 } | |
356 } | |
357 | |
358 | |
274 | 359 .. _orthanc-explorer-authorization: |
360 | |
361 Integration with the Orthanc Explorer | |
362 ------------------------------------- | |
363 | |
364 Starting from Orthanc 1.5.8, you can pass authorization tokens in the url | |
365 search params when opening the Orthanc explorer i.e. | |
366 http://localhost:8042/app/explorer.html?token=1234. This token will be | |
367 included as an HTTP header in every request sent to the Orthanc Rest API. | |
368 It will also be included in the url search params when opening the Orthanc | |
369 or Osimis viewer. | |
370 | |
371 Only 3 tokens name will be recognized and forwarded: ``token``, ``auth-token`` | |
372 and ``authorization``. | |
373 | |
374 Please note that the Orthanc Explorer has not been designed to handle | |
375 the authorization so, when an authorization is not granted, it will simply | |
376 display an empty page or an error message. |