11:47 p.m.
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).
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?
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.
Is there any news on these plans? It sounds like the sort of thing that we
would require.
Cheers,
Shannon