dcm4chee PACS - how to trace ownership of dicom studies in multitenant situation.

[David Simic]

Hi folks,

I'm contemplating a setup of dcm4chee in a multitenant situation hosted in the cloud.

However, I'm puzzling over how to track the ownership of the studies back to the original clients. I need a fail proof method, one which does not rely on client generated UIDs. Presumably it would be something similar to how one establishes an authenticated session in a website with the extra plumbing that attributes user generated content to the correct authenticated user  - from the server-side.

I'm aware of the dicom security feature but not entirely sure it's the preferred way, what the best practices in using it would be for my setup, or what pitfalls I may encounter when I start hooking it up to real-world modalities.

Any thoughts on the best way to track ownership while keeping everything within the same server / db?  (P.S. I need everything in the same place for some of the features I am envisioning.)

Best & thanks,

David

[David Simic]

A few notes:

Looking at the database schema for dcm4chee, I see that the "aet" field of the ae table is constrained to be unique.

So presumably by creating a separate table which maps ae.aet to individual customer accounts, I'm almost almost there.

Furthermore, looking at the series table, there is a field called "src_aet," which would presumably allow me to further map each series, and hence each study, to a customer account as well.

Unfortunately there are two problems with this: 1) series.src_aet is not constrained to be non-null, 2) nor is this field an actual foreign key to the unique field ae.aet, and so it is not guaranteed to be meaningful. Thus it isn't clear if correlating via ae.aet and series.src_aet is a viable strategy, or what extra steps could be taken to make it one (ie: fail safe correlation of studies to customer accounts).

The dicom security service could conceivably fix the above, assuming that it indeed guarantees series.src_aet == ae.aet. Does anybody know if it does? I will likely give this a shot soon if I can’t think of something better. However even if it works, I'd definitely still interested to hear if someone has an alternate approach ...

[David Simic]

Update:

I went ahead a configured dicom security for my dcm4chee instance. Now anyone trying to store a dicom archive requires a username and passcode.

Via the jmx console, I have also set the parameter dcm4chee.archive:service:CallingAETitle to "CONFIGURED_AETS," to restrict calling AETs to the ones added explicitly to dcm4chee. Clients now must use a pre-registered AET title, instead of being able to invent their own. So far so good!

However here's the hitch: I do not see anyway to restrict the AET used by the client to the client (ie: assign ownership of an AET to a client account). Ie: Any client with valid login credentials and assigned role "AET" can use any AET they want, including those intended for other clients, as long as the AET is preregistered with DCM4CHEE. So this does not allow a fail proof way of tracking study ownership back to a single account / customer.

Is there any way to restrict use of AETs to specific user accounts? Or is there perhaps an alternate approach to accomplishing what I want ...?

Best,

D

[Rob McLear]

On systems where I want to do this, I typically set the client AET to include a random string at the end, which essentially ensures no one will be able to guess another AET registered in the system. i.e. AET=WORKSTATIONB2DPCdY2  . Obviously if users have access to multiple client workstations they could just copy down the AET and use it at another location, but it does provide some barrier to AE spoofing. 

-Rob

[David Simic]

Hi Rob,

Thanks for the input! If I can't find something more fail-safe, I will likely go this route.

Another thought I'm considering is setting up some kind of intermediate gateway which can set the right AET on the fly based on user credentials, however I'm not sure how feasible this is here.

Best,

David

[Rob McLear]

I was also thinking about this from the opposite direction; you could give each client workstation a unique AET for the PACS (i.e. PACS-XYZPDQ) and configure that PACS to only accept studies based on specific called AETs. I believe the called AET is stored with each incoming study but I’m not sure of that.

-Rob

> --
> You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/iZet6wDF_ME/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.
> To post to this group, send email to dcm...@googlegroups.com.
> Visit this group at https://groups.google.com/group/dcm4che.
> For more options, visit https://groups.google.com/d/optout.

[BRIT]

Rob,

The only way of ensuring multi-tenancy using CalledAET (at least using DCM4CHEE v2.x - I've yet to investiage v4) is to set up a file system for each tenant, which (IMHO) would be the way to go anyway.

[Rob McLear]

I had not thought of that. Have you implemented this? I’m curious to know what would need to be done to have the separate file systems running in parallel.

-Rob

[BRIT]

I've had notes all over the place Rob but this weekend I intend on getting them all together (I'm writing up some internal documentation) and this will be one of them.  I'll let you know how I get on.

[Fabio Filocomo]

Hi!

I am facing the same problem that you faced in 2016. Were you able to resolve this issue?

I also ask, how did you set up user and password for AET?

[Fabio F]

Hi BRIT. How did you solve this problem?

[Romain Paturet]

Hello. Any updates on this topic ?