I’ll have a chat with the fellas, we’re always on the lookout for people to contribute, blog articles included if you’re interested that is?
Yea I’m interested since I don’t have a blog or instructional platform. My only issue with my setup is the use of the an external nginx application. I’m aware this site tends to cater toward the use of all docker images – so for example nginx would also be run within a docker container in addition to the authelia, mariadb and redis containers. I already had an nginx installation setup on the host so I just made use of it. If that’s not a problem I’m ok with post the documentation. The documentation is already done, it probably just needs to be formatted correctly for markup which is kind of specific to the blogging/documentation platform – ie like wordpress, jekyll, etc.
@kevdog How about we publish it on our blog, I’d like to rewrite the Nginx bit, which I’m happy to do to utilise our LE/Nginx image, however still publish it under your handle/avatar?
Does that sound reasonable?
Yes the offer sounds totally reasonable. Is it a problem however if I’m not using all the docker images from your site?
Here are the docker hub images I’m using:
AUTHELIA_CONTAINER=authelia/authelia:latest
REDIS_CONTAINER=bitnami/redis:latest
MYSQL_CONTAINER=linuxserver/mariadb
I chose the redis container from bitnami since I could pass the redis password as an ENV variable. (In fact looking at docker hub I don’t even see a linuxserver/redis image so I’m guessing its probably OK).
Yes you can rewrite the nginx bit, and in fact I’m pretty sure I could set that up – would just need to change a few things but I get the idea.
Nope, it’s no problem using other containers, I wrote a bitwarden guide on the blog, the rule we tend to play by is that it has to involve a container of ours somewhere, so Mariadb and LetsEncrypt would more than cover that and we don’t have a redis or Authelia container.
Well let me know how to get started. I’m making the assumption of a working nginx setup with installed SSL certs as a pre-requisite. If you wanted to actually expound upon this pre-requisite, that’s OK. My documentation had to start somewhere.
Sent you a PM fella.
@chbmb and @kevdog I utilise a lot of of the LSIO containers including the LE/nginx one myself.
The nginx supplementary config examples we provide in our docs is modelled to work alongside the LSIO container: https://docs.authelia.com/deployment/supported-proxies/nginx.html. As a matter of fact you’ll see that the our Traefik examples utilises an LSIO image just to showcase the protection.
I think one of our team members James is going to reach out @chbmb, to see if there’s anything we can also do to support this initiative.
What was the question? I’ve had authelia up and running for a few months now. It works very well. I’m using nginx as the reverse proxy only because I’m more comfortable working with that reverse proxy than others. Are you looking for something?
I dont think it was a question.
nightah was pointing out that using the current documentation will work with LSIO LE/nginx and authelia.
Which it does - I have just tested it. It works now because a few months ago when I tested it (after Authelia v4 was just released) it did not work without heavy customizations).
Precisely. The intent of the post was to confirm this, and also suggest that us (the Authelia team) are open to supporting the LSIO community if we can.
The authelia team is great and extremely responsive.
In terms of documentation – are you speaking about the official authelia documentation which is able to utilize the LSIA LE/nginx image? I’m using the LSIO mariadb container with authelia, however I’m managing LE and nginx actually on the docker host. Authelia recently introduced the use of docker secrets and I’m aware in the future they are going to do away with setting passwords through the use of the env file or environmental variables. You could still set password through the authelia configuration file if you’d like or through the use of docker secrets. I spoke with the authelia people last week who helped me with the setup of docker secrets since I wasn’t familiar with the process.
My only small (please not the word small) pet peave would be the way the implement their version of the docker secrets file. Most implementations use the suffix FILE on the end of their password env variables. LSIO favors a FILE__ prefix. For a specific example
for the linuxserver/mariad
MYSQL_PASSWORD=${AUTHELIA_STORAGE_MYSQL_PASSWORD}
When using docker secrets via a file method:
FILE__MYSQL_PASSWORD=/run/secrets/storage-mysql_secret
Most use
MYSQL_PASSWORD_FILE=/run/secrets/storage-mysql_secret
@nightah we have an initial draft for incorporating authelia into letsencrypt and the reverse proxy confs. We would appreciate your feedback
I really wish I could help you guys on this one. You authelia.conf file is constructed differently than mine. I basically just lifted mine from the examples on the authelia web site. You configuration is definitely a little bit different. Not sure my contribution would help anything.
Yep that was James and myself (Amir).
@aptalca that config works great, perhaps the only thing I would do personally is make enabling Authelia in the locations via another include instead of the explicit definitions of the respective 4 lines, but that’s just a nit really.
docker-letsencrypt/root/defaults/authelia.conf at c2cb1d6e9ca0e1eb0493e9f3bfc513617f71cc9d · linuxserver/docker-letsencrypt · GitHub can be removed to avoid any confusion especially given it’s commented.
@nightah good catch, those two commented lines are an artifact from my local testing and will be removed.
I originally didn’t want to have two confs that got included so I tried to combine them into one as much as possible. That way it would be clearer and more concise (also would be more in line with how we currently handle ldap). Unfortunately I can’t move the proxy_set_header lines out because they only get inherited if there are no other set header directives in the location block.
I did see a note about them:
# Set the X-Forwarded-User and X-Forwarded-Groups with the headers
# returned by Authelia for the backends which can consume them.
# This is not safe, as the backend must make sure that they come from the
# proxy. In the future, it's gonna be safe to just use OAuth.
Does that mean that behavior will change in a future update and these header settings will no longer be needed?
Also, currently Authelia’s login form page is served at the root uri /, and requires a subdomain proxy conf. Is it possible (or are there plans to make it possible) to serve the page at a subfolder like /authelia? That way, we wouldn’t need a subdomain proxy and could instead add a new location block for it into authelia.conf. That would also negate the need to enter the server url for the error_page directive and instead use something like error_page 401 =200 /authelia; Our ldap implementation works that way: https://github.com/linuxserver/docker-letsencrypt/blob/master/root/defaults/ldap.conf#L6-L13
Not necessarily it’s just specifying that your backend application should be aware if allowing header based authentication. Some applications also you to specify incoming sources for those headers.
I don’t think we will remove the feature, but OAuth/OIDC will likely be the most common path of integration in the near future.
There hasn’t really been a request for this before, you could likely do it right now with some work in the reverse proxy, but we haven’t tested it.
If there’s a desire we could definitely look in to it though.
Ah this looks very promising!
I’ve been trying to get the ldap companion to work in combination with the duo authentication proxy for several days but doesn’t work.
So I would definitely like to try this.
If only it would work with the subfolders that would be great.
@Amviewer I use LDAP and Duo day to day so if you have any issues please don’t hesitate to jump on Matrix for support, alternatively you can ask in the other support channel on the LSIO discord and if James or I happen to catch it, we’re happy to help.
@aptalca just gotta add the finishing touches like documentation updates but the base code for serving out at from a base_url is completed.
For any that want to give this a try ahead of time just pull authelia/authelia:feature-support-subpath.
https://github.com/authelia/authelia/blob/0a1e5d3dfc10fadc04093a2c0e617247802e6160/config.template.yml#L19-L20 includes the changes you need to make to your configuration file.
This should be merged into master and released within the next day or two.
1 Like