Plan for the next JHipster Gateway!

626 views
Skip to first unread message

Julien Dubois

unread,
Mar 31, 2017, 4:06:06 PM3/31/17
to JHipster dev team
Hi everyone,

So we talked a couple of months ago about the new JHipster Registry, and we followed this plan:


Some good news:

- My trainees Julien (Margarido) and Mohammed did a very good job
- We start to have something working fine, we should even be able to demo some stuff at Devoxx France next week
- So for me, in something like one month this should be released

So now, let's make a plan for the next generation of the gateway:

- Let's drop Cassandra as soon as possible: https://github.com/jhipster/generator-jhipster/issues/5388 -> if anyone wants to help, this should be some interesting piece of code
- JHipster UAA should be "out of beta", but as I just said to David on our Gitter chat, it's just that I'm not using it
- I'm going to see people from Keycloak next week, to make it work with JHipster - they are some kind of competitor to JHipster UAA, and at Ippon we've used it successfully for several projects
- Both JHipster UAA and Keycloak should allow us to drop most of our security configuration in the gateway

My plan is that:

- Our gateway could become totally stateless (if you don't use entities), and so much lighter and easier to use
- Better security: maybe we could keep the JWT token for "simple" architectures, but having OAuth2 tokens on the gateway is much more secured (and then we keep JWT tokens between the gateway and the microservices, so not much things change here)
- With the new Registry, the admin screens would also go to the registry, making it even lighter
- That would also prepare for Zuul 2, which won't work on a servlet container (it's directly based on Netty)

And of course, extra points if we migrate from REST/JSON to gprc for the gateway to microservices communication, using the great work from Christophe!

Are you all OK with that?

Julien

Gaël Marziou

unread,
Mar 31, 2017, 5:27:00 PM3/31/17
to JHipster dev team
- I'm going to see people from Keycloak next week, to make it work with JHipster - they are some kind of competitor to JHipster UAA, and at Ippon we've used it successfully for several projects
- Both JHipster UAA and Keycloak should allow us to drop most of our security configuration in the gateway

I've also started to use Keycloak at work with JHipster and Android apps.
I wanted to start it on my own but as I am slower than the team, I'd be happy to help.

I suppose your idea is to drop all user management from gateway, do you plan also to remove other pages like login, user registration, forgot password and edit profile pages?
If so, we could publish a JHipster theme for Keycloak.

For the moment, I have used the 2 java adapters from Keycloak:
- spring-boot-adapter to configure Keycloak client in application properties rather than using keycloak.json
- spring-security-adapter, for this one I'm not clear on the adavantages versus using spring-security-oauth

On Angular 2+ front, there are also some choices to make here, Keycloak team just started to deliver typescript on master, it should be released for 3.1 hopefully and makes our life easier.

Have you seen this proof of concept to embed Keycloak server in a spring boot app?

It could help to turn keycloak into an Eureka client as what David for uaa.

Cheers,
Gaël


Pierre BESSON

unread,
Mar 31, 2017, 6:04:04 PM3/31/17
to Julien Dubois, JHipster dev team
This sound like a great plan. I'm all for better security as I have heard of some issues with JWT.

About the future reactive gateway. The Netflix guys said they are going to release Zuul 2, however it's been a long time already and nothing is coming... So it seems to be an internal Netflix project for now (maybe it's too tied up with their internal stuff).

However, the good news is that the Spring team has started to work on their own reactive gateway which is based on Spring 5 : https://github.com/spring-cloud-incubator/spring-cloud-gateway 

So we could instead try to experiment with this to provide reactive microservices and gateways in the future.

Regards,
Pierre

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev+unsubscribe@googlegroups.com.
To post to this group, send email to jhipst...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jhipster-dev/CADNXADHoCAxkQgZkJBs0a96dUbz0ZP7g%3D6c-i9zbjCF8hiOsuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Julien Dubois

unread,
Apr 1, 2017, 2:45:29 AM4/1/17
to Pierre BESSON, JHipster dev team
Oh, I didn't have a close look at the "Spring Cloud Gateway", so this isn't based on Zuul? Indeed, I'm not totally happy with Zuul 1 as it uses a threaded model (it's a servlet filter, after all!), but it also allows for more features, etc...

