Roll-out-create failure with openid connect

[slv-009]

Hi all.

I would appreciate some assistance / guidance with regard to a hawkbit / keycloak (openid connect) integration. In summary, we’ve built a hawkbit server and using a reverse proxy for ssl termination, and using gateway authentication (ddi) for now. The next step, a keycloak instance was added to manage / authenticate users, all users created in keycloak for now. Initially it all seemed to be working well. We have however come across an issue with regard to creating rollouts, when logged in to hawkbit with a keycloak user.. all the functions with regard to create, delete, update targets, distributions and artifacts is working as expected, except creating a new rollout. When creating a new roll-out, it fails to complete, and remains in the creating state on the GUI.

The following error appears in the logs:
o.e.h.r.jpa.JpaSystemManagement: Exception on forEachTenant execution for tenant DEFAULT with error message [No such user]. Continue with next tenant.

If the new rollout is deleted the, it deletes successfully.

If the hawkbit configuration is changed and keycloak auth is removed (revert to direct login) the rollout can be created and deployed successfully.

In order to remove as many components as possible, the above was rebuilt in a lab and consists of a hawkbit install from sources, using an external mariadb, and then a keycloak docker, also using an external mariadb. All connections (hawkbit & keycloak) are http on port 8080.(Seperate ip’s) If the keycloak is removed, and logging directly into hawkbit, the roll-out can successfully be created.

The following roles / permissions have been added to the keycloak user for this hawkbit client:
APPROVE_ROLLOUT, CREATE_REPOSITORY, CREATE_ROLLOUT, CREATE_TARGET, DELETE_ROLLOUT,
DELETE_REPOSITORY, DELETE_TARGET, DOWNLOAD_REPOSITORY_ARTIFACT, HANDLE_ROLLOUT,
READ_REPOSITORY, READ_ROLLOUT, READ_TARGET, READ_TARGET_SECURITY_TOKEN,
ROLLOUT_MANAGEMENT, TENANT_CONFIGURATION, UPDATE_REPOSITORY, UPDATE_TARGET,
UPDATE_ROLLOUT, SYSTEM_ADMIN,

And various combinations of the above have been attempted without success.

Any assistance will be appreciated!

Hopefully I've missed something simple!
Please let me know if any other information is required.

[camal-cakar-gcx]

Any updates on this questions and the solution to it?

[camal-cakar-gcx]

Hi,
I investigated this behaviour and found out that the In-Memory User Management is trying to get the user by nameand this is where things crash(cc @bogdan-bondar). As I am using OIDC for my authentication (with Keycloak), I didn't setup any users by hand via the multiUserProperty and an explicit spring.security.user.name.

I found a working example here #966

What is correct setup to authenticate users via an Authentication Provider and give to a few the rights to create a Rollout?

[slv-009]

Hi,
The above scenario was tested with 0.3.0M6. I recall running a test in *October 2020 (*Need to verify) using master and the behaviour was improved, to confirm I'll re-configure this test scenario using current master and confirm the behaviour by end of this week. Thank you all for looking at it.

[schabdo]

@slv-009 Indeed implementation improved quite a bit. Any update on this?

[schabdo]

@camal-cakar-gcx InMemoryUserManagementAutoConfiguration should not be involved in an OIDC setup if it is configured properly. So no need for configuring any users on hawkBit side

[slv-009]

@schabdo

Firstly, apologies for the late response.

I reconfigured my test scenario as set out initially, and this time using 030M6, it works perfectly, so I can confirm that any changes have been effective and resolved what I experienced above.

Really appreciate the great effort here. Thank you. I'll close this for now.

[schabdo]

Never mind! Same over here: Occasionally distracted by my day to day job which require some time to answer. Nevertheless glad to see you happy with hawkBit and the recently made changes

[camal-cakar-gcx]

Hi,
I can't confirm this. I am running hawkbit/hawkbit-update-server:0.3.0M6-mysql and still am unable to create a rollout. Hawkbit Instance is running since 12 days. Keycloak is used for OIDC and is used for all users to login. Maybe a permission is missing? I will revisit my configuration.

[slv-009]

@camal-cakar-gcx , Im running on a VM and built from sources as I need the S3 extension, I havent tried it with the docker. My initial test scenario Begin August 2020 had the scenario.

This week I deleted the hawkbit folder, ran a fresh "git clone" and "mvn clean install", applied the application.properties file and it works perfectly.

The only difference that was obvious on the GUI is the save icon under the system config menu.

Aug 2020

Last week

[camal-cakar-gcx]

Thanks @slv-009 that is clarifying why it is working for you :) My context is running Hawkbit within Kubernetes connected to Keycloak for OIDC. So I am relying on the latest pushed Container Image.

On a side note, I see the old save image. Maybe it is time for a new Container Image tag?

[schabdo]

On a side note, I see the old save image. Maybe it is time for a new Container Image tag?

Definitively! I'm almost done with the paperwork for the upcoming 0.3.0M7. Hope to get a fresh version out of the door next week or at least the week after ... so stay tuned