traefik-forwardauth-support-with-keycloak/

[utterances-bot]

Traefik ForwardAuth Support with Keycloak

Step-by-step instructions to configure ForwardAuth middleware on Traefik. Assumes you have working Keycloak and Traefik installs.

https://brianturchyn.net/traefik-forwardauth-support-with-keycloak/

[pbitante]

Thank you for the tutorial, this has been an immense help!

I have keycloak and traefik-forward-auth up and running with the keycloak client setup per your instructions. When I navigate to my application, however, I am met with a "Bad Gateway" error and it will not redirect to the authentication portal. I was wondering if you had a full docker-compose file with your Traefik setup that I could look at? I am hoping that it is something simple that is holding me up.

[b-turchyn]

Hey there @pbitante; I created a Gist that hopefully helps.

My usual workflow is to have each logical service in its own separate Docker Compose file, so I put this together from two separate files. I suppose that's my way of saying that I haven't technically tested this in its current form. Nevertheless, I hope this helps sort out any potential issues you might be having. If there's anything else I can help with, let me know!

https://gist.github.com/b-turchyn/555d893d2055e5bda3fa56ee78910d1e

[pbitante]

Hi @b-turchyn!

Thank you for responding to me with this gist. I took a look at it, and it didn't appear to have any glaring differences in my setup vs yours. I tried matching my labels/settings to what you have specified, but still no luck. I'm assuming you had setup your keycloak client with the same settings your specified above, and I had set up a client both in a fresh image of keycloak 11 as well as with our custom keycloak image. I have created a gist of my setup without keycloak, as it was the same as yours. If you would like to take a look at it I would greatly appreciate it.

https://gist.github.com/pbitante/32a9b869e5b8eb258f96edfbcd65170e

[PierrePetit]

Hey @pbiante!

I faced similar issues and had to fix two things, both in my keycloak's backoffice.

I had to add in my realm's "Client scopes" the missing attributes used by mesosphere/traefik-forward-auth. I saw these in the keyloak url and logs I got when I tried to log into my container and got a "504 bad gateway" error : openid, profile, groups (and email, that already existed). I added them in keycloak's forwardauth client : https://imgur.com/7wUSMY0

Other problem: my user only had a username, and no email. That resulted in an access denied error once I completed the login. Simply filling the email of the user in keycloak's "Users" section of the backoffice fixed that.

I hope this can help you or someone else.

[b-turchyn]

Thanks for the extra info, @PierrePetit. I'm taking a look at my Keycloak configuration and I also have client scopes assigned. In my configuration, I have every default and optional client scope assigned, although I likely don't need most of these. Likely a scope of address, or email and profile would be sufficient, although I haven't tested this (yet!).

I'll tinker around with what I have defined in the client scopes on my local install, and once I've confirmed which scopes are required I'll respond back here and update the article accordingly.

[b-turchyn]

Looks like you were right; I definitely missed documenting the client scope changes. I've updated the post above to reflect what my configuration looks like.

This makes me think that I've likely customized other parts of my realm that may have an impact on how these all fit together. Hopefully this was the only part I missed, but if I did fail to cover something else and either of you run into further issues, definitely reach out and I'll dig into it further.

[PierrePetit]

Great post, and gotta love you keeping it up to date. Kudos, and thanks, it helped me a lot :)

[Freundschaft]

thanks for this! is there any way to add the forward-auth rules for whitelist and groups directly in the docker-compose file?

[b-turchyn]

thanks for this! is there any way to add the forward-auth rules for whitelist and groups directly in the docker-compose file?

Hey @Freundschaft; not that I'm aware of.

I'm trying to think how one would implement this. The challenge here is that the configuration that happens within docker-compose.yaml is largely in the form of labels, and those labels are used by Traefik. In the case of the whitelist and group assignments, those are used by Keycloak, which as far as it's concerned, doesn't know nor care about the labels (and, for that matter, may not even be hosted within the same Docker footprint).

One potential option would be to import your Keycloak realm via the available options on the Docker image ([link] -- see "Importing a realm" section) and use that to set the endpoint whitelist. Two caveats come to mind here.

1. I have no idea what this will do to the user listing you have within your already-existing database. As with all advice on the internet, this comes with no warranty ;) (although if you try this and it works, you should totally reply back!)
2. This doesn't pull the configuration from the labels or from the Compose file, but would put the configuration onto the filesystem.

I can definitely see why this would be desirable for a smaller footprint. I'm sure many people reading this are doing this for their own homelab deployment. I haven't put a ton of thought into this, but I suspect from an industry best practices perspective, you wouldn't want to do this, since that potentially gives those with access to your application infrastructure the power to modify how the identity provider functions, and that seems like a big no-no (assuming multiple teams, limited trust and all that).

Hope this helps!

[pbitante]

Hey, @b-turchyn and @PierrePetit!

I was able to get this working by just creating a "groups" client role in Keycloak, so thank you for pointing that out!

I was just wondering, do you have a way to handle logouts implemented in your solution?

Thank you again!

[pbitante]

Hey, @Freundschaft!

You can create an ipwhitelist middleware by adding labels to the service that you are deploying behind the forward-auth container.

https://doc.traefik.io/traefik/v2.5/middlewares/http/ipwhitelist/

Then add that middleware to the list of middlewares for the router on that container. I hope this helps!

[Freundschaft]

perfect thanks for all the helpful replies!

[dduh96]

Hi there, great post! I'm currently looking around for middlewares to connect traefik and keycloak, there's a lot of stuff out there and I'm having trouble ascertaining the pros and cons of them. So was wondering is there any particular reason for you to use mesophere's project?

