broken archive interface when using LDAP user federation

[Jonathan Brooks]

Dear Vrinda,

Following the instructions for secure archive and RESTful services leads to a situation where it is not possible to access the archive (401 Unauthorized).

I think I've tracked the source of this down to a missing role for user and admin, which is *not* automatically assigned to these new users when they are imported via LDAP user federation.

After initially creating the realm there are ?no users, but there are 3 roles generated automatically (default-roles-dcm4che, offline_access, uma_authorization).

We import 3 new users via sync with LDAP server:

At this point we then import roles, again syncing with LDAP.

the five imported roles can be seen as they don't have an associated description.

When looking at the role assigned to each user they are as follows:

User

Admin

Root

You'll note that none of them have the role default-roles-dcm4che assigned to them.

Without adding the role "default-roles-dcm4che" to either of the users: user or admin  it is not possible to interact with the archive web interface. I.e. after logging in, I see no information on the standard landing page, and receive a 401 Unauthorized error when choosing an option from the left hand menu icon.

I don't know if this is some peculiarity of installation on Ubuntu, but I have reproduced this configuration issue multiple times (each time starting with a complete reinstall of keycloak and wildfly). In every repeated install, adding the role default-roles-dcm4che fixes the problem.

I also tried removing/purging openldap and reinstalling to confirm that it wasn't an issue with a "failed" import of the original .ldif files. None of the imports reported any failure. Again the problem persisted.

Not sure if anyone else has encountered this problem, but I have seen some threads talking about 401 Unauthorized, so might be worth exploring??

Hope this helps.

Best,

Jon

[Deeps]

Hi Jon,

             I am also facing the same issue. Getting 401 Unauthorized when accessing the dcm4chee-arc/ui2. After manually correcting the role-mappings I am able to access the archive.

Did you find any solution for this issue?

Thanks & Regards,

Deeps.

[Jonathan Brooks]

Hi Deeps,

Glad to hear it wasn't just me!

I'm really not sure why the default role wasn't being added... I assumed that the LDAP import must have gone wrong somewhere, so perhaps related to repeating the installation where I would leave mySQL and openldap in place, delete the dcm4che-arc-ui folder then start again.. it's likely that I missed a step.

Glad it worked for you too!

Cheers,

Jon

--
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/Nra91rQlGNo/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/6c3cb960-ba50-466e-b9cf-0c6501b1799en%40googlegroups.com.

[Vrinda Nayak]

I have already answered before w.r.t. default-roles-dcm4che in https://groups.google.com/g/dcm4che/c/OV6sFEtjo-g/m/TYGWMBejBAAJ

Whether you use manual setup (choosing LDAP user federation and syncing users/roles from LDAP) / dockerized setup (which automatically uses LDAP user federation), there is no requirement for assigning default-roles-dcm4che

[Deeps]

Hi Vrinda,

             I have followed the steps as given in the link https://github.com/dcm4che/dcm4chee-arc-light/wiki/Secure-Archive-UI-and-RESTful-Services-using-Keycloak#ldap-configuration-and-keycloak-user-federation for configuring ldap.  I have attached the screenshots of role-mappings of admin and unauthorized message that I am getting when accessing dcm4chee-arc/ui2 using admin. 

If I am adding default-roles-dcm4che to assigned roles, then I am able to access dcm4chee-arc/ui2 application without any issues.

Thanks & Regards,

Deeps.

[Vrinda Nayak]

Which version of keycloak and archive are you using? And I'm assuming you've used a non-dockerized installation.

[Deeps]

Yes Vrinda,  I am using a non-dockerized installation.  I am using dcm4chee-arc-light 5.26.0, keycloak 15.0.2 and wildfly 24.0.1.

[Jonathan Brooks]

HI Vrinda,

I am using dcm4chee-arc-light 5.25.2, keycloak 15.0.2 and wildfly 24.0.1.

(on Ubuntu 20.04.4 LTS)

Is there something weird about keycloak 15.0.2?

Best wishes,

Jon

[Vrinda Nayak]

I have not tested keycloak 15.0.2. There is currently an open issue to document manual installation with Keycloak 18.x, however I have run into some issues regarding certificates. Please, if possible, it's recommended to use dockerized setup which is faster and easier to install and maintain. Keycloak 18.x with archive 5.26.1 has been tested with docker and works seamlessly. See

- https://github.com/dcm4che/dcm4chee-arc-light/wiki/Run-secured-archive-services-on-a-single-host

- https://github.com/dcm4che/dcm4chee-arc-light/wiki/Run-secured-archive-services-and-Elastic-Stack-on-a-single-host

- https://github.com/dcm4che/dcm4chee-arc-light/wiki/Upgrade-Keycloak-on-Docker

[Jonathan Brooks]

Hi Vrinda, dcm4chee team,

FYI the secure install instructions specifically recommend using keycloak 15.0.2 (here) - which is fine, I'm just grateful that the instructions are there! Thank you!

One reason for not going with the dockerized version is that I found it more difficult to interface with the file system (passing folders to the container and getting everything to match internally); networking within the constraints of our environment was also really tricky. 

It's really interesting that you also found issues when using certificates - which I assumed would be more straightforward with a manual install? Is there anything you could share about the problems you're facing as this is definitely something I've encountered too? I was never able to get the final deployment to work with either (1) self-signed certificate, or (2) a certificate that was signed by our authority provider.

