Advanced authorization plugin dicomweb-plugin issue

[Alexandru_Mihai_Vut1]

Hello,

I am using the advanced authorization plugin for orthanc that call “in-house” REST API to check authorization, based on Token header value.
Over dicomweb-plugin, this works ok for:

• http://127.0.0.1/dicom-web/studies/1.2.826.0.1.3680043.8.1055.1.20170626100116652.756727516.6235062/series

but not for metadata endpoint (403 htp code):

• http://127.0.0.1/dicom-web/studies/1.2.826.0.1.3680043.8.1055.1.20170626100116652.756727516.6235062/series/1.2.826.0.1.3680043.8.1055.1.20170626100129209.175732410.1148676/metadata

The same token is used for all requests.

Based on documentation page, to avoid http calls for each level I have:

• AUTHZ_UNCHECKED_LEVELS=[“patient”, “series”, “instances”]

I tried to add metadata also, but it seems that it’s not a part of DICOM hierarchy.

In my orthanc console I found a strange message: “A validity duration cannot be negative”

What is validity duration message? Is about authorization plugin? My REST API is returning 200 HTTP code for token validation.

Thanks!

[jodogne]

I copy/paste here a message that was not properly handled by Google Groups:

Alexandru Mihai Vuta verso.930@gmail.com 17 August 2020 at 15:35

"Hi,

Fixed, before I used orthanc 1.5.x version. After upgrading to 1.7.2, authorization plugin do not accept anymore negative values for validity field (inside reponse object).
Now I have another issue that I think is a BUG in advanced authorization plugin.

Using DICOM-WEB plugin, the ADVANCED AUTHORIZATION PLUGIN is not able to secure metdata`s endpoint.
So I have this request made by OHIF viewer over DICOM-WEB plugin, asking for metadatas (got 403):

Authorization was provided via ‘Token’ header.

Authorization endpoint was called by ORTHANC with these information:

Obviously, my service was not able to allow this request because dicomUid is null. I think that studies/xxx/series/xxx/metadata endpoint is not a part of DICOM hierarchy.
How can I handle this issue?

Thanks!"

[jodogne]

My answer: Please provide a minimal working example so that other people can understand and reproduce your issue:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example

[Alexandru_Mihai_Vut1]

Ok, here is a demo project that simulate what I am trying to accomplish in production: https://github.com/alexvuta/orthanc-authorization-service-demo

Finally I understand how this thing works:

• if requests are made on /dicom-web/studies/*** endpoint, authorization plugin will provide ‘dicom-uid’ information in POST payload:
  curl -v -H ‘Token: demo’ -H ‘Content-type: application/json’ http://localhost:8044/dicom-web/studies/1.2.826.0.1.3680043.8.1055.1.20170626100116652.756727516.6235062

• if requests are made on /dicom-web/studies/***/metadata, no dicom-uid information will be provided in POST payload:
  curl -v -H ‘Token: demo’ -H ‘Content-type: application/json’ http://localhost:8044/dicom-web/studies/1.2.826.0.1.3680043.8.1055.1.20170626100116652.756727516.6235062/metadata

But, here it is not able to get dicom-uid information and we have uri information in payload to make authorization decisions based on url (e.g. get uid from provided url)
I don’t get the reason why, since is on the same path (studies)

However, in my example you can reproduce this based on README instructions.
I hope that my github example projec will be usefull for somebody one day.

Thanks!

Pe luni, 17 august 2020, la 21:13:01 UTC+3, s.jo...@gmail.com a scris: