[keycloak-user] Keycloak suitability in microservice-based platform

Bill Burke bburke at redhat.com
Mon Jun 29 07:10:04 EDT 2015

On 6/29/2015 12:47 AM, Shannon Lloyd wrote:
> Hi,
> We are evaluating Keycloak for possible use in a microservices-based
> SaaS platform that we are building, and I have a few questions around
> the suitability of Keycloak within the architecture that we are planning
> on using.
> Briefly, we will have a handful of end-user applications with their own
> UIs and a large number of backend services with which those UIs will
> speak. Some of those services will act as aggregating/gateway services
> which will delegate to other services further downstream, so there will
> be a lot of service-to-service comms. Our design currently calls for
> each logical application (i.e. a UI plus a handful of supporting
> services) to have its own set of roles that make sense within the
> context of that application. Because many/most roles will only make
> sense in that one context, it does not make sense for a user's token to
> contain all possible roles across the entire realm (the tokens would be
> insanely large). We came up with the idea of having an
> authentication/identity token (containing no application-specific roles)
> to represent the logged in user, and then passing this token to
> downstream services which would then (e.g. via a filter in front of that
> service) retrieve and cache application-specific tokens (with roles)
> from the SSO service for that combination of authenticated identity and
> application/client (relying on the fact that the identity token is valid
> and not expired as proof of an active session).

I don't think you need to do that.  In Keycloak each token is built 
specifically and tailor made for each client and you have complete 
control over what goes into the token via the client's Scope and Mappers.

> Firstly, does this seem like a reasonable approach?
> Secondly, how much support is there in Keycloak to support something
> like this? We are not using an app server, so it doesn't appear to be a
> simple case of leveraging one of the existing adapters. We have a custom
> Java(-SE)-based framework (happens to use Undertow for HTTP, but only
> undertow-core). What support exists for custom, programmatic
> authentication and JWT retrieval outside of the set of adapters provided
> in the Keycloak distribution? Are there any examples along these lines?
> Is it a case of us needing to trawl through all the REST endpoints
> exposed via keycloak-services to figure out what is do-able, or are the
> non-admin endpoints documented somewhere in the same way that the admin
> endpoints have been documented?

Tokens are just JWTs wrapped in a JWS.  Since you're using Undertow, I 
think it is possible to use our adapter.  I'd have to do some research 
to remember how, but our Security Proxy does something very similar if 
you want to look at that code.  Our Security Proxy is just Undertow set 
up with a handler chain which is what you probably want.

> I noticed this on the Keycloak blog about a month ago:
> If a service needs to invoke another service it can pass on the token it
> received, which will invoke the other service with the users
> permissions. Soon we'll add support for services to authenticate
> directly with Keycloak to be able to invoke other services with their
> own permissions, not just on behalf of users.

Marek is work on that the next few weeks.

Bill Burke
JBoss, a division of Red Hat

More information about the keycloak-user mailing list