My latest thinking was that there was something in the dcm4chee-arc-light JAVA application that was referring to the distributed self-signed cert (J4Care), that was in conflict with anything I tried to use during the build? Would love to be able to get a solution to this, so please let me know if I can help in any way.

Best wishes,

Jon

[Vrinda Nayak]

Until I have resolved https://github.com/dcm4che/dcm4chee-arc-light/issues/3698, I've updated the manual secure archive installation wiki page to reflect Keycloak's last official distribution powered by Wildfly (16.1.1) - prior to Keycloak Quarkus distribution (starts with 17+ versions of Keycloak, wherein Wildfly distribution are depracated).

There is a known issue in Keycloak, whereby default account client specific client roles do not get assigned to the created users. To overcome this, there is an additional manual step required to assign these.

Note : default-roles-dcm4che Realm role is not required to be mapped to the users!! Please see the updated notes and screenshots.

[Aloïs Dreyfus]

Hi,

With the docker version of dcm4chee-arc-psql:5.25.2-secure-ui (with dcm4che/keycloak:16.1.1), I also get a blank interface when logging in with a user I created ("newuser").

Adding the default-roles-dcm4che role to "newuser" in keycloak solves the problem: the interface becomes functional when I log in with "newuser".

Thanks for the tip.

[Vrinda Nayak]

As mentioned in the last post - the resolution of issue is not to add default-roles-dcm4che to the new / existing users. Instead, mapping of account Client roles manage-account and view-profile is what's needed due to known issue in Keycloak.

Keycloak images (14+) released / used by Dcm4chee 5.x archive, contains an init-account script to do this automatically. However, if you're upgrading from a version of Keycloak older than 14.0.0 (which does not have this issue) to a higher version of Keycloak (equal to or newer than 14.0.0), you need to add account client roles to the users using add-account script provided in the images. All this has been explained in Upgrade Keycloak on Docker wiki - specifically see Upgrade Steps based on previous LDAP version / DB backend section.

[Jonathan Brooks]

Hi Vrinda,

Thanks for updating the installation instructions. Unfortunately they are not working for me.

FYI I'm *not* upgrading from an earlier keycloak version. I'm starting on a vanilla install with keycloak 15.0.2, dcm4chee-arc-ui-5.25.2 (secure/mysql).

I'm not sure if the keycloak init-account script is being run automatically (?), but adding account client roles is not working for me.

Here is the output from my install

Can I check if I'm supposed to select all the the Available Roles (e.g. manage-account-links, manage-consent etc etc) and then click "Add Selected"?

If I do this (select all available roles) then press add selected, only three roles can be assigned (see output below):

E.g. it is not possible to assign manage-account to the user root.

FYI I'm logged in with the admin/admin account on the keycloak admin console

Hope this helps?

Best wishes,

Jon

[Vrinda Nayak]

The notes about init-account and add-account script were replied to Aloïs Dreyfus user as he used this same email thread to point out his findings with dockerized version of the setup. In the note before his, I have already written about updates to the wiki page and screenshots using Keycloak 16.1.1 / Wildfly 26.1.1 showing mapping of account client roles to each individual default users - root / admin / user

I referenced the notes and screenshots in its own section, so that it is clearer - independent of whether you choose to use LDAP User Federation or manually create users and roles.

See Manually fix account client role mappings to users

[Jonathan Brooks]

Hi Vrinda,

So I'm using Keycloak LDAP User Federation to import users (admin, root, user = 3), roles (ADMINISTRATION, admin, auditlog, root, user = 5) and client roles -> realm-management (create-client, impersonation, etc, etc = 19).

Your instructions for mapping the account client roles to each user is not working (for me) with Keycloak 15.0.2 - see my previous email. 

FYI I've included screenshots of the default Realm Roles (and what appears under the Client Roles (account) by default):

What happens e.g. if I select "manage-account" and Add selected >>

NOTE: says Success, but nothing added!!!

What happens if I try to access the archive interface without manage-account/view-profile in the Effective Roles.

Result = 

The only way I've found to make my Client Roles (account) look like the example from your updated instructions is to select default-roles-dcm4che from the Realm Roles - which then adds the necessary Effective Roles - and hey presto - I can access the archive... this is completely reproducible (for me).

Result = 

Not sure what I'm doing differently! Are there any negative implications for selecting default-roles-dcm4che?

Best wishes,

Jon

[Vrinda Nayak]

Sorry, but I can't invest time for an older pre-Quarkus distribution from Keycloak. The one I documented in wiki is the most recent of versions of Keycloak standalone (pre-Quarkus) - 16.1.1

As for

- Are there any negative implications for selecting default-roles-dcm4che?

I might have mentioned multiple times now in several different posts that this role assignment should not be required. We have never used it in any of our customer installations. I can't be debugging and commenting on something that is not of relevance / usage. You may choose to take this up directly on Keycloak Discussions.

[Jonathan Brooks]

Hi,

No it's okay - I wasn't expecting you to fix this (!), I just wanted to bring it to your attention and for others facing similar problems.

For those setting out on building a secured archive what are your current recommendations (software versions known to work)? 

Historically, I had some problems with getting a containerized version to run, so this was my motivation to try to build from scratch. Can this be done using Quarkus versions of Keycloak? Sorry if I've missed this information/discussion.

Best wishes,

Jon