[b-turchyn]

Hey, @Freundschaft!

You can create an ipwhitelist middleware by adding labels to the service that you are deploying behind the forward-auth container.

https://doc.traefik.io/traefik/v2.5/middlewares/http/ipwhitelist/

Then add that middleware to the list of middlewares for the router on that container. I hope this helps!

I'd definitely recommend this middleware for IP whitelisting, particularly if you're operating primarily in the IPv4 space. IPv6 will introduce some wrinkles in there since the allocated addresses can be more portable, and IP whitelisting may be less effective for you then (admittedly I am by no means an expert in IPv6).

The Traefik middlewares are fairly solid overall. Sometimes I find the documentation for them a little hard to think of in terms of what labels I need to apply to my containers and where I should be putting those labels.

[b-turchyn]

Hi there, great post! I'm currently looking around for middlewares to connect traefik and keycloak, there's a lot of stuff out there and I'm having trouble ascertaining the pros and cons of them. So was wondering is there any particular reason for you to use mesophere's project?

Hi @dduh96; I forget exactly why I picked mesosphere's project. I had been doing some research back when I first implemented this, and there was a recommendation to use mesosphere's versus the original. I believe it was related to this note in the README (bolding is my own, all other formatting is original):

noelcatt/traefik-forward-auth and funkypenguin/traefik-forward-auth also made thomseddon/traefik-forward-auth apply to generic OIDC, but they are now based on an older version which does not support rules and also require the UserInfo endpoint to be supported.

If I remember the exact reason in the future, I'll be sure to respond back!

[Freundschaft]

Hey, @b-turchyn and @PierrePetit!

I was able to get this working by just creating a "groups" client role in Keycloak, so thank you for pointing that out!

I was just wondering, do you have a way to handle logouts implemented in your solution?

Thank you again!

hello, how were you able to find a solution with the groups client role? as far as I understand it is not good practice to perform authorization in the authentication. keycloak takes care of the authentication, but then the traefik middleware should take care of the authorization, e.g. by checking if the group is allowed to access the service or not, right? I was wondering if this could be somehow configurable within the middleware itself

[b-turchyn]

Hey there @Freundschaft;

hello, how were you able to find a solution with the groups client role?

I'm not sure exactly what you're asking here. Are you asking if I found a solution for confirming a user is part of a particular group before authorizing? (If so, keep reading! 😄)

as far as I understand it is not good practice to perform authorization in the authentication. keycloak takes care of the authentication, but then the traefik middleware should take care of the authorization, e.g. by checking if the group is allowed to access the service or not, right? I was wondering if this could be somehow configurable within the middleware itself

You're absolutely right; in an ideal world, authentication and authorization are two separate items that should be verified by different systems. In this case, Keycloak should be responsible for defining the identity (authentication), and either Traefik or the forwardauth proxy should confirm the authorization.

I looked into the configuration both for the Traefik Middleware and the traefik-forward-auth container and did not find any options to validate that the user has a specific role. The closest I could find was Kubernetes RBAC support. This does look like it would be relatively simple to build a more static implementation, although I haven't personally looked into what would be required for that. At first glance:

• A new struct that implements the Authorizer interface
• Changes to the Config struct to support the definition of which group the user needs to be a part of (possibly on a per-URL basis, which is where the complexity comes in)

[dduh96]

Hi another question,

I dont want to redeploy my traefik stack because its being used in production, can I deploy this in its own docker-compose or do I have to redeploy traefik for this to work? Are there any labels that will only work when it is declared in the traefik docker-compose?

[b-turchyn]

Hi another question,

I dont want to redeploy my traefik stack because its being used in production, can I deploy this in its own docker-compose or do I have to redeploy traefik for this to work? Are there any labels that will only work when it is declared in the traefik docker-compose?

Hi @dduh96; all of this can be deployed in its own Docker Compose file. The forward-auth middleware is built into Traefik, and using it does not require any changes nor reboots to the Traefik container itself.

The one exception to this might be if you wanted to enforce this authentication for Traefik's internal API dashboard. In my example docker-compose.yaml file, I had the following labels on the Traefik container (where routers.api was the name of the API service I was exposing):

      - "traefik.http.routers.api.service=api@internal"
      - "traefik.http.routers.api.middlewares=traefik-forward-auth"

Not sure if you can apply that via another container. I haven't personally tested it.

[karma-git]

Hello everyone!

I'm trying to setup kc with traefik proxy for applications that aren't able to authenticate users themselves.

But I have issues. I've described them here (redirects loop between proxy and keycloak), please take a look: https://hackmd.io/7FfaqDjnTRmsKq-9knhFcQ

Many thanks in advance.

Best regards,

[karma-git]

resolved using the configuration from https://github.com/sleighzy/k3s-traefik-forward-auth-openid-connect

[b-turchyn]

Thanks for responding back that you were able to fix your issue, @karma-git.

I don't have any experience working with Kubernetes; are you able to clarify what the specific issue was with your original configuration? Might be useful if others run into the same situation.

[RemiSca]

Hello,

Thanks for this very helpful cookbook, great help!

I've faced the following issue while following it:

msg="error clearing session: error setting session options: securecookie: error - caused by: crypto/aes: invalid key size 0"

As answered in the issue https://github.com/mesosphere/traefik-forward-auth/issues/62, adding ENCRYPTION_KEY variable solved it.

Regards,

[b-turchyn]

Thanks for the info, @RemiSca; I've made a note to review what I've written and see where I can make updates :)