Need some help with Authelia plz

aptalca · May 5, 2020, 8:10pm

@nightah we have an initial draft for incorporating authelia into letsencrypt and the reverse proxy confs. We would appreciate your feedback

kevdog · May 5, 2020, 9:51pm

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.

nightah · May 23, 2020, 10:50am

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.

https://github.com/linuxserver/docker-letsencrypt/blob/c2cb1d6e9ca0e1eb0493e9f3bfc513617f71cc9d/root/defaults/authelia.conf#L7-L8 can be removed to avoid any confusion especially given it’s commented.

aptalca · May 6, 2020, 4:10pm

@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

nightah · May 7, 2020, 12:30am

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.

Amviewer · May 16, 2020, 8:40pm

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.

nightah · May 23, 2020, 10:48am

@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.

aptalca · May 19, 2020, 1:57am

@nightah excellent! I’ll try it out tomorrow

Amviewer · May 19, 2020, 7:26pm

Thanks that would be very helpful. I’m very close to making it work but every time I put the Duo proxy in between the LetsEncrypt and the LDAP server it fails.
I’ll create a separate topic as this is not relevant to this topic.

nightah · May 23, 2020, 10:51am

The path changes have been released under v4.19.0, docs here.
You can run it with any of the following tags:

master (you probably don’t want this unless you want to be running bleeding edge).
4.19.0
4.19
4

aptalca · May 22, 2020, 7:10pm

@nightah I’m driving myself crazy over here with the subfolder

I have it partially working, just can’t go all the way.

The one concerning thing I noticed is that, if the auth request server is not set up correctly (wrong address, no connection, etc.), nginx just lets the user in. I would expect nginx to block by default if auth request is not successful. I’ll look into it more later.

With authelia subfolder, my assumption is that all pages are served under the subfolder, including the login page and all api call addresses?

If so, I set it up so that auth request is set to /authelia/api/verify, which is proxied to https://authelia:9091/authelia/api/verify with a ^~ for exact match, and that part seems to work.
The error page 401 is set to redirect to /authelia/?rd=$target_url; and location block /authelia proxies http://authelia:9091

That part semi works, because although it redirects to the login page, the ?rd=$target_url gets stripped, so after successful auth, it redirects to the naked domain rather than the original requested subdomain.

I keep getting different results with trailing slashes in different places and it’s driving me nuts.

Here are the confs I’m currently using:
authelia-server.conf:

# Virtual endpoint created by nginx to forward auth requests.

location /authelia {
    include /config/nginx/proxy.conf;
    resolver 127.0.0.11;
    set $upstream_authelia authelia;
    proxy_pass http://$upstream_authelia:9091;
}

location ^~ /authelia/api/verify {
    internal;
    resolver 127.0.0.11;
    set $upstream_authelia authelia;
    proxy_pass_request_body off;
    proxy_pass http://$upstream_authelia:9091;
    proxy_set_header Content-Length "";

    # Timeout if the real server is dead
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

    # [REQUIRED] Needed by Authelia to check authorizations of the resource.
    # Provide either X-Original-URL and X-Forwarded-Proto or
    # X-Forwarded-Proto, X-Forwarded-Host and X-Forwarded-Uri or both.
    # Those headers will be used by Authelia to deduce the target url of the user.
    # Basic Proxy Config
    client_body_buffer_size 128k;
    proxy_set_header Host $host;
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr; 
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Host $http_host;
    proxy_set_header X-Forwarded-Uri $request_uri;
    proxy_set_header X-Forwarded-Ssl on;
    proxy_redirect  http://  $scheme://;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    proxy_cache_bypass $cookie_session;
    proxy_no_cache $cookie_session;
    proxy_buffers 4 32k;

    # Advanced Proxy Config
    send_timeout 5m;
    proxy_read_timeout 240;
    proxy_send_timeout 240;
    proxy_connect_timeout 240;
}

authelia-location.conf:

auth_request /authelia/api/verify;
auth_request_set $target_url $scheme://$http_host$request_uri;
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
error_page 401 =302 /authelia/?rd=$target_url;

heimdall proxy conf:

# make sure that your dns has a cname set for heimdall

server {
    listen 443 ssl;
    listen [::]:443 ssl;

    server_name heimdall.*;

    include /config/nginx/ssl.conf;

    client_max_body_size 0;

    # enable for ldap auth, fill in ldap details in ldap.conf
    #include /config/nginx/ldap.conf;

    include /config/nginx/authelia-server.conf;

    location / {
        # enable the next two lines for http auth
        #auth_basic "Restricted";
        #auth_basic_user_file /config/nginx/.htpasswd;

        # enable the next two lines for ldap auth
        #auth_request /auth;
        #error_page 401 =200 /login;

        # enable the next line for authelia
        include /config/nginx/authelia-location.conf;        

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app heimdall;
        set $upstream_port 443;
        set $upstream_proto https;
        proxy_pass $upstream_proto://$upstream_app:$upstream_port;

    }
}

Amviewer · May 22, 2020, 10:13pm

Been trying to get this running with the lite config but keeps coming back its missing parts in the configuration.yml.
JWT secret…what do I do with that…? The documentation isn’t very clear on what to put there or how to generate it. If I put file notifiers in there it still wants smtp or filesystem.

I’m I using the wrong tag for the docker with latest?

nightah · May 23, 2020, 5:58am

@aptalca was close, the redirect seems to be stripped because there’s no server notation, your authelia-server.conf is fine just a small change for the config that you provided to adapt the authelia-location.conf:

authelia-location.conf

auth_request /authelia/api/verify;
auth_request_set $target_url $scheme://$http_host$request_uri;
auth_request_set $user $upstream_http_remote_user;
auth_request_set $groups $upstream_http_remote_groups;
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
error_page 401 =302 https://$server_name/authelia/?rd=$target_url;

nightah · May 23, 2020, 6:12am

@Amviewer step 4 in the Lite docs tells you to update your configuration.yml and docker-compose.yml with your respective domains and secrets.

There’s a note in the example config for all the respective secrets.

aptalca · May 23, 2020, 4:31pm

yup, that fixed it. Thanks. I ended up using $scheme://$http_host/authelia/?rd=$target_url for consistency

I just noticed that the reset password email includes a reset link without the subfolder

nightah · May 23, 2020, 4:39pm

Good spot, thanks for that I’ll fix that up.

Also $scheme:// makes sense for consistency but just be aware it won’t work if it happens to land on a http:// entrypoint.

Amviewer · May 23, 2020, 6:52pm

I didn’t use docker compose.
Just portainer and pulled the :latest and did a bind for the etc/authelia and put the configuration.yml there.
Don’t really like the stacks which happens when you use compose. I like to control which network its in etc…which you can do…I know.
Will try again later and use the 4.19 tags and see if it works.

aptalca · May 24, 2020, 1:06am

@nightah
Here are the PRs ready for testing:

nightah · May 24, 2020, 2:18am

Nice work @aptalca, we’ve also released a patch release v4.19.1 for the incorrect hyperlink if running with path specified.

Amviewer · May 24, 2020, 4:51pm

Finally got Authelia to work and put in all the bits for Nginx but I get this error in the LetsEncrypt container.

nginx: [emerg] unknown “upstream_authelia_external” variable

It seems to hang on this part in the subfolder

enable the next four lines for Authelia

auth_request /authelia;
proxy_set_header Remote-User $user;
proxy_set_header Remote-Groups $groups;
error_page 401 =302 $upstream_authelia_external/?rd=$target_url;