Jhipster using OpenIDConnect (OIDC) instead of internal UAA

0
votes

Can anybody point me in a direction for configuring the jhipster gateway to use an external OpenID Connect (OIDC) provider instead of bundling all the UAA stuff? I know of the jhipster UAA server, but that seems to be a standalone auth server.

My use case is that my (many) different jhipster microservice projects will have their authentication and JWT generation stuff handled by an external OIDC provider - not the jhipster gateway itself.

Btw, I'm aware of these projects:

github.com/jhipster/jhipster-openid-connect
github.com/sdoxsee/jhipster-openid-connect-microservices

And I've read through this lengthy discussion which seems to conclude that and OpenId Connect alternative is in the making: https://github.com/jhipster/jhipster-experimental-microservices/issues/3

I have some ideas:

  1. Set up a microservices stack to use the UAA server. Then, in some way, instead of using the jhipster UAA server, point at my external OIDC provider.

  2. Look at what mraible has done with regards to the Stormpath (and soon to come Okta) subgenerator.

  3. Experiment with "social logins"(jhipster.github.io/tips/012_tip_add_new_spring_social_connector.html)

Would anybody like to discuss?

1
jhipsterspring-cloudopenid-connect
Totally on board with this. I think the main issue is the user domain model that jhipster uses is almost always different from what an identity provider would use. You'd need adapt your provider's user model to the jhipster model. There are standard ways of representing user models (e.g. scim) that some identify providers support. Maybe jhipster should adopt scim to make this easier. - sdoxsee
The other question is what flows to generate. Implicit, hybrid or authorization code flows. I think I'd lean to supporting only one flow--namely authorization code flow because we can't support all and it keeps the token safely on the server side and can leverage spring's SSO capabilities - sdoxsee
Thanks for the tip with SCIM, wasn't aware of that :) I love these kinds of standards. As for which flow to support: authorization code flow should at least be the default flow. - Kenneth
Looking at youtube.com/watch?v=72K7cMCv7eM&t=1844s (at approx: 17:40) Matt is speaking about a library they have developed at Okta: Juiser, which handles conversion between jwt and user objects - Kenneth
As for checking out Juiser, this is probably a good place to start: developer.okta.com/blog/2017/08/08/secure-spring-microservices - Kenneth

1 Answers

1
votes

You may be already aware but OpenID Connect support has been merged and is due to come out in the next jhipster release (4.10.0?)

Here's the merged pull request and more support is coming.