Microservice without user management shall not generate User and Authority entities as well as related resources

[ko5tik]

Overview of the feature request

When "skipUserManagement": true is set for microservice, User and Authority entities as well as supporting classes and services are generated even is there is no use for them at all. And when 0Auth is used as login option there is no management of user information at all in the application.

I suggest skipping generation of those classes unless they are explicitely requested ( say, when application uses JWT or session
and those artifact are going to be managed in one of the microservices which has this option enabled explicitely )

Motivation for or Use Case

Those unused entities pollute database schema and mapping files and namespaces , and this confuse developers and managers.
This leads to extra work to remove them form codebase upon each regeneration. And this clearly sucks and lowers acceptance of jHipster as tool.

Related issues or PR

none found yet

• [ч] Checking this box is mandatory (this is just to show you read everything)

[ko5tik]

Looking into the sources:

    {
      condition: generator => generator.authenticationTypeOauth2,
      path: SERVER_TEST_SRC_DIR,
      templates: [
        {
          file: 'package/service/UserServiceIT.java',
          renameTo: generator => `${generator.testDir}service/UserServiceIT.java`,
        },
      ],
    },

In my unterstanding authenticationTypeOauth2 means that authentication is outsourced to some external provider ( keycloak, okta , whatever ) . This there will be no real user data in the application - so there is no point to have this servince at all

[ko5tik]

Another observation:

{ condition: generator => !generator.skipUserManagement, path: SERVER_MAIN_RES_DIR, templates: ['templates/mail/activationEmail.html', 'templates/mail/creationEmail.html', 'templates/mail/passwordResetEmail.html'], },

Activation email templates and user related exceptions are skipped when no user management

[mshima]

Duplicate of #16074.

[ko5tik]

Which is also mine but did not received attention. This one is more specific though.
I would like to have some discussions with commiters about those user entities and whether they are really necessary
in this case

From my point of view it looks as if there were some mixed up boolean conditions.

[mraible]

They exist so you can have relationships to the User entity in your microservices. We might change things to use SCIM in the future.

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

[ko5tik]

I know that I can make relationship to User entity. But I do not need to. In my opinion, when I do not have user management in the backend microservice ( "skipUserManagement": true set explicitely, oauth2 authentication selected ) there shall be no user entity in this microservice at all (and also authority and supporting classes)

Current version generates user entities for all microservices in the application - which is kind of redundant anyway.

Frontends do not generate user entitites just DTOs - which kind of makes sense to exract user data from auth tokens an deliver it to frontend code.

[mshima]

@ko5tik can you provide a PR making user entities conditional on user relationship existence?

[ko5tik]

Conditionality shall be on "skipUserManagement" option and there is definitely an issue that user entities are generated in all microservices in case there are more than one.

Only scenario where relationship with to user entity makes sense for me is monolith with session or jwt authentication - in this case users are managed inside the app, emails are sent etc.

Will work on pull request.

[Tcharl]

If we follow the advice of both of you , thus only generating user in this cases:

• Session
• Jwt
• Relationship to user

We would be able to remove that 'skipusermanagement' in V8, WDYT?

[mshima]

It will still be needed for public services with no user management. Unless it makes sense to create authenticationType no.

[mshima]

Conditionality shall be on "skipUserManagement" option and there is definitely an issue that user entities are generated in all microservices in case there are more than one.

User must be generated if User relationship exists at oauth2 authenticationType.
Removing this feature is a unjustified breaking change is not on discussion for JHipster 7 and probably won’t happen for v8.

IMO the best approach is to introduce a new configuration like proxyUsersForRelationships.
And some files will depend on it and others will depend on it or skipUserManagement.

[ko5tik]

User must be generated if User relationship exists at oauth2 authenticationType. Removing this feature is a unjustified breaking change is not on discussion for JHipster 7 and probably won’t happen for v8.

