Adding User entity enhancement management

[fcauchois]

User is a special entity, pre-generated and needed by jhipster as a core entity. Actually, every relation to User is working great (you can add relation from an entity to User) but every relation from it, or new attribute are ignored. This is due to the actual entitygenerator who use template to create (or update) assets for the new entity.

I figure out and try 2 ways to improve that :

• create a new 'UserManaged' entity related to the standard 'User' entity. We use this entity to manage our relation and add a small helper to retrieve it from the real User : no jhipster modification is required as it's just a tip.
• simply modify both command line and uml generator to proceed User entity and create a special treatment in entity generator process (entity/index.js) to generate User.java, thanks to a dedicated template (merge btw app\templates\src\main\java\package\domain_User.java and entity\templates\src\main\java\package\domain_Entity.java) and the liquibase patch. Every other steps are ignored, thus those relations and fields are only available through the domain class.

The second solution ca be improve by many ways, so the question is : do jhipster need to manage this special User generator, then we can work on a pull request, or the first solution (using a separated UserXXX entity to handle needed relation or attributes) is enought ?

Or other way we did'nt see ?

[pnreddysvu]

one hint to add any number of new attributes to user entity. The SSO project from JBoss Keycloak(http://keycloak.jboss.org/) handled the same case very well. I think we should inspire from that solution.

[fcauchois]

Wasn't aware of that project, sound very good and cover most of common use case we need when speak about A&A, but need a lot of work to be integrated in jhipster, isn't it (first time i use a question tag in my whole life :D) ? To be planed for jHipster 3 ?

One thought : if the User.java core class become simply an extends of a 'JHIUser' like abstract class that come with all actuel User property, it can be easily update through the entity generator process (with only one modification : add the correct extends when matching User name entity - and adapting user management sreen to dynamically add new relations/attributes) ?

[pnreddysvu]

Yes it is really a great project but very few people know this(may be less publicity). Till last week I was thinking that Cloud Foundry UAA was the best A&A project but after going through KeyCloak, UAA is nothing in front of that.

I dont think integrating with JHipster is difficult. They have Spring-boot adapter. https://github.com/keycloak/keycloak/tree/master/integration/spring-boot

[pnreddysvu]

JHIPSTER DEV Team: just have a look at https://www.youtube.com/watch?v=5MQoJZKXM_s I feel it is worth to consider KeyCloak instead of UAA for micro service architecture. It is a JBoss project having 7 dedicated developers and very active community.

[jdubois]

I still have to see if we need such a server: we already have built-in OAuth2 support, so maybe we could just have a JHipster server that is the OAuth2 server.

In a microservices architecture, we would have a front-end router, and then all other REST endpoints would be behind this router: we don't really need an SSO server for this. Maybe the other endpoints would not be secured, or be secured differently. I also need to work on this part, and this is part of the current on-going "micro-services" effort (yes I need to communicate more on this, but this is very early).

Then, if such a server is needed, I'd like to have a look at all the alternatives, including CAS, which is the biggest and most used SSO server. Clearly I agree with you, UAA is not ready yet.

Concerning Keycloak in particular:

• 300 Github stars isn't much to me, we have 10 times more! I'm always reluctant to use such projects, which are not well-known enough, but of course it depends on the context, we have already done this in the past
• Yes I know that's a Redhat project. We already use a lot of Redhat technologies (Hibernate, MapStruct...), so no problem with this
• I had a look at their development team, and in particular there is @patriot1burke in it, whom I remember from the early JBoss days (when you had to pay to have the JBoss manual, who remembers that weird idea?), and yes that's cool to have those people behind the project

One option would be to have a Keycloak module in JHipster, if that ever makes sense: have you had a look at our marketplace yet?

[pnreddysvu]

understood. keycloak module make sense. Lack of proper documentation and examples are the reasons for not gaining popularity. Otherwise it is a great project. I will try integrating in my free time.

[gmarziou]

I did not know about CAS, it's very interesting. I'll have a closer look.

[fcauchois]

Implementing external login to existing service (such as ldap) or even SSO (like CAS, reverse proxy, etc) is not big deal, really. And adding it to a jhipster can but done manually in a few hours... ! If the need is ton implement that kind of server, builtin, that's, for me, not a JHI core concern (more a markeplace one however).

But remember this issue is much more simple : adding some data logic to the User, cause Database Model are designed to ensure data validity, and 90% of the time, this will need relation from and to the User wich is "usually" involve in business transaction :D.

My question, wich can be quiclky solved, is : do i need to stick to my first idea (adding a related User class that handle that new logic, ez but ugly) or update the entity generator to allow some logic to be added to the Core User Jhipster entity (i did a try to this idea, and it's working fine, but can only apply if it follows JHI DEV TEAM plan and will be integrated as standard use case, otherwise i will not continue on that way) ?

[fcauchois]

Last word for short term : we use the UserXX tricks.

Issue can be close as incoming news must precise future on next jHipster Meetup in Paris !

[magick93]

Hello

I would really like to see Keycloak integrate with JHipster. Is anyone interested in working on this? I am new to JHipster, but am help to help on this task.

[pnreddysvu]

@magick93 I am interested to work on this. But I can do only back end work. I am not a front end developer.

[magick93]

@pnreddysvu - Keycloak has its on frontend. Basically, when the user needs to login the should be redirected to keycloak for auth, then redirected back. Keycloak also has a user management UI.

[pascalgrimaud]

@magick93 @pnreddysvu : there was a discussion here https://github.com/jhipster/generator-jhipster/issues/2465 about keycloak Maybe someone has begun to work on this module...

[pnreddysvu]

@pascalgrimaud It is good if someone has started. @magick93 I know keycloak provides user management. But many changes required in Jhipster front end code. I am talking about that part.

[pascalgrimaud]

@pnreddysvu : not sure someone has begun this module, maybe locally? Because I don't see repository about it ;)

[magick93]

@pnreddysvu - ok. Well, I probably have the least experience in Jhipster of anyone. I only learned about JHipster about 2 hours ago.

[pnreddysvu]

Below things to be done to integrate with keycloak

1) Split current monolithic Jhipster app into two apps 1) Client app(front end app) 2) Server app 2) Remove user management, login, social login from both front end and backend 3) Secure both backend and frontend with keycloak 4) Enable relationship between new entities and keycloak entities

[pascalgrimaud]

Some work was already done par Deepu here : https://github.com/jhipster/generator-jhipster/pull/2613 There should be a new option : --skip-client

[magick93]

Keycloak has a federation spi - which means it can auth user based on an existing 3rd party db.

So you dont necessarily need to remove the jhipster backend. You can create a sync between keycloak and jhipster.

Keycloak will also sync. Keycloak can get all users from Jhipster.

Then, you can, for example, enable social login, and this will create an account based on, say facebook, in both keycloak and jhipster.

Keycloak can also manage mapping and combining of accounts, for when, say, a jhipster account already exists and user logs in with facebook.

On Tue, Jan 19, 2016 at 10:30 AM, pnreddysvu notifications@github.com wrote:

Below things to be done to integrate with keycloak

1) Split current monolithic Jhipster app into two apps 1) Client app(front end app) 2) Server app 2) Remove user management, login, social login from both front end and backend 3) Secure both backend and frontend with keycloak 4) Enable relationship between new entities and keycloak entities

— Reply to this email directly or view it on GitHub https://github.com/jhipster/generator-jhipster/issues/2538#issuecomment-172790331 .

[pnreddysvu]

That leads to completely duplicate tasks and mess up things. It will be nightmare to maintain the code. This is my personal opinion. Please don't get offended.

[magick93]

@pnreddysvu - you will have to try harder to offend me :)

By using the JHipster database it allows users who already have users to switch to keycloak, and not need to migrate.

I guess my point is, there are many ways of using Keycloak. So we should decide how and what we want to get from it.

[pnreddysvu]

Ok let me clarify you few things.

1) Jhipster provides user management and keycloak also provides user management. To work seamlessly you need two way replication. If you create user in Jhipster it should be replicated back to keycloak and vice versa. If you change password through keycloak interface that has to be synced again back to jhispter db.

