search

jhipster / generator-jhipster

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
https://www.jhipster.tech
Apache License 2.0
21.44k stars 4.02k forks source link

UAA support: should it be removed ? #13081

Closed pascalgrimaud closed 3 years ago

pascalgrimaud commented 3 years ago

@xetys : you did a great job for UAA support, but today, it's not well maintained. See https://github.com/hipster-labs/jhipster-daily-builds/actions?query=workflow%3A%22Microservices+UAA%22

As the support of UAA is mainly done by 1 person, I open this ticket to discuss if someone else wants to maintain this option ? If not, the option could be simply removed, as it is useless to keep an option which is broken since months.

Then, the option is not maintained in JHipster Registry too, so it could be removed there too.

So plz comment.

pascalgrimaud commented 3 years ago

cc @jhipster/developers

avdev4j commented 3 years ago

hi, My 2 cents I would say UAA should be moved to a dedicated blueprint. By doing this, it will target a specific version of JHipster, the maintenance will be easier and it will avoid to break features (or builds) in the main generator if there is new breaking changes for example.

regards,

xetys commented 3 years ago

if moving to a blueprint, would it still be possible to use it in a JDL like today?

I see the issue with maintenance, I'm kinda far from contributing the past year. I'd love to find a way back to this, but I'm with you, other contributors to UAA would be beneficial. I remember there has been a time when a quite notable amount of users were using UAA. Could someone tell me how the current situation is? Would be interesting for me to know if it even makes sense to put afford in this option. I'm still using it every day and it's a great thing

MathieuAA commented 3 years ago

Yes you can! As long as options from the blueprints are handled, well, inside the blueprint, everything should be good!

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 30 days with no activity. Our core developers tend to be more verbose on denying. If there is no negative comment, possibly this feature will be accepted. We are accepting PRs :smiley:. Comment or this will be closed in 7 days

pascalgrimaud commented 3 years ago

up, for final v7

PierreBesson commented 3 years ago

After 2 months, there has been no further comments from the community on this. I would say the consensus is to remove UAA support for JHipster v7 as it is currently broken. In the future a blueprint can be created for a next-gen UAA architecture. Especially with the new blueprint capabilities coming in v7, such a blueprint should be relatively easy to do and will allow the community of UAA users to progress at their own pace without blocking or being blocked by the evolution of the main generator.

deepu105 commented 3 years ago

Yes lets remove it

Thanks & Regards, Deepu

On Tue, Jan 19, 2021 at 9:03 PM Pierre Besson notifications@github.com wrote:

After 2 months, there has been no further comments from the community on this. I would say the consensus is to remove UAA support for JHipster v7 as it is currently broken. In the future a blueprint can be created for a next-gen UAA architecture. Especially with the new blueprint capabilities coming in v7, such a blueprint should be relatively easy to do and will allow the community of UAA users to progress at their own pace without blocking or being blocked by the evolution of the main generator.

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/13081#issuecomment-763094884, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKF62DPSV3PRRAFVGMLTS2XQRPANCNFSM4TZ7M4LA .

pascalgrimaud commented 3 years ago

As no one wants to do this, I'm starting it so

pascalgrimaud commented 3 years ago

Bounty claimed at https://opencollective.com/generator-jhipster/expenses/33412

jfougere commented 3 years ago

What does that mean exactly for users currently having a UAA server & UAA authentication configured ? Stuck in V6 ? Need to migrate to Keycloak ?

pascalgrimaud commented 3 years ago

@jfougere : as JHipster is a code generator, you can manually upgrade your applications and not rely anymore to JHipster.

You can still try to use v6 but I don't know the exact version when UAA was working.

I'm sorry for removing important options like this one, but it is useless to keep broken options. We were stuck when trying to migrate to Spring Boot 2.3, then 2.4. And after asking help in this ticket, mailing list, twitter, as no one want to maintain this option, the final decision was to simply remove UAA.

Hope you can understand.

jfougere commented 3 years ago

