How to enhance Caddy's basic_auth?
from tubbadu@lemmy.kde.social to selfhosted@lemmy.world on 23 Jul 19:33
https://lemmy.kde.social/post/4163320
from tubbadu@lemmy.kde.social to selfhosted@lemmy.world on 23 Jul 19:33
https://lemmy.kde.social/post/4163320
Hello fellow selfhoster! on my debian server I use Caddy as reverse proxy, and would like to protect some services and files with a password. I would like, however, to be able to access some protected files programmatically, from a script. using Caddy’s built-in basic_auth works as intended, but I’d like to be able to use a login form instead of just a browser prompt. This is AFAIK not possible, so I’m looking for alternatives. Any idea?
#selfhosted
threaded - newest
I use github.com/nosduco/nforwardauth for this purpose
There is an example implementation for caddy in github.com/nosduco/nforwardauth/tree/…/caddy-v2
or maybe voidauth could do it sh.itjust.works/post/42016490
Developer of VoidAuth here, you could give that a try! If you have any issues or questions I can help :) VoidAuth
It does support basic_auth to ProxyAuth protected domains, so you can set up a user for that purpose. Docs for that are here: ProxyAuth
This looks very interesting! I see that it supports users groups, would it be possible to create “named access policies” (like “admin_only_policy”, “group_XXX_policy” ecc) and then assign them to the various services directly in the Caddyfile? thank you very much!
I don’t think you could do that directly in the Caddyfile, but you can create those groups/policies inside VoidAuth and assign them to users there.
The steps would be to (in VoidAuth) create the access group/policy, create the ProxyAuth Domain (protected.example.com/*) with the allowed group(s), make sure the user(s) have that group, then in Caddy add the forward_auth directive to the same route you want to protect.
Then when you go to access that route in a browser it will redirect you to VoidAuth login, or if you pass an Authentication header with Basic Auth (like when using an API) it will use that.
How does programmatic access tie into the desire for a login form?
Either way, you can do a login form -> basic auth forwarding page by rigging up some simple JS, or access programmatically in a direct way by simply setting a manual Authorization header.
I would like to keep files with “private” information protected from public access, but I would like to access them from a script. An example: i wrote a karaoke application to use with my friends, they have to go to a webpage and select the songs they like, and then the karaoke app connects to the server to get the updated preference file. I would like that the users had a “nice login form” to select their songs, and then I’d like my karaoke app to easily download the file while still keeping it password-protected
Yeah, I believe you don’t need to extend Caddy at all for that.
Add a properly-formatted Authorization header to any requests you make to the server and it’ll work. See Wikipedia page for header string format:
en.wikipedia.org/…/Basic_access_authentication
On the webpage side, I’d have the login form make a POST to your login endpoint using a basic auth header to pull a JWT that acts as a “real” auth key for other pages.
This is all assuming you want to stick with basic auth as opposed to a more heavyweight option.
I don’t use Caddy but Keycloak may be what you’re looking for.
This was actually pretty interesting until I found out that Caddy is not yet supported :(
Thank you anyway!
I use Authelia powered by LLDAP with Caddy to protect services. For accessing files I use copyparty, it can hook into Authelia for user auth.
I already looked into Authelia, and the “problem” I encountered is that it does not support “named policies” (I don’t know the actual name): what I mean is to be able to create “only_admin_policy”, “only_registered_users_policy” etc, and then in Caddy to be able to say something like this
service1.website.com { reverse_proxy container1:1234 apply_policy only_admin_policy } service2.website.com { reverse_proxy container2:1234 apply_policy only_registered_users_policy } service3.website.com { reverse_proxy container3:1234 }Instead if I understood correctly (and I would gladly be proved wrong) this is not possible with Authelia, as these policies have to be specified inside Authelia, so I would have two different configurations in two different places instead of having everything in the Caddyfile
I hope I explained well what I mean
thanks for the help!
yes, it can do that, assuming you are using LDAP or have set up users/groups in the Authelia config. you don’t need to set it up in the caddyfile though, you can handle everything from Authelia’s end. for example, here is a typical protected item from my caddyfile.
# this is a bit of code at the top that I use for every protected item, and call it each time to save space (protected) { tls /ssl/home-cert.pem /ssl/home-key.pem forward_auth :4100 { uri /api/verify?rd=https://auth.myurl.xyz/ copy_headers Remote-User Remote-Groups Remote-Name Remote-Email header_up Host {upstream_hostport} } encode gzip } # UptimeKuma uptime.myurl.xyz { # now to call the code above for this item import protected * reverse_proxy :4000 }that’s all I need in my caddyfile, just the bits that forward the information about the user to each site to log them in. I can then handle all the auth rules like saying which sites are only for admins or users in the Authelia config. since I use LDAP, I can set up the groups in that, then just specify which sites are DENY or TWO_FACTOR for each group in the Authelia config. or even in the apps themselves, if they support LDAP like Jellyfin and Forgejo.
Check out supertokens.io
I see voidauth already mentioned, great setup also