2) Keyclaok user can have different fields and jhipster user can have different fields. You will not get one to one mapping.

3) Keycloak supports multi tenancy through realm. Similar thing is not possible through jhipster. You cannot utilize that feature at all. 4) Keycloak provides social login and jhipster too. Those too will conflict again.

[magick93]

Ok, yes that does clarify things.

Does jhipster use Spring Security?

[pnreddysvu]

yes jhipster uses spring security.

[magick93]

Im not sure if this helps -the documentation is a bit light - http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#spring-security-adapter

[pnreddysvu]

yes that is the way to go. here is the working sample. https://github.com/foo4u/keycloak-spring-demo

[deepu105]

Im not an expert on Oauth and Im not familiar with keyclock. But reading above I can talk only from JHipster perspective.

The comments above about works to be done to integrate keyclock with Jhipster is too drastic and will break a lot of our current options, so Im not sure its worth the effort given it doesnt achive much in value compared to current implementation. It might make sense in a microservice architecture which @jdubois is exploring and there is a discussion going on that here

So If someone wants to do this as a Module that is more than welcome and we will try to help in ways we can, plz open new issues to add any additional needles or methods required. But I dont think we will be adding this to the normal Jhipster generator for now.

So as per thread openers comment Im closing this. we can continue any discussion on keyclock here

PS: But If you need to use Jhipster to generate a backend and then use a keyclock and different front end you can use the new --skip-client option for that. Im doing the same to have a React + Spring app generator based on Jhipster here take a look if required

[magick93]

I dont know anything about writing jhipster modules, but would really like to see keycloak work with jhipster.

Can someone please provide a highlevel list of tasks on what would be needed to make keycloak work with jhipster as a module, then I can give it a go.

[deepu105]

use our https://github.com/jhipster/generator-jhipster-module module generator to generate a skeleton, refer docs here https://jhipster.github.io/modules/creating-a-module/

Thanks & Regards, Deepu

On Wed, Jan 20, 2016 at 2:26 PM, magick93 notifications@github.com wrote:

I dont know anything about writing jhipster modules, but would really like to see keycloak work with jhipster.

Can someone please provide a highlevel list of tasks on what would be needed to make keycloak work with jhipster as a module, then I can give it a go.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/generator-jhipster/issues/2538#issuecomment-173108197 .

[pnreddysvu]

@deepu105 I agree with you. keycloak make sense if we go with micro services approach. I would expect one thing from you if you are willing to help here.

instead of --skip-client use option like --separate-client and if used generate two apps 1) client app and 2) server app.

It will be useful for microservices as well as keycloak integration. You can ignore client if you want to use react client.

[deepu105]

That will be too much of if else on the generator and bit of work to do and we are not going that direction atleast for now based on earlier discussions we had, this might change in the future based on demand and how the microservices architecture goes.

Btw I have a question for you. What do you consider a separate client app? to me the current client is almost like a separate angular app, the only thing is that everything is deployed as a single package.

Thanks & Regards, Deepu

On Wed, Jan 20, 2016 at 3:01 PM, pnreddysvu notifications@github.com wrote:

@deepu105 https://github.com/deepu105 I agree with you. keycloak make sense if we go with micro services approach. I would expect one thing from you if you are willing to help here.

instead of --skip-client use option like --separate-client and if used generate two apps 1) client app and 2) server app.

It will be useful for microservices as well as keycloak integration. You can ignore client if you want to use react client.

— Reply to this email directly or view it on GitHub https://github.com/jhipster/generator-jhipster/issues/2538#issuecomment-173112283 .

[pnreddysvu]

There are at least three use cases now.

1) Micro services:

• Depending on load you can scale only client or only server
• You can implement client load balancing using Ribbon

2) Keycloak integration specific

• REST API will be secured with bearer-only so that you can implement own client and expose API to 3 rd parties
• clients will be secured with confidential/public depending on client type

3) Production deployment

-- most of the enterprise applications will be deployed in 3 tier architecture