Hi Thomas (and others),

Thanks for your time. What you are describing is my plan B (a shared Keycloak instance running to which all developers can connect), but as you expected I prefer to not have to be online nor to run an extra application (Keycloak) every time. 99% of the time a default user will suffice and will make the development process a lot more lightweight. Other suggestions are very welcome.

Kind regards,

Martijn

From: Thomas Raehalme [mailto:thomas.raehalme@aitiofinland.com]
Sent: dinsdag 15 maart 2016 16:19
To: Martijn Claus <m.claus@smile.nl>
Cc: keycloak-user <keycloak-user@lists.jboss.org>
Subject: Re: [keycloak-user] Not using keycloak in development

On Mar 15, 2016 16:57, "Martijn Claus" <m.claus@smile.nl> wrote:
> I’ve been setting up Keycloak and liking it thus far. We are using it in an angular / Spring / REST context. For development there are cases where I don’t want to run the Keycloak application (war) but only my own application. I assume this is a valid usecase. But if I turn the Keycloak off, the angular frontend will redirect me to an offline url and the application fails. I will not have a token and the backend will rightfully throw back some AccessDeniedExceptions. Is there a way to use some kind of (magic/permanent/development) token that will be accepted by the backend  and the Keycloak application will never have to be contacted? Or is there some other feature that my backend spring keycloak adapter will accept anything and work with a default user?
>

I'm not sure what you suspect is possible, but here's what we do:

In development mode we use Keycloak configuration which connects to a shared Keycloak instance where we have configured a specific realm and client allowing the use of localhost as redirect URL. This works for every developer and we don't need to "turn off" authentication.

The downside is that you need to be online. If this is a problem you could always use Vagrant or Docker to run Keycloak on localhost. But I guess you were trying to avoid this.

In production we naturally use another Keycloak configuration which we can enable through Spring profiles or Tomcat context.xml or whatever method best fits the situation.

Hope this helps!

Best regards,
Thomas