Mercurial > hg > orthanc-book
annotate Sphinx/source/plugins/authorization.rst @ 311:0078d465c768
note
| author | Sebastien Jodogne <s.jodogne@gmail.com> |
|---|---|
| date | Tue, 04 Feb 2020 17:18:02 +0100 |
| parents | c310a795c133 |
| children | 84e3a2612c36 |
| 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 |
|
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
4 Advanced authorization plugin |
|
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
5 ============================= |
|
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 |
| 16 <https://bitbucket.org/osimis/orthanc-authorization>`__ is freely | |
| 17 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 |
|
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
27 for every UNIX-like distribution (including GNU/Linux):: |
|
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" : { | |
| 55 "WebService" : "http://localhost:8000/" | |
| 56 } | |
|
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
57 } |
|
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
58 |
|
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
59 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
|
60 configuration file. |
|
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
61 |
| 97 | 62 |
| 63 Web Service | |
| 64 ----------- | |
| 65 | |
| 66 This section describes how a Web service suitable for the | |
| 67 authorization plugin can be designed. | |
| 68 | |
| 69 **Note:** The behavior described in this section is implemented by the | |
| 70 ``AuthorizationWebService`` C++ class in the source code. It is | |
| 71 possible to define a different authorization back-end by deriving | |
| 72 from interface ``IAuthorizationService``. | |
| 73 | |
| 74 | |
| 75 Incoming request | |
| 76 ^^^^^^^^^^^^^^^^ | |
| 77 | |
| 78 For each HTTP/REST request that Orthanc receives, the plugin will | |
| 79 issue a set of HTTP ``POST`` requests against the Web service that is | |
| 80 specified in the configuration file (in the basic configuration file | |
| 81 above, the Web service listening at ``http://localhost:8000/`` is | |
| 82 used). The body of each of those ``POST`` requests is a JSON file | |
| 83 similar to the following one:: | |
| 84 | |
| 85 { | |
| 86 "dicom-uid" : "123ABC", | |
| 87 "level" : "patient", | |
| 88 "method" : "get", | |
| 89 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8" | |
| 90 } | |
| 91 | |
| 92 In this example, the user is accessing an URI that is related to some | |
| 98 | 93 DICOM resource, namely a patient whose DICOM identifier is |
| 94 ``123ABC``. In such a case, the following fields will be set in the | |
| 95 JSON body: | |
| 97 | 96 |
| 97 * The ``level`` field specifies which type of resource the user is | |
| 98 accessing, according to the :ref:`DICOM model of the real world | |
| 99 <model-world>`. This field can be set to ``patient``, ``study``, | |
| 100 ``series``, or ``instance``. | |
| 101 * The ``method`` field specifies which HTTP method is used by the | |
| 98 | 102 to-be-authorized request. It can be set to ``get``, ``post``, |
| 103 ``delete``, or ``put``. | |
| 97 | 104 * The ``dicom-uid`` field gives the :ref:`DICOM identifier |
| 98 | 105 <dicom-identifiers>` of the resource that is accessed. If the |
| 97 | 106 resource is a patient, this field contains the ``PatientID`` DICOM |
| 107 tag. For a study, it contains its ``StudyInstanceUID``. For a | |
| 108 series, it contains its ``SeriesInstanceUID``. For an instance, it | |
| 109 contains its ``SOPInstanceUID``. | |
| 110 * The ``orthanc-id`` field gives the :ref:`Orthanc identifier | |
| 111 <orthanc-ids>` of the resource. | |
| 112 | |
| 113 When the user accesses a lower-level resource in the DICOM hierarchy | |
| 114 (a study, a series or an instance), the authorization plugin will | |
| 115 issue one separate call to the Web service for each level of the | |
| 116 hierarchy. For instance, here are the 3 successive requests that are | |
| 117 issued when accessing some series:: | |
| 118 | |
| 119 { | |
| 120 "dicom-uid" : "123ABC", | |
| 121 "level" : "patient", | |
| 122 "method" : "get", | |
| 123 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8" | |
| 124 } | |
| 125 { | |
| 126 "dicom-uid" : "1.3.51.0.1.1.192.168.29.133.1681753.1681732", | |
| 127 "level" : "study", | |
| 128 "method" : "get", | |
| 129 "orthanc-id" : "6e2c0ec2-5d99c8ca-c1c21cee-79a09605-68391d12" | |
| 130 } | |
| 131 { | |
| 132 "dicom-uid" : "1.3.12.2.1107.5.2.33.37097.2012041612474981424569674.0.0.0", | |
| 133 "level" : "series", | |
| 134 "method" : "get", | |
| 135 "orthanc-id" : "6ca4c9f3-5e895cb3-4d82c6da-09e060fe-9c59f228" | |
| 136 } | |
| 137 | |
| 138 It the user is accessing a URI that is not directly related to an | |
| 139 individual DICOM resource, the JSON body will look as follows:: | |
| 140 | |
| 141 { | |
| 142 "level" : "system", | |
| 143 "method" : "get", | |
| 144 "uri" : "/changes" | |
| 145 } | |
| 146 | |
| 147 In such a situation, the following fields are set: | |
| 148 | |
| 149 * The ``level`` field is always set to ``system``. | |
| 150 * The ``method`` field is the same as above. | |
| 151 * The ``uri`` field provides the URI that was accessed by the user. | |
| 152 | |
| 153 **Important note:** The plugin will transparently parse the URIs of | |
| 154 the core :ref:`REST API of Orthanc <rest>`, of the :ref:`Web viewer | |
| 155 plugin <webviewer>`, of the :ref:`DICOMweb plugin <dicomweb>`, and of | |
| 156 the :ref:`whole-slide imaging plugin <wsi>`. Unrecognized URIs (such | |
| 157 as those introduced by other plugins) will be handled as a ``system`` | |
| 158 call. It is possible to introduce parsing support for more plugins by | |
| 159 modifying the ``DefaultAuthorizationParser`` C++ class in the source | |
| 160 code of the plugin. | |
| 161 | |
| 162 | |
| 163 Expected answer | |
| 164 ^^^^^^^^^^^^^^^ | |
| 165 | |
| 166 The Web service must answer by sending a JSON file that tells whether | |
| 167 the access is granted or not to the user. Here is a sample answer:: | |
| 168 | |
| 169 { | |
| 170 "granted": true, | |
| 171 "validity" : 5 | |
| 172 } | |
| 173 | |
| 174 Here is a description of these two fields: | |
| 175 | |
| 176 * ``granted`` tells whether access to the resource is granted | |
| 177 (``true``) or not granted (``false``). In the case the user is | |
| 98 | 178 accessing a DICOM resource, the access to *all* the levels of the |
| 179 hierarchy above this resource must be granted (logical conjunction | |
| 180 over the levels). | |
| 97 | 181 * ``validity`` tells the authorization plugin for how many seconds the |
| 182 result of the Web service must be cached. If set to ``0`` second, | |
| 183 the cache entry will never expire. | |
| 184 | |
| 185 **Note:** The source code of the plugin contains a `basic example | |
| 186 <https://bitbucket.org/osimis/orthanc-authorization/src/default/Resources/TestService.js>`__ | |
| 187 of such a Web service written in node.js. | |
| 188 | |
| 189 | |
| 190 Authentication tokens | |
| 191 ^^^^^^^^^^^^^^^^^^^^^ | |
|
96
750f7ab733c1
start documentation of authorization
Sebastien Jodogne <s.jodogne@gmail.com>
parents:
diff
changeset
|
192 |
| 98 | 193 It is obviously desirable to limit access to the resources depending |
| 194 on the user that is logged in. Real-life Web framework such as Django | |
| 195 would send the identity of the authenticated user either as an HTTP | |
| 196 header, or as an additional argument for ``GET`` requests. The | |
| 197 authorization plugin allows to forward these authentication tokens to | |
| 198 the Web service. | |
| 199 | |
| 200 To configure the authentication plugin to use some HTTP header, one | |
| 201 must provide the option ``TokenHttpHeaders`` the configuration file of | |
| 202 Orthanc as follows:: | |
| 203 | |
| 204 { | |
| 205 "Name" : "MyOrthanc", | |
| 206 [...] | |
| 207 "Authorization" : { | |
| 208 "WebService" : "http://localhost:8000/", | |
| 209 "TokenHttpHeaders" : [ "hello" ] | |
| 210 } | |
| 211 } | |
| 212 | |
| 213 .. highlight:: text | |
| 214 | |
| 215 In such a situation, if some HTTP client issues the following call:: | |
| 216 | |
| 217 # curl -H 'hello: world' http://localhost:8042/patients/6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8 | |
| 218 | |
| 219 .. highlight:: json | |
| 220 | |
| 221 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
|
222 |
| 98 | 223 { |
| 224 "dicom-uid" : "123ABC", | |
| 225 "level" : "patient", | |
| 226 "method" : "get", | |
| 227 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8", | |
| 228 "token-key" : "hello", | |
| 229 "token-value" : "world" | |
| 230 } | |
| 231 | |
| 232 .. highlight:: text | |
| 233 | |
| 234 Note how the key and the value of the authentication token stored as a | |
| 235 HTTP header are forwarded to the Web service. | |
| 236 | |
| 237 The same mechanism can be used if the authentication token is provided | |
| 238 as some ``GET`` argument by setting the ``TokenGetArguments`` | |
| 239 configuration option:: | |
| 97 | 240 |
| 98 | 241 # curl http://localhost:8042/patients/6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8?hello=world |
| 242 { | |
| 243 "dicom-uid" : "123ABC", | |
| 244 "level" : "patient", | |
| 245 "method" : "get", | |
| 246 "orthanc-id" : "6eeded74-75005003-c3ae9738-d4a06a4f-6beedeb8", | |
| 247 "token-key" : "hello", | |
| 248 "token-value" : "world" | |
| 249 } | |
| 250 | |
| 251 **Note 1:** It is allowed to provide a list of HTTP tokens or a list | |
| 252 of ``GET`` arguments in the configuration options. In this case, the | |
| 253 authorization plugin will loop over all the available authentication | |
| 254 tokens, until it finds one for which the access is granted (logical | |
| 255 disjunction over the authentication tokens). | |
| 256 | |
| 257 **Note 2:** The cache entry that remembers whether some access was | |
| 258 granted in the past, depends on the value of the token. | |
| 259 | |
| 260 **Note 3:** The support of authentication tokens provided as ``GET`` | |
| 261 arguments requires a version of Orthanc that is above 1.2.1. | |
| 97 | 262 |
| 263 | |
| 264 Full configuration | |
| 265 ------------------ | |
| 266 | |
| 98 | 267 .. highlight:: json |
| 268 | |
| 269 Here is the list of all the configuration options:: | |
| 97 | 270 |
| 98 | 271 { |
| 272 "Name" : "MyOrthanc", | |
| 273 [...] | |
| 274 "Authorization" : { | |
| 275 "WebService" : "http://localhost:8000/", | |
| 276 "TokenGetArguments" : [ "user" ], | |
| 277 "TokenHttpHeaders" : [ "hello" ], | |
| 278 "UncheckedResources" : [ | |
| 279 "/series", | |
| 280 "/instances", | |
| 281 "/patients", | |
| 282 "/studies", | |
| 283 "/plugins/explorer.js", | |
| 284 "/system" | |
| 285 ], | |
| 286 "UncheckedFolders" : [ | |
| 287 "/app/", | |
| 288 "/web-viewer/app/", | |
| 289 "/web-viewer/libs/", | |
| 290 "/wsi/app/" | |
| 291 ], | |
| 292 "UncheckedLevels" : [ "study" ] | |
| 293 } | |
| 294 } | |
| 295 | |
| 296 The following options have been described above: ``WebService``, | |
| 297 ``TokenGetArguments``, and ``TokenHttpHeaders``. Here are the | |
| 298 remaining options: | |
| 299 | |
| 300 * ``UncheckedResources`` specifies a list of resources for which the | |
| 301 authentication plugin is not triggered, and to which access is | |
| 302 always granted. | |
| 303 | |
| 304 * ``UncheckedFolders`` is similar to ``UncheckedResources`` for folders: | |
| 305 Access to all the URIs below the unchecked folders is always granted. | |
| 306 | |
| 307 * ``UncheckedLevels`` allows to specify which levels of the | |
| 308 :ref:`DICOM hierarchy <model-world>` are ignored by the authorization | |
| 309 plugin. This can be used to reduce the number of calls to the Web | |
| 310 service. Think for instance about an authorization mechanism that | |
| 311 simply associates its studies to a set of granted users: In this case, | |
| 312 the series and instance levels can be ignored. | |
| 274 | 313 |
| 314 | |
| 315 .. _orthanc-explorer-authorization: | |
| 316 | |
| 317 Integration with the Orthanc Explorer | |
| 318 ------------------------------------- | |
| 319 | |
| 320 Starting from Orthanc 1.5.8, you can pass authorization tokens in the url | |
| 321 search params when opening the Orthanc explorer i.e. | |
| 322 http://localhost:8042/app/explorer.html?token=1234. This token will be | |
| 323 included as an HTTP header in every request sent to the Orthanc Rest API. | |
| 324 It will also be included in the url search params when opening the Orthanc | |
| 325 or Osimis viewer. | |
| 326 | |
| 327 Only 3 tokens name will be recognized and forwarded: ``token``, ``auth-token`` | |
| 328 and ``authorization``. | |
| 329 | |
| 330 Please note that the Orthanc Explorer has not been designed to handle | |
| 331 the authorization so, when an authorization is not granted, it will simply | |
| 332 display an empty page or an error message. |