jhi_user table doesn't create a newly made user created by keycloak

[ebihimself]

Describe the bug
I have enabled user registration in the keycloak. But after registering new users, the jhi_user table does not receive new users created in keycloak.

To Reproduce
Steps to reproduce the behavior:

1. Generate a new Quarkus application using the "jhipster-quarkus."
2. Add keycloak as the stateful authenticator
3. Once you're in keycloak, you can edit your Realm settings > Login > activate user registration,
4. Navigate to the login page, click on the "Register" button
5. Submit the form with dummy user data
6. Check jhi_user table and keyclock users. They are not equal!

Expected behavior
I expect to receive created new user in the jhi_user table after a successful registration.

Desktop (please complete the following information):

• OS: ubuntu 20.04
• Browser chrome
• Version 89.0.4389.128

[mraible]

In the main generator, the user is synced with the JHipster database when the user logs in.

It works, but it's not an excellent solution. A better solution would be to implement SCIM.

https://developer.okta.com/docs/concepts/scim/

Unfortunately, Keycloak doesn't support it yet.

https://stackoverflow.com/q/58566587/65681

[ebihimself]

In the main generator, the user is synced with the JHipster database when the user logs in.

It works, but it's not an excellent solution. A better solution would be to implement SCIM.

https://developer.okta.com/docs/concepts/scim/

Unfortunately, Keycloak doesn't support it yet.

https://stackoverflow.com/q/58566587/65681

So, should the jhipster-quarkus behave in the same manner as the main Jhipster generator does? I mean, should it create a new user after their first login?

[mraible]

If you have a better solution that works with Keycloak and Okta, I'd love to hear about it.

[ebihimself]

If you have a better solution that works with Keycloak and Okta, I'd love to hear about it.

I wondered about keeping everything about users in the keycloak and using soft relations to relate application entities and users.

My initiation thinking is something like the application that must tie every single order to a user. Instead of creating the jhi_user table, syncing keycloak data, and relating with orders through a foreign key, we can store the user's UID coming from the keycloak for the relevant orders. And query the users by keycloak programmatic access (restful API).

I would like to know your opinion about this.

[ebihimself]

By the way, the functionality to create users after their first login seems not to work properly.

[mraible]

Instead of creating the jhi_user table, syncing keycloak data, and relating with orders through a foreign key, we can store the user's UID coming from the keycloak for the relevant orders. And query the users by keycloak programmatic access (restful API).

I implemented things the way I did so developers could just use JPA (or NoSQL, or whatever they're using) and not have to deal with REST calls to the OAuth identity provider. Especially since identity providers might implement things differently and we'd have to add logic for Keycloak, Okta, Auth0, Microsoft, etc. Also, OIDC has no standard way to query an IdP for all the users, so it'd be difficult to add a list of users to dropdowns.

By the way, the functionality to create users after their first login seems not to work properly.

It works in the main generator, so if it doesn't work in the Quarkus blueprint, that's a bug IMO.

[mraible]

Added bug bounty to get this fixed.

[GeraldScott]

I don't have a solution (well, not yet, but I am working on it) but note that it is helpful to separate the problem into two concerns:

• management of personal information, which is application-specific, and
• identity and access management which is the domain of OIDC

Trying to get the IDP to manage personal information as well as login information conflates the concept of the user as a person with the concept of a user login. They are not the same. The OIDC data is a subset of the user's personal information.

I am working on an application that checks jhi_user after a successful login. If the user does not exist, I enrol them with the basic OIDC details, then prompt them to complete the rest of their personal information. No syncing with the IDP.