New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for enabling the use of Keycloak with Spring Security #2465

Closed
raehalme opened this Issue Dec 9, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@raehalme

raehalme commented Dec 9, 2015

Keycloak is an open source integrated SSO and IDM solution built on top of OAuth 2.0 and OpenID Connect. Keycloak provides numerous adapters for application types to make it really simple to enable it as the authentication mechanism. Spring Security already has a ready-made adapter available as part of the distribution.

It would be great to have direct support for enabling and pre-configuring Keycloak when creating a new application with JHipster. It could be a one more option to the list of authentication types (3/15).

@jdubois

This comment has been minimized.

Show comment
Hide comment
@jdubois

jdubois Dec 9, 2015

Member

One solution is indeed to add one more question to the list of authentication types.
But, as far as I understand, Keycloak is going to be a third-party service, so in the end it's always complex for us to integrate, as we can't test and support this ourselves (we would need to install a Keycloak server, work with different versions... lots of work).
We are currently rolling out a new "module" system, and it looks like a good option for this. We already have people (ping @cbornet ) doing "security modules", so you also maybe work with them.

This is not officially released yet, but here is:

For what you do, you will most certainly need a new extension point (or "needle" as we call them): if you go this way, don't hesitate to ask us for this.

Member

jdubois commented Dec 9, 2015

One solution is indeed to add one more question to the list of authentication types.
But, as far as I understand, Keycloak is going to be a third-party service, so in the end it's always complex for us to integrate, as we can't test and support this ourselves (we would need to install a Keycloak server, work with different versions... lots of work).
We are currently rolling out a new "module" system, and it looks like a good option for this. We already have people (ping @cbornet ) doing "security modules", so you also maybe work with them.

This is not officially released yet, but here is:

For what you do, you will most certainly need a new extension point (or "needle" as we call them): if you go this way, don't hesitate to ask us for this.

@raehalme

This comment has been minimized.

Show comment
Hide comment
@raehalme

raehalme Dec 9, 2015

Keycloak has pretty extensive test suite available where they are using, for example, Arquillian while running tests against the service. I'm pretty sure the same technique could be used here as well. There're also Docker images available, and I've published a simple Vagrant setup to make testing easier.

But thanks! I'll have a look the "module" system when I've a chance to focus on this a bit more.

raehalme commented Dec 9, 2015

Keycloak has pretty extensive test suite available where they are using, for example, Arquillian while running tests against the service. I'm pretty sure the same technique could be used here as well. There're also Docker images available, and I've published a simple Vagrant setup to make testing easier.

But thanks! I'll have a look the "module" system when I've a chance to focus on this a bit more.

@jdubois

This comment has been minimized.

Show comment
Hide comment
@jdubois

jdubois Dec 9, 2015

Member

Oh, Arquillian, that's exactly why I don't want to go that way! I've worked on several projects using this, I don't want to use that ever again.
So the good thing with modules is that people using Keycloak can still do whatever they want with Arquillian, and I don't have any of those issues, as we are cleanly separated. Should be perfect for everyone!
I'll let you do the module -> I'm closing this as we won't work on this from the JHipster side, but of course you can add more tickets if needed (if you do a module, you might want a new variable, function or needle, just ask!)

Member

jdubois commented Dec 9, 2015

Oh, Arquillian, that's exactly why I don't want to go that way! I've worked on several projects using this, I don't want to use that ever again.
So the good thing with modules is that people using Keycloak can still do whatever they want with Arquillian, and I don't have any of those issues, as we are cleanly separated. Should be perfect for everyone!
I'll let you do the module -> I'm closing this as we won't work on this from the JHipster side, but of course you can add more tickets if needed (if you do a module, you might want a new variable, function or needle, just ask!)

@jdubois jdubois closed this Dec 9, 2015

@jdubois jdubois modified the milestone: 2.26.0 Dec 16, 2015

@pascalgrimaud pascalgrimaud added the module label Jan 3, 2016

@jdubois

This comment has been minimized.

Show comment
Hide comment
@jdubois

jdubois Jan 13, 2016

Member

Hi @raehalme we've had some recent new works, in the field of microservices, and I'm finding Keycloak looks like a very good idea for #2584
This is quite a different use-case, but if we want to have an OAuth2 server, Keycloak looks like an excellent option, I'm definitely going to test this out!

Member

jdubois commented Jan 13, 2016

Hi @raehalme we've had some recent new works, in the field of microservices, and I'm finding Keycloak looks like a very good idea for #2584
This is quite a different use-case, but if we want to have an OAuth2 server, Keycloak looks like an excellent option, I'm definitely going to test this out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment