Heimdall and Zitadel

[cloudcompute]

Hi @dadrus

Do we need Heimdall if we are using Zitadel for authentication. Zitadel allows us to extend its capability with fine-grained access control.

Taken from the post whose link is mentioned above:

Despite the comprehensive features that come with ZITADEL, there may be instances where a more customized or fine-grained approach is needed. Currently, the most effective way to implement fine-grained authorization in ZITADEL is by using custom application logic for smaller projects, or for larger scale projects, leveraging an available third-party tool such as warrant.dev, cerbos.dev, etc. These tools can integrate with ZITADEL, further enhancing your capacity for nuanced, fine-grained authorization.

Thank you for the guidance.

[dadrus]

Hi. Heimdall is not just another authorization or authentication system. It serves as an orchestrator that integrates and combines existing systems, allowing you to abstract away from dealing with authentication or authorization protocols/APIs in your own code. For example, while ZITADEL can use an authorization system and enforce access control during login, it cannot do so after a long-lived login session has been established. This means you would need to integrate with the appropriate authorization system yourself, or you could use heimdall to handle it for you.

With that in mind, let me turn your question around: What challenges are you facing? Based on your specific needs, you might find heimdall helpful for simplifying your setup and reducing your efforts.

[cloudcompute]

Hi and thank you for the response.

My requirements: a reverse-proxy like Envoy, Mullti-tenant SSO, powerful authorization system, Graphql gateway/federation (like Apollo router), microservices hidden behind this gateway. So the challenge is to integrate all this stuff.

while ZITADEL can use an authorization system and enforce access control during login, it cannot do so after a long-lived login session has been established.

So this means if i am using Zitadel and its built-in authorization, I may escape using Heimdall. But if we integrate third-party authorization service like OPA, OpenFGA.. Zitadel's built-in session handling won't suffice and we need to use Heimdall that takes care of sessions (storing in redis) and access/refresh tokens etc. Is my perception correct Or am I missing something?

If this is so, are we not maintaining sessions at two places: Heimdall and Zitadel. How should we handle this?

This service is probably an alternative to Heimadall... but restricted to Envoy/Istio. It may help you improve Heimdall.

[dadrus]

So this means if i am using Zitadel and its built-in authorization, I may escape using Heimdall. But if we integrate third-party authorization service like OPA, OpenFGA.

Yes. You can make use of heimdall to escape that limitation and let it enforce authentication and authorization requirements for individual endpoints.

Zitadel's built-in session handling won't suffice and we need to use Heimdall that takes care of sessions (storing in redis) and access/refresh tokens etc.

Even though heimdall can enforce the existence and validity of a session, it does not manage sessions by itself (at least not now) - it is stateless. It can however make use of other services, which can do so. Typically that functionality is required, when OIDC is used in 1st party context and there is a need for a client (from OAuth2 point of view), which would drive the corresponding flow and manage the sessions, you're talking about (like the service, you've referenced). The general pattern right now would be:

• If the request, heimdall is guarding does not have the required authentication information it will raise an authentication error
• In an error handler, you would react on that error and perform a redirect with a return to url set (the initial url, heimdall was handling) to the service which manages the actual oidc flow, like e.g. https://github.com/oauth2-proxy/oauth2-proxy.
• That service will perform the required actions, set the corresponding cookie and redirect to the url specified in the return url (from the previous step)
• Heimdall performs the same checks as in step 1, but this time it is able to verify the authentication session and continue with the rest of the defined pipeline.

If this is so, are we not maintaining sessions at two places: Heimdall and Zitadel. How should we handle this?

As I've written above, heimdall does not manage any sessions. Nevertheless, with any SSO protocol, there are indeed two sessions in place if the IDP and the services making use of that IDP live in different domains:

1. on the IDP provider side. Otherwise SSO won't work
2. on the side of the service making use of that IDP. This second session is typically based on the contents of the id, refresh and access tokens (if OIDC is used as "SSO" protocol). This is what the authservice from Istio's ecosystem, you've referenced, or the oauth2-proxy, which I mentioned above, do.

This service is probably an alternative to Heimadall... but restricted to Envoy/Istio. It may help you improve Heimdall.

Thank you for the hint. Authservice is indeed known to me. It is not an alternative to heimdall as it is a pure OIDC flow manager (just drives the OIDC flow and enforce the presence of the corresponding session), like the oauth2 proxy, I referenced above. Even though the maintainers of it write, it can be used for fine-grained access control, it is not capable of doing so. It can only check, what's inside the JWT. As such, the maximum it can do is enforcement of RBAC and even here statically - changes to the roles done during the session lifetime can not be reflected (same as with Zitadel).

[cloudcompute]

I just know the fundamentals of OIDC and OAuth.. not the details. Thank you for shedding some light in this subject.

I had a quick look at your code and I found Redis/cache and Sessions are there. I quickly assumed Heimdall is maintaining the session in Redis. So what is the use of Redis in Heimdall?

In case, we use Zitadel and Apollo Router, docker-compose.yaml would be like this:

heimdall:
image: dadrus/heimdall:latest
...

upstream:
image: apollo-router
...

idp:
image: zitadel
...

Pl. confirm.

In the meantime, I am trying to figure out whether I can avoid using this Router service and does the split/aggregation at the Envoy proxy level itself.. probably using its middleware ability.

[dadrus]

I had a quick look at your code and I found Redis/cache and Sessions are there. I quickly assumed Heimdall is maintaining the session in Redis. So what is the use of Redis in Heimdall?

For distribute cache purposes only to reduce communication to other systems. Here an example: If a request hits heimdall and a corresponding pipeline is configured to check the validity of a corresponding session, heimdall will communicate to the responsible IDP (or the system managing the session). With caching enabled, heimdall will cache the response for some configurable time.

You can also use an in-memory cache for the same purpose (which is the default setting) - the downside is that the cache is local to a particular heimdall instance, or disable caching entirely.

In case, we use Zitadel and Apollo Router, docker-compose.yaml would be like this: ...

Yes. You'll however need an additional service, which would drive the OIDC flow.

[dadrus]

For everbody interested: https://dadrus.github.io/heimdall/v0.15.0/guides/authn/oidc_first_party_auth/

[cloudcompute]

@dadrus

Okay thanks, I had a quick, looking great.