search

jhipster / generator-jhipster-quarkus

Quarkus blueprint for JHipster
https://www.jhipster.tech/blueprints/quarkus/
Apache License 2.0
141 stars 56 forks source link

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

Open ebihimself opened 3 years ago

ebihimself commented 3 years ago

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):

mraible commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

ebihimself commented 3 years ago

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 commented 3 years ago

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

mraible commented 3 years ago

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 commented 3 years ago

Added bug bounty to get this fixed.

GeraldScott commented 3 years ago

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:

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.