Yes I understand, I am just wondering what would be the correct way forward! I also try to understand what is now the recommended way to secure application with JHipster 7+ ?

Regarding the Spring Boot 2.3/2.4 upgrade, what was the pain point ? Was it the deprecated code from sprint-security-oauth2 ?

pascalgrimaud commented 3 years ago

I suggest you to use OAuth2 with Keycloak or Okta :-)

About 2.3, I didn't take care of the migration, so I can't tell. About 2.4, all gateways are reactive now, using Webflux, because Zuul and Ribbon are deprecated. So it would be a hard part to upgrade.

shougao commented 3 years ago

After 2 months, there has been no further comments from the community on this. I would say the consensus is to remove UAA support for JHipster v7 as it is currently broken. In the future a blueprint can be created for a next-gen UAA architecture. Especially with the new blueprint capabilities coming in v7, such a blueprint should be relatively easy to do and will allow the community of UAA users to progress at their own pace without blocking or being blocked by the evolution of the main generator.

wish to know the next-get UAA will release

pascalgrimaud commented 3 years ago

@shougao : UAA has been removed from JHipster and I don't think someone started a blueprint, so nothing is planned.

kevin-madhu commented 3 years ago

@pascalgrimaud @deepu105 How is the JHipster UAA server superior to the spring authorization server? Is it a viable option to concentrate on bringing https://github.com/spring-projects-experimental/spring-authorization-server to the Jhipster ecosystem? Maybe that'll solve the maintainability issue because it's a spring project itself (still listed as experimental though). Maybe an initiative to bring it to the Jhipster ecosystem could impart more momentum into that project. Any thoughts?

jdubois commented 3 years ago

@kevin-madhu they probably share some common code, but JHipster UAA isn't maintained anymore. It was just too much work, and not enough people ready to contribute to it. For something as important as security, I would recommend a 3rd party service like Okta, Keycloack (but you need to manage it seriously, and take a support contract), Azure Active Directory, etc.

kevin-madhu commented 3 years ago

@jdubois Exactly my point. Do you suggest providing a new option of using "Spring Authorization Server" as a security option in addition to Okta and Keycloack, replacing the JHipster UAA option. Since Spring Authorization Server is an official project of Spring itself, maybe it's more maintained than JHipster UAA.

pascalgrimaud commented 3 years ago

@kevin-madhu : it won't be done in main generator-jhipster because it's too much work. But are you ready to start a blueprint or a module to add this option, and maintain it as your personal project ?

kevin-madhu commented 3 years ago

@pascalgrimaud I'm ready to start working on it this weekend.

pascalgrimaud commented 3 years ago

@kevin-madhu : good news! don't hesitate to ping @jhipster on Twitter, once your project is started, so we can give visibility

kevin-madhu commented 3 years ago

@pascalgrimaud Cool! Thanks

AlexandreCassagne commented 3 years ago

I am not opposed per se to morphing the UAA into a Spring authorisation server option – but will we plan to maintain compatibility for existing UAA users?

This is critical for my needs, so if help is required in maintaining the existing infrastructure/shifting it to Spring authorisation server I'm happy to help with that.

I will plan on merging my multi-factor authentication work as well, which I implemented atop the UAA, if there is interest from you all. Your comments on the well founded/secure nature of my work will be appreciated :-)

jfougere commented 3 years ago

I'm no expert in OAuth2 so I may propose a stupid thing, correct me if I'm wrong. As far as I know the UAA server is a valid OAuth2 server. Why can't we support it as any OAuth2 server using the OAuth2 option ?

I understand that current OAuth2 option setup things for OpenID. Maybe we could have 2 options: base OAuth2 & OpenID. What do u think ?

mraible commented 3 years ago

Spring Authorization Server supports OAuth and OIDC, so this should be possible.

https://spring.io/blog/2021/05/10/spring-authorization-server-0-1-1-available-now

We'll just have to document how to configure it, like we do for Okta.

https://www.jhipster.tech/security/#okta

