search

go-vikunja / vikunja

Mirror of vikunja from https://code.vikunja.io/api
GNU Affero General Public License v3.0
758 stars 55 forks source link

sticky openid login / Authentik OpenID misconfiguration #256

Closed mrpops2ko closed 2 months ago

mrpops2ko commented 2 months ago

Description

hi so i have found what i think is a bug and also the rest of the information is me trying to debug wrongly configured routing on my own part, so please ignore it but its good to keep it around for anybody who is silly enough to have forward auth configured and were declaring authentik as a traefik middleware like - "traefik.http.routers.vikunja.middlewares=authentik@file" im sure others will find this from google in time

now onto the bug (or 2 rather, one is in the documentation of openid, you forgot a trailing slash in the authurl part)

and the other is in relation to the logic of openid

what i've observed is this, and i've reproduced it a few times now to check too

start order is important for the 'log in with authentik' button to appear

if i start vikunja without authentik / traefik then the button disappears and never will be visible

if i start authentik / traefik and then start vikunja then the button appears

a possible solution to this is some retry mechanism

==========================================================================

i'm following your documentation on how to implement openid auth and it seems im doing something wrong but i've gone over the config 15 times now and i'm reasonably sure i've followed it exactly and it still doesn't work.

I use traefik and authentik. To start I verified that I could reach vikunja through traefik without an middleware auth.

I then added authentik middleware, which i have verified works on other applications. - "traefik.http.routers.vikunja.middlewares=authentik@file"

I then added the config.yml and noticed it wouldn't load, i resolved this issue by adding VIKUNJA_SERVICE_ROOTPATH: /app/vikunja/files so that it would then work and pick up the config, the logs verify it does and if i ssh and cat the file it confirms to what is bindmounted

2024-04-25T14:55:15.025605133+01:00: INFO ▶ config/InitConfig 001 Using config file: /app/vikunja/files/config.yml

What may be the issue could possibly be my traefik label for authentik, i have it set up to work with the forward auth proxy but this rule might need to be expanded further to support openid and requests that vikunja might be making to authentik via that

authentik resides at auth.domain.com vikunja resides at vikunja.domain.com

currently this is the label for authentik - "traefik.http.routers.authentik.rule=Host(`auth.domain.com`) || HostRegexp(`{subdomain:[a-z0-9]+}.domain.com``) && PathPrefix(`/outpost.goauthentik.io/`)"

i've followed this guide https://vikunja.io/docs/openid-example-configurations/ and followed the config exactly and it doesn't work.

I started to play around with various URLs to see if it was that, and noticed that authurl: "https://authentik.mydomain.com/application/o/vikunja" this didn't work but adding a trailing slash to it did

this didn't resolve my problem but at least it brought me to an authentik page which states information like

  "issuer": "https://auth.domain.com/application/o/vikunja/",
  "authorization_endpoint": "https://auth.domain.com/application/o/authorize/",
  "token_endpoint": "https://auth.domain.com/application/o/token/",
  "userinfo_endpoint": "https://auth.domain.com/application/o/userinfo/",
  "end_session_endpoint": "https://auth.domain.com/application/o/vikunja/end-session/",
  "introspection_endpoint": "https://auth.domain.com/application/o/introspect/",
  "revocation_endpoint": "https://auth.domain.com/application/o/revoke/",
  "device_authorization_endpoint": "https://auth.domain.com/application/o/device/",

so i suspect that at least needs updating in the docs, but i'm still without success in able to access vikunja with authentik and i'm not sure what else to try now

additional things i've tried: removing all quotation marks, i attempted to compare and contrast the examples and in the first few you offer yaml without quotations and the authentik one you didn't - this didn't resolve the issue (and i dont think wrapping in quotation marks is an issue)

Finally I figured it out, what I was wrongly not realising is that OpenID and forward auth proxying are 2 completely mutually exclusive things - i can't add an authentik forward auth that sits in front of vikunja (or well you can but that is not openid)

openid act as a login provider, and the front facing part will still be vikunja the user just needs to click the log in with authentik button and it will work.

Vikunja Version

latest

Browser and version

chrome

Can you reproduce the bug on the Vikunja demo site?

Please select

Screenshots

No response

kolaente commented 2 months ago

what i've observed is this, and i've reproduced it a few times now to check too

start order is important for the 'log in with authentik' button to appear

if i start vikunja without authentik / traefik then the button disappears and never will be visible

if i start authentik / traefik and then start vikunja then the button appears

This is by design. Vikunja will try to reach the auth provider when the first request to the /api/v1/info endpoint is made, usually when you open Vikunja in the browser. I would not host Vikunja and Authentik in the same docker compose stack to make that work.

Where exactly is the slash missing in the docs? The actual url used is inferred from the .well-known response from the provider.

mrpops2ko commented 2 months ago

what i've observed is this, and i've reproduced it a few times now to check too start order is important for the 'log in with authentik' button to appear if i start vikunja without authentik / traefik then the button disappears and never will be visible if i start authentik / traefik and then start vikunja then the button appears

This is by design. Vikunja will try to reach the auth provider when the first request to the /api/v1/info endpoint is made, usually when you open Vikunja in the browser. I would not host Vikunja and Authentik in the same docker compose stack to make that work.

Where exactly is the slash missing in the docs? The actual url used is inferred from the .well-known response from the provider.

what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO

https://gyazo.com/52bee35cd51e586e771a3988b422a648.png trailing slash here

kolaente commented 2 months ago

what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO

It's mostly to speed things up and do not hit the auth endpoint for discovery all the time. Usually this is not a problem as auth providers are somewhat critical and thus need to be up constantly.

If Vikunja was able to see the auth provider and cached the provider, and you restart Traefik only, Vikunja will still have the entry in cache and not "forget" it.

mrpops2ko commented 2 months ago

what is the logic of the design? for example i have vikunja and authentik in separate docker compose stacks (traefik and authentik are in the same stack) and if i need to take traefik down to add some new network or make a modification, then vikunja will be up and unable to reach the endpoint so it will just never present authentik SSO

It's mostly to speed things up and do not hit the auth endpoint for discovery all the time. Usually this is not a problem as auth providers are somewhat critical and thus need to be up constantly.

If Vikunja was able to see the auth provider and cached the provider, and you restart Traefik only, Vikunja will still have the entry in cache and not "forget" it.

alright thank you, well i can only hope that you will reconsider this design decision because on some levels it makes no sense.

if we were to add up the cumulative cost, across every single vikunja user hitting some endpoint that was down, once every say 30 seconds i'm sure the cumulative cost across the span of a year is less than $5

the amount of wasted cpu cycles, extra 'load' and all the rest is so virtually low that if we were to graph it out it'd be so statistically insignificant that it'd be questionable if it was real

we are literally talking about loading what is likely a traefik 404 page if its a self hosted auth is down and repeating that every 30 seconds or whatever arbitary retry mechanism value, which im sure nobody is losing sleep over or could ever quantify into meaningful monetary loss or wasted performance