Documentation for DCM4CHEE 5

[Peter Bihacsi]

Hi, 

Is there any available extensive documentation for version 5? The wiki is really not useful if someone start from zero knowledge.
For example, simple tasks like limit access for remote AET by AE Title is not covered anywhere in the wiki. (https://github.com/dcm4che/dcm4chee-arc-light/wiki/Access-control-based-on-Archive-AEs this content is really not helping)
Could someone please pointing to the right direction?

Cheers,
Peter

[CPaiva]

Hello,

Maybe you problem can be solved using  Accepted Calling AE Title(s) Attribute.

You can find this Attribute using UI:

Config->Device->dcm4chee-arc->Child Objects->Network Aes->DCM4CHEE->Extensions->Network Ae Extension->Edit Extension->Attributes->"Accepted Calling AE Title"

Now just insert accepted AETs. If it is leave blank, all Aets will be accepted (default).

[Peter Bihacsi]

Hi,

Thanks for taking time to reply. I realised, I wasn't very precise when phrased the question. Also, let me extend the original question.

If I have clients that use DICOM protocol to connect to the pacs, I want to setup role based access control for studies by AET. In other words, I want to ensure, remote AET only can access to certain studies. I figured, I can add access control id for AET and tag the study in the DB. But the question is how can manage access by remote AET  without modifying the AET in osirix each time. This is not covered in the wiki at all. It might be not a feature any longer. It was in the old version if I understood correctly.

Also...

I deployed a secured version and set up keycloak. All works as expected. But, I'm facing the same problem, that how can I configure role based access to studies?

Many thanks

--
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/aGu0lzez6q8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/1ac9c320-393a-4d50-b03e-866cd738b35fn%40googlegroups.com.

 

[Gunter Zeilinger]

dcm4chee-arc 5.x does not support to configure Calling AET specific Access Control beside general rejection of a particular peer AE from connecting a particular AE provided by the archive. That is compliant with DICOM PS 3.15 H.1.1.2. Network Application Entity: "A Network AE is an application entity that provides services on a network. A Network AE will have the same functional capability regardless of the particular network connection used. If there are functional differences based on selected network connection, then these are separate Network AEs. If there are functional differences based on other internal structures, then these are separate Network AEs."

So the DICOM compliant solution supported by dcm4chee-arc-5.x is to configure separate Archive AEs for different access policies and configure to restrict the peer AEs from which associations are accepted by them to a specific  list of Calling AETs.

[Peter Bihacsi]

Hi Gunter,

Thanks for taking time to reply.

Perhaps DICOM protocol changted since dcm4chee 2.X as I found this was implemented https://dcm4che.atlassian.net/wiki/spaces/ee2/pages/2556087/Configuration+of+Study+Permissions+Role+Based+Access+Control . 
Does it mean, DicomWeb also doesn't support RBAC too? If so, what's the point for user authentication if unique user credentials are not used in permission controls?
I'd be very surprised if RBAC is not implemented based on URL control in DicomWeb (https://www.dicomstandard.org/dicomweb/query-qido-rs/), but it's not mentioned anywhere in the project wiki.

Thanks and regards

To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/4af8f045-5f6c-407b-aae3-428ba9948e36n%40googlegroups.com.

--

Peter Bihacsi

Senior IT Systems Administrator

Registered office St John's Innovation Centre, Cowley Road, Cambridge.  CB4 0WS

www.vet-ct.com | Peter.Bihacsi@vet-ct.com

               

 

This communication and the information that it contains is intended for the person or organisation named above and for no other person or organisation and may be confidential and protected by law. Unauthorised use, copying or disclosure of its contents may be unlawful. If you have received this communication in error, please contact us immediately on the email or postal address given above. This email and any attachments are believed to be free of any virus, or any defect, which might affect any computer system into which they are received and opened. No responsibility is accepted by Vet CT Specialists Ltd. for any loss or damage arising in any way from receipt or use thereof. All emails sent and/or received by Vet CT Specialists Ltd. may be monitored and/or stored for monitoring purposes. 

 

[Gunter Zeilinger]

DICOM delegates specification of access control to other standards, particularly Kerberos, SAML or JSON Web Tokens (Open ID Connect).
Future versions of dcm4chee-arc may support Open ID Connect based access control via HTTP (=dicomWeb) and DICOM Upper Layer Services more fine granted access policy than current version, which only checks if the authorized user in the token has assigned a particular Keycloak user role. Such implementation may be aligned to IHE Internet User Authorization Profile (IUA)

[Peter Bihacsi]

Thanks Gunter for the confirmation of the current state of the project. I understand this is not implemented yet.

Is there any workaround? Can I assigning multiple access_control_id to study? Apparently, study <-> Access control ID relationship is 1 to 1, is this correct?
I'm just trying to find a way to assign one study for multiple user without make them changes which AET they are connecting to. Is there a way to manage access to study by the user/caller AET in dcm4chee-arc-light?

Cheers,

[Gunter Zeilinger]

study <-> Access control ID relationship is 1 to 1, but one Archive AE can grant access of studies with different access control IDs (Access Control ID(s) is multi-valued)

[Peter Bihacsi]

But it means, the user need to change the AET every time, they need to access other studies. For eg.: 
User A and User B has access to Study 1 and Study 3 but should have no access to Study 2.
User C need  should have access to Study 2 and Study 1 but no access to anything else.
User B need should have access to Study 4 too.
No one can access to anything else apart above.
In this very small permission scenario, I need to setup 3 new AET and User B and User C must switch between AETs to gain access to those studies. Also, I cannot prevent users to change the well known AET to gain access to studies  they shouldn't have access to.
With hundreds of studies and many radiologist with different access, this is an administration nightmare. I understand the old 2.X version delivers this RBAC based on user AET. My we know why was this removed from the new version? 

Thanks and regards,

[Gunter Zeilinger]

No. Typically there are just a handful of access control policies in use in a particular domain - we never needed the flexibility that each study may have its own individual access policy assigned.

[Gunter Zeilinger]

As a simple example. If you have remote AEs which shall only have access of Studies of one category and other remote AEs which shall only access Studies of a different category, and other remote AEs which shall be able to access both, you need 2 Access Control IDs and 3 Archive AEs.