In oauth2 real user / authority entity used for authentication resides somewhere else ( if it exists at all ) - what exactly is this generated user entity in context of microservice? At the moment it is just an entity ( actually 2 ) without any special meaning, which is neither populated not synched with anything and serves no real purpose.

There are no relatioships over the microservice boundary - so it there is no user management ( and this option is generated by default for the microservice / 0auth ) there shall be no user - as this is done for the frontends

[Tcharl]

I had the use case on one project: I made kind of a Project catalog for my company's InnerSource initiative.
Thus, I had a microservice, hosting the list of projects my company implemented, and the User who was the originator of the project (it's oauth2 handle) was the only one being able to edit his project's informations.
How could I achieve that without storing the user Oauth identity? RBAC through group wasn't possible (project list was dynamic), could have used another class to achieve the same thing for sure (called OAuthUser :-p), with a lot of custom code, but would have it be cleaner?

[ko5tik]

I had the use case on one project: I made kind of a Project catalog for my company's InnerSource initiative. Thus, I had a microservice, hosting the list of projects my company implemented, and the User who was the originator of the project (it's oauth2 handle) was the only one being able to edit his project's informations. How could I achieve that without storing the user Oauth identity? RBAC through group wasn't possible (project list was dynamic), could have used another class to achieve the same thing for sure (called OAuthUser :-p), with a lot of custom code, but would have it be cleaner?

In a similar situation I used user principal as a field in "owned" object (which is available to the services via securoty utils) to check of accessibility of certain object for invocation / filtering lists. Of course I had to create separate methods. I surely could have extra entity and relationships for this purpose - but this entity would have nothing to do with real authentication, and will have to be synched with real database anyway.

My proposal is not to generate those user entities if it is explicitly specified that they are not desired (skip user management = true - which is default for microservices anyway)

[ko5tik]

So looking deeper into issue - actual sources skip generation of user entities for microservice or 0auth authentication - but only when called as "jhipster entitites" . when invoked as just "jhipster" those config settings are not honored.

[ko5tik]

After some debugging I discovered strange thing:

    if (
      this.configOptions.sharedEntities.User ||
      (this.jhipsterConfig.skipUserManagement && this.jhipsterConfig.authenticationType !== OAUTH2)
    ) {
      return;
    }

( bootstrap/index.js @ 219 )

@Tcharl @mshima : can you comment of this? This line forces user entity generation for all microservices with 0auth
event if it is explicitely disabled ( but not when using other auth options ) - looks kind of weird for me

And disableIUserManagemt is set to true for microservices by default anyway.....

[Tcharl]

dono

[mshima]

can you comment of this? This line forces user entity generation for all microservices with 0auth

This is expected.
User is always generated for relationship. We should make it conditional on user relationship existence.

[ko5tik]

This is expected. User is always generated for relationship. We should make it conditional on user relationship existence.

It is already conditional ( skipUserManagement ) for everything but oauth2 - I do not grok this logic. Actual state is: all backend microservices get user/authority entities generates whether they need it or not when Oauth2 is activated ( not needed by default ) when "app" generator is invoked ( "jhipster" ) , but not when "jhipster entitites" is invoked.

[mshima]

About the oauth2 + User relationship, ideally:

• UserService used for oauth2 should split. The UserService used for userManagement should not be used.
• User entity should be generated like any other with an additional service.
• Should be generated only when needed or add an option.

[Tcharl]

What about generating the User service when this statements are in jdl:

• A relationship exists to User
• a idl entity called User is specified, any field within this entity will be appended in addition to default one.

[github-actions]

This issue is stale because it has been open for too long without any activity.
Due to the moving nature of jhipster generated application, bugs can become invalid.
If this issue still applies please comment otherwise it will be closed in 7 days

[mshima]

We should implement this to simplify and reduce generated files.

[mshima]

@DanielFran bug bounty claimed https://opencollective.com/generator-jhipster/expenses/211710.

[DanielFran]

@mshima approved