On May 11, 2021, at 22:23, Julien Fougere @.***> wrote:

 I'm no expert in OAuth2 so I may propose a stupid thing, correct me if I'm wrong. As far as I know the UAA server is a valid OAuth2 server. Why can't we support it as any OAuth2 server using the OAuth2 option ?

I understand that current OAuth2 option setup things for OpenID. Maybe we could have 2 options: base OAuth2 & OpenID. What do u think ?

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

jfougere commented 3 years ago

@mraible do you think we could keep support for UAA server while using the OAuth2 option in JHipster ?

I am asking because adding support for Spring Authorization Server is great but in the meantime it would be nice to offer a solution for users still having a UAA server.

pascalgrimaud commented 3 years ago

@jfougere : I totally understand your need and we are really sad for removing the UAA support. The problem is to maintain the option:

The problem we had with UAA support, is the lack of maintenance. No one wants to maintain it. We had daily builds which failed during more than 6 months, and when I asked help, no one answered :(

I don't want the option to be added back, and in 6 months, it's broken again. I don't want to be stuck when we'll upgrade Spring Boot and the UAA option will be broken again.

Another problem is the support is done during our personal time. That's the main point.

jfougere commented 3 years ago

@pascalgrimaud yes I understood perfectly the reason. I'm just saying that a UAA server is also an OAuth2 server. So it would be nice to have an option OAuth2 in JHipster (Not OIDC) that allows to connect to whatever OAuth2 server we use (UAA server included).

I suppose the use of OIDC in Spring is not mandatory no ? (I'm no expert again here).

pascalgrimaud commented 3 years ago

@jfougere : the expert here is Matt, and as mentioned above, it's possible :-)

In my opinion, how it can be achieved:

deepu105 commented 3 years ago

I also agree about not adding UAA back. Unfortunately we can't maintain options unless its requested by a lot of people. And as Pascal mentioned it shouldn't be hard to modify generated code to make it work and if you are really interested I would suggest building a blueprint that does this

On Wed, 12 May 2021, 9:10 am Pascal Grimaud, @.***> wrote:

@jfougere https://github.com/jfougere : the expert here is Matt, and as mentioned above, it's possible :-)

In my opinion, how it can be achieved:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jhipster/generator-jhipster/issues/13081#issuecomment-839522708, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIOKF52X4BCHRY3UBDBN2DTNISVPANCNFSM4TZ7M4LA .

jfougere commented 3 years ago

@pascalgrimaud I understand your point but again it's not exactly what I meant. I'm not asking to put back UAA option neither to maintain the UAA server itself.

I'm just saying that the UAA is also a valid OAuth2 server (as far as I know), and so supporting OAuth2 should normally mean supporting also the UAA server.

In what way the UAA needs specific client code ? (Here the key point for me is to avoid having to migrate our UAA server to something else at least for now)

xetys commented 3 years ago

Slowly I'm waking up from retirement and suddenly get here :D well...

I'm very sorry that I haven't been able to maintain UAA in the last few months, so I understand the decision of removing it from the main generator. For a couple of days, I'm working on a first version of the UAA blueprint. Here I'm proceeding not to fast, as I want to make this blueprint overriding as few as possible from the main generation process. That's quite a bit of work to do for now.

Anyways, I'm running too many UAA applications to cut them from future upgrades as UAA is not supported, so I'm confident it will return as a blueprint soon. So @kevin-madhu I'm very happy to get some support for the blueprint.

@jfougere about UAA and OAuth2. It's kinda yes and no answer to this. Yes, both OAuth2 (keycloak/okta) are using OAuth2 for the flow. But there are some differences. The OAuth2 option is a little bit more suited for an external IDP. We don't assume the service is being part of your microservices. The UAA on the other hand is an own service, which you can client-load-balance and extend to your own logic. The philosophy here is the following:

I'm still the opinion, that UAA gives a great value for JHipster microservice. It's not exactly the same as OAuth2 option.

And while I'm here... I'm planning to set up the UAA blueprint first as it was before it was removed. I am aware that Spring is developing a new version of the authorization server. They wanted to remove it because they thought Keycloak does the job, but as I explained so much in the past: there ARE cases when users want to implement their own OAuth2 authserver and not using a complete external solution. I'm happy to see, that the spring team finally got convinced by the com that this still is a thing and proceed their work on a new service. But as version 0.0.1 doesn't seem stable to me I think to restore what there was, and when things get stable, move to that new stuff then.

jfougere commented 3 years ago

Thanks @xetys for this explanation. I agree those 2 cases are different and valid.

If I understand correctly, the need for specific client code was to make a load balanced client for the authorization server (UAA) in order to access it via the registry. Am I correct ? What else is specific on the client side ?

I guess if the Spring team is going forward with their authorization server that chances are that client side support will be added and also support via registry in spring cloud. If so maybe it could bring some level of compatibility for us still using a UAA server!

xetys commented 3 years ago

I don't get what you mean with specific client code.

If you mean the JHipster client (say Angular), then the client code is simpler than in the JWT case, as the frontend doesn't manage the tokens.

If you mean the gateways code, so UAA provided a very unique thing. The gateway stored the JWT access tokens in a HTTP-only cookie. With this, the frontend didn't had to manage the token anymore. Even more, it is safer this way, as there is no way of performing XSS attacks on tokens as there is no token visible to JS.

Then again, there is some code for all services to fetch the verification key. In contrast to JWT, UAA uses asymmetric keys. That is indeed a bit specific and possibly can be changed towards a framework standard.

jfougere commented 3 years ago

Thanks @xetys, yes I meant code in services. Thanks for the clarification.

kevin-madhu commented 3 years ago

Slowly I'm waking up from retirement and suddenly get here :D well...

I'm very sorry that I haven't been able to maintain UAA in the last few months, so I understand the decision of removing it from the main generator. For a couple of days, I'm working on a first version of the UAA blueprint. Here I'm proceeding not to fast, as I want to make this blueprint overriding as few as possible from the main generation process. That's quite a bit of work to do for now.

Anyways, I'm running too many UAA applications to cut them from future upgrades as UAA is not supported, so I'm confident it will return as a blueprint soon. So @kevin-madhu I'm very happy to get some support for the blueprint.

@jfougere about UAA and OAuth2. It's kinda yes and no answer to this. Yes, both OAuth2 (keycloak/okta) are using OAuth2 for the flow. But there are some differences. The OAuth2 option is a little bit more suited for an external IDP. We don't assume the service is being part of your microservices. The UAA on the other hand is an own service, which you can client-load-balance and extend to your own logic. The philosophy here is the following:

  • the OAuth2 option allows to fully outsource all user stuff to an external identity provider (IDP). Such as Keycloak or Okta. You are fine handling all user-related stuff outside of your application's scope. Here, OAuth2+OIDC IS the de facto standard how to design communication between your application and the IDP.
  • the UAA option allows you a flexible security setup for the microservice context (user2service calls, service2service calls, 3rd party clients for exposing your API to the outside, etc). Compared to the JWT option, UAA also allows you to modify your user design (registration flow, custom user data, e-mail templates, bla bla bla) as you could normally do with JHipster, but you don't have to reinvent the wheel when it comes to common security scenarios, where the JWT option is just not giving you the tools. OAuth2 is used here, because that specification does describe how to handle that.

I'm still the opinion, that UAA gives a great value for JHipster microservice. It's not exactly the same as OAuth2 option.

And while I'm here... I'm planning to set up the UAA blueprint first as it was before it was removed. I am aware that Spring is developing a new version of the authorization server. They wanted to remove it because they thought Keycloak does the job, but as I explained so much in the past: there ARE cases when users want to implement their own OAuth2 authserver and not using a complete external solution. I'm happy to see, that the spring team finally got convinced by the com that this still is a thing and proceed their work on a new service. But as version 0.0.1 doesn't seem stable to me I think to restore what there was, and when things get stable, move to that new stuff then.

@xetys @AlexandreCassagne Any advice and help from you will be appreciated too!

Even though Spring Authorization Server is a new player and 0.0.1 may not be as stable as the latest JHipster UAA server I'm leaning more towards bringing Spring Authorization Server as a blueprint and get it added to the JHipster ecosystem because then it's a win-win for both the parties (at least in my opinion) because with JHipster comes more adoption and more adoption puts more momentum into the spring project. Also, with the addition of it into the JHipster ecosystem, UAA experts like you yourself kinda will start contributing to the spring project, eventually being able to match the stability and functionality of UAA. When the spring team sees adoption and all this activity maybe they'll take it more seriously and do a really good job of maintaining the project. This is vaguely my line of thought. What do you guys think?

gmarziou commented 3 years ago

0.1.1 is really early, the fact that it is a Spring project does not give any guarantee about its future, it's labeled as experimental and could stop any time.

About adoption by JHipster community, do you think many users would deploy a real app in production based on an experimental security component? I doubt it.

xetys commented 3 years ago

@kevin-madhu as I stated before, my first milestone is that the uaa blueprint (https://github.com/k-tel/generator-jhipster-uaa) will behave exactly as it was before it has been removed from the generator. There are a lot of fixes and actions done to integrate that feature into the rest of JHipster generated code base and there is absolutely no need to reinvent those things again.

When this is done, it could be an experimental feature to let the user choose the spring authorization server instead of the old one.

As @gmarziou I stated, I doubt many users would like the idea of using experimental stuff in production, while we have a stable solution which is field proven for years.

kevin-madhu commented 3 years ago

Okay @xetys. Got it.

niniss commented 3 years ago

Hello, I agree that a standalone UAA blueprint it's the best solution until Spring AUTH server is only on experimental step and can be removed at any time !

dc-tonglec commented 3 years ago

Azure

@jdubois I saw you mentioned about Azure Active Directory. Is there any example/documentation on how to configure Jhipster with Azure AD B2C? Thanks!

jdubois commented 3 years ago

@dc-tonglec I did a blog post about this at https://dev.to/azure/using-spring-security-with-azure-active-directory-mga - be sure to use a recent Spring Boot version, I coded some specific support for Azure that will make AAD B2C work (and even improved it last week: https://github.com/spring-projects/spring-boot/pull/27819 )

mraible commented 3 years ago

@jdubois You might want to update your tutorial (or write a new one) that uses auth code flow instead of implicit flow. Implicit flow is deprecated and is no longer recommended. https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead

jdubois commented 3 years ago

Thank you @mraible ! Yes, that would be another tutorial.

dc-tonglec commented 3 years ago

Thanks a lot @jdubois & @mraible !

I am really looking forward to the new tutorial. ☺

pascalgrimaud commented 1 year ago

@miguelk5 : I confirm the UAA support has been removed. Anyway, the page on our website is still there, because we didn't remove the old page, only the link from our main page to access to it, to not broke the different blog post etc.

yosephsa commented 11 months ago

@pascalgrimaud It seems like the Overview Diagram under the Microservices section still references UAA within the JHipster architecture. This diagram may need to be updated in order to avoid confusion https://www.jhipster.tech/microservices-architecture/

If someone still has the original reference diagram to update that'll be better since newer versions don't use Zuul and so on. If not, then here's an alternative temporary drop in if you'd like. microservices_architecture_3

mraible commented 11 months ago

I remember there being an issue about updating the microservices architecture diagrams. I'm not sure where it is, but I did create a couple of new diagrams as part of Micro Frontends for Java Microservices.

lsorba commented 7 months ago

Sorry for keeping this topic alive.

I am still a fan of the old but good UAA that I have tweaked, thanks for your work @xetys ! @xetys you wrote few years back that you are still using UAA for your projects, did you manage to configure a microservice with Spring Security 6 to auth² with UAA ? A bit in the idea of @jfougere ?

My goal would be to keep the UAA (I know it is not up to date) but make it work with a generated & adpated JHipster 8 microservice using Spring Security 6,...

If anyone achieved this, I would be very happy to get some tips and support!