Viewers: Implementing access control

[TZubiri]

Is there a possibility to restrict the access to resources when sharing an OHIF link?

Currently, if I share a link to a hosted image, the user can go to the study list and see all images. Even if I were to remove the link from the viewer, or block the study-list URL. The user can still access the developer console and get unrestricted query capabilities to my PACS server.
For my use case, the user should only have access to the images he has the URL for (if the instance UIDs don't provide enough entropy, then I an extra hash should be added to the URL, or the resource should be protected by an authentication scheme.

Is there any functionality out of the box that OHIF supports that I am missing? Is there any way to deactivate the escalation of priviliges in OHIF viewer, or must I switch to the Standalone version?

Thank you.

[TZubiri]

I'll switch to the standalone js implementation and delegate access control to an external server. I haven't figured out the exact specifics, but I think this should be possible.

[dannyrb]

I'll switch to the standalone js implementation and delegate access control to an external server.

This is the only secure way to handle this. Anything client side is just security through obscurity. We're adding some documentation in the near future that covers how to implement server-side access control using open source libraries and docker. I don't believe "Share URLs" are slated anytime soon.

[dannyrb]

👋 Hi @TZubiri, now that v2 is released we do have some better documentation on an identity/auth setup here: https://docs.ohif.org/deployment/recipes/user-account-control.html

The recipe is specific for access to the entire viewer/pacs, but Keycloak does support more granular control, scopes, etc. This should be a good enough starting point if you want to pursue Share URLs or something similar. You should be able to do something like:

• Per study, give the option for the user to "turn on share urls"
• Create a long, secure-enough-for-your-purposes, token (ideally, one that expires)
• Add a react + viewer route that excepts the token
  
  
  
  • If valid, don't redirect for oidc
  
  
  • On all outgoing PACS requests, include token
  
  
• Add nginx listener block that allows access to the PACS for the matching study if the token is valid

^ That may not be fully baked, but hopefully gives some guidance on one possible approach.