Anyway: yes, moving away as many parts as possible from the gateway (which includes moving away the security part) will allow us to migrate more easily from Zuul 1, and this will happen at some point, as Zuul 1 won't evolve. Probably we will move to Zuul 2, but if they don't release anything soon we might move to Spring Cloud Gateway (if it's finished and stable), or something else.

Then, there are still some very "JHipster specific" things that will need to happen on the Gateway: I had a quick look at the request throttling code from Spring Cloud Gateway, and they took the other library I looked at, which is much simpler. Now I want to use Bucket4J because it has Hazelcast support, and thanks to the JHipster Registry we can scale Hazelcast clusters -> this is typically a very "JHipster specific" feature, and in my mind I have many other use cases like this one.

Julien
--
Julien Dubois

Deepu K Sasidharan

unread,
Apr 1, 2017, 3:57:24 AM4/1/17
to Julien Dubois, Pierre BESSON, JHipster dev team
Sounds like a great plan. +1

It would be nice to make the gateway lighter.  Since most of you have said what I wanted to say I'm not gonna say it again :)


Thanks & Regards,
Deepu

David Steiman

unread,
Apr 1, 2017, 5:21:43 AM4/1/17
to Deepu K Sasidharan, Julien Dubois, Pierre BESSON, JHipster dev team
Hi guys,

I am happy to read the UAA is moving forward to going out of beta. I'm pretty sure everyone knows my position to that, as I propagated to move it as default security solution recently. People are asking, why it's beta and if it is production ready. I think it is, as it stateless and inter-operable with other solutions using OAuth 2.0. Last week I plugged a ten years old PHP legacy app behind our JHI Gateway, bringing authorization to that application using well known OAuth2 flows. It took me about half an hour to get it done :D
 
@Julien, we can choose some date as it is comfortable to you, where I just can answer all questions you might have with UAA and show all the things inside the box, if that makes it easier. If we find some "bad" or "incomplete" stuff with the current state, I could fix it ASAP. 

I have no experience with keycloak, but as you said, with UAA and keycloak we would have a stateless and scalable microservice experience.

For that plan, lets do it! +1

greets
David


To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.



--
Julien Dubois

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.

Julien Dubois

unread,
Apr 4, 2017, 2:23:55 AM4/4/17
to David Steiman, Deepu K Sasidharan, Pierre BESSON, JHipster dev team
Thanks David!
Sorry but I won't be available this week because of Devoxx, but yes we need to talk about JHipster UAA and Keycloak. Don't you see Keycloak as a competitor, or maybe even a replacement?

Julien

To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev+unsubscribe@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.



--
Julien Dubois

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev+unsubscribe@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev+unsubscribe@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.

David Steiman

unread,
Apr 4, 2017, 4:44:07 PM4/4/17
to Julien Dubois, Deepu K Sasidharan, Pierre BESSON, JHipster dev team
sorry for the late response....i'm as usual totally stuck in work

don't hurry for this....I want to have a calm time to do this with you outside of devoxx-release insaneness.  As I said, pick a date comfortable to you...

To answer your questions:

is keycloak a competitor? considering it would be that integrated as uaa is, with angular (here...both ng1 and ng2), user auth setup for users AND client setups for the apps, than yes it is.
I took a veeeery quick look at it today (I just have the same experience with keycloak as Julien with JHopster UAA :-D ), and it is very promising. As all the connecting parts are done upon standards, it should be more or less like plug and play with keycloak, as everything relies on OAuth 2. 

is keycloak a replacement? I say not, as JHipster UAA gives the user a fully customizable application, which is like a normal JHipster microservice, talking in OAuth 2. So you get a standardized security solution, where you still can do own stuff. Like extending the Users domain with very related stuff, like a Customer in a Store. I do that in my workshop sample from microXchg.

for me, this is comparable to the "JHipster Registry vs Hashicorp Consul" scenario, where one can take a "origin" JHipster solution (with UAA you can even more do that, rather in JHI Registry) and a competiting battle proofed solution to the rescue.

We should offer both: customization next to support of great tools, like Consul and Keycloak...IMHO

Greetings!

To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.



--
Julien Dubois

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "JHipster dev team" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhipster-dev...@googlegroups.com.

To post to this group, send email to jhipst...@googlegroups.com.

Gael Marziou

unread,
Apr 4, 2017, 6:47:18 PM4/4/17
to jhipst...@googlegroups.com
Hi David,

Your comparison with Registry vs Consul makes a lot of sense to me.

Differences between uaa and keycloak in terms of impact on JHipster:

- server-side: keycloak provides 2 libs spring-boot-adapter for configuration through application.properties, spring-security-adapter which populates
SecurityContext with Principal and Authorities. For me, it would make sense to keep the config part and I'm not sure whether spring-security-adapter
could be totally replaced by spring-security-oauth so that it could be same code as for uaa.

- client side: keycloak provides a small npm module keycloak-js which is able to work in both a browser or a cordova mobile app. I think we should
build an angular service wrapper around it because it includes some logic to build an auth request (for instance there is a nonce parameter that
should be generated for each request like a CSRF id), parse response, ...

I'll share some repo hopefully this week end.

Cheers,
Gaël


Gaël Marziou

unread,
Apr 18, 2017, 6:10:15 PM4/18/17
to JHipster dev team
Here is my repo about Keycloak integration, so far there's only an example of microservice


Required modifications are described in README:


I'll add another example with an ng4 app and also realm definition

Cheers,

Gaël

Gaël Marziou

unread,
Apr 20, 2017, 9:08:10 AM4/20/17
to JHipster dev team
Some comments from Stephen Doxee on my repo as he can't post on this group:

https://github.com/gmarziou/jhipster-keycloak/issues/2

Reply all
Reply to author
Forward
0 new messages