UAA support: should it be removed ? #13081
Comments
|
cc @jhipster/developers |
|
hi, regards, |
|
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 |
|
Yes you can! As long as options from the blueprints are handled, well, inside the blueprint, everything should be good! |
|
This issue is stale because it has been open 30 days with no activity. |
|
up, for final v7 |
pascalgrimaud
added
$$ bug-bounty $$
|
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. |
|
Yes lets remove it
Thanks & Regards,
Deepu
…On Tue, Jan 19, 2021 at 9:03 PM Pierre Besson ***@***.***> 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
<#13081 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIOKF62DPSV3PRRAFVGMLTS2XQRPANCNFSM4TZ7M4LA>
.
|
|
As no one wants to do this, I'm starting it so |
|
Bounty claimed at https://opencollective.com/generator-jhipster/expenses/33412 |
|
What does that mean exactly for users currently having a UAA server & UAA authentication configured ? |
|
@pascalgrimaud I'm ready to start working on it this weekend. |
|
@kevin-madhu : good news! don't hesitate to ping |
|
@pascalgrimaud Cool! Thanks |
|
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 :-) |
|
I'm no expert in OAuth2 so I may propose a stupid thing, correct me if I'm wrong. I understand that current OAuth2 option setup things for OpenID. Maybe we could have 2 options: base OAuth2 & OpenID. |
|
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.
|
|
@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. |
|
@jfougere : I totally understand your need and we are really sad for removing the UAA support.
The problem we had with UAA support, is the lack of maintenance. No one wants to maintain it. I don't want the option to be added back, and in 6 months, it's broken again. Another problem is the support is done during our personal time. |
|
@pascalgrimaud yes I understood perfectly the reason. I suppose the use of OIDC in Spring is not mandatory no ? (I'm no expert again here). |
|
@jfougere : the expert here is Matt, and as mentioned above, it's possible :-) In my opinion, how it can be achieved:
|
|
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:
- build your Spring Authorization Server (
https://spring.io/blog/2021/05/10/spring-authorization-server-0-1-1-available-now
)
- generate a project with JHipster + OAuth2
- apply some changes (code / config) to make it works with Spring
Authorization Server, as the generated code is yours, you can do what you
want -> I don't have any idea how to do this part :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#13081 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIOKF52X4BCHRY3UBDBN2DTNISVPANCNFSM4TZ7M4LA>
.
|
|
@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) |
|
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. |
|
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! |
|
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. |
|
Thanks @xetys, yes I meant code in services. Thanks for the clarification. |
@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? |
|
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. |
|
@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. |
|
Okay @xetys. Got it. |
|
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 ! |
@jdubois I saw you mentioned about Azure Active Directory. Is there any example/documentation on how to configure Jhipster with Azure AD B2C? Thanks! |
|
@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: spring-projects/spring-boot#27819 ) |
|
@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 |
|
Thank you @mraible ! Yes, that would be another tutorial. |
|
@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. |
|
@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. |
|
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. |
|
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 ! 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! |
and others
@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.
The text was updated successfully, but these errors were encountered: