Debating whether unique clients are needed for each microservice within an SSO realm

[gbengataylor]

A security realm can be established in Keycloak and it is possible to setup multiple clients within that realm. For example, we could create a realm for every frontend and backend app in the microservices demo .This documents conversations about how to go about creating clients

cutting and pasting discussion with Mike Echevarria

[08:33, 5/29/2019] Gbenga: Good morning Mike. When you get a chance I'd like to get your opinion about setting clients within a realm in keycloak. Imagine you have a microservices app with multiple backend apps and one or two front-end apps. How would you recommend setting up the clients within the sso realm. Would you have a client for every backend app, or just one for all the backend using a bearer token. Would you have a client for each frontend? I'm leaning towards one client for all backend apps and one for each frontend but wanted a sanity check.. thanks [08:38, 5/29/2019] Mike Echevarria: Ideally you have a client for each service. That way you can more easily audit activities (see which sessions are active) [08:39, 5/29/2019] Mike Echevarria: You can also revoke client access without breaking all the other microservices [08:39, 5/29/2019] Mike Echevarria: That said, in my ocp-sso project I use one client for all the backends, lol. Because yeah, it's easier [08:40, 5/29/2019] Gbenga: haha [08:41, 5/29/2019] Mike Echevarria: I keep a separate client for frontends because those are usually public/confidential and have redirects. So it's actually more work to try and maintain all those possibilities instead of just separate clients [08:42, 5/29/2019] Gbenga: so in terms of the flow, if i have an client for every microservice then the front end has to retrieve a separate token for each one...and if a backend needs to call another backend, it can't propagate the token it also needs to generate a new one? is that correct? [08:46, 5/29/2019] Mike Echevarria: The clients themselves refresh tokens. It doesn't need to go all the way back up [08:47, 5/29/2019] Mike Echevarria: Backends can move tokens along, that's no issue [08:49, 5/29/2019] Mike Echevarria: If a backend needs to change to a different account, then that's where you start getting into service accounts. Or you have public methods that call a microservice that needs to get authenticated stuff [09:01, 5/29/2019] Gbenga: thanks for the info

for now will have one client for all the backend microservices. Will reconsider as we expand on this demo

[dudash]

A couple more thoughts (slightly off topic): 1) I agree, it makes sense to keep it simple for now (let's try to add comments where we are relaxing security for the sake of demo simplicity) e.g. token propagation, which I think is sometimes frowned upon 2) FYI: Istio can do JWT token validation too (although I'd like to try to keep istio optional in this repo).

For istio, this is a good read: https://blog.christianposta.com/how-a-service-mesh-can-help-with-microservices-security/

And if using istio Authorization: Bearer $TOKEN is always passed to the end service and is the only place where the payload can be extracted from

[dudash]

A few more random thoughts off the top of my head (also slightly off topic might be better exported in a security doc...): Istio with mTLS can be configured to verify that service X is allowed to communicate with service Y. And it will make sure that traffic can't be snooped on. But SSO (our auth service) comes in to the picture for authentication and authorization. This capability let's us handle the deeper use case of service X is communicating and making some request of service Y on behalf of userA. So we can delegate initial authorization to the auth service and optionally let Istio verify that on each request without service X or service Y needing to perform that activity. JWTs aka tokens enable this.

Istio can even do RBAC for authorization. But I'm not sure we want to go that deep integrating istio for this demo.

• Upside of offloading to Istio is that it's less work in the service code which are written in different languages and required different library dependencies.
• Downside of offloading to Istio is requiring that ppl using this demo use Istio and we are hoping to make that optional.

[gbengataylor]

Options for verifying token

• Istio handle the JWT authorization
• Each service validates the token "offline". The public key needs to be set manually on startup or retrieved from keycloak/auth on startup and with that public key can verify the token. Requires JWT libraries
• each service asks Keycloak to verify the token for every service call.

[dudash]

This one is definitely out: "each service asks Keycloak to verify the token for every service call." :turtle:

[gbengataylor]

I would hope the keycloak client will be able to cache the validations for the life of the token :). will investigate