Authorization in admin ui

[MuratovAS]

I studied the project a little.
I really like your application. Thank you.

I would like to point out some shortcomings.

1. I haven't found an easy way to disable admin authorization. I need to do this because I use the external authorization system authelia. I'm currently logging in twice.It would be cool to skip authorization if ADMIN_PASSWORD is empty.

2. The system allows you to brute-force determine the administrator's login. because the error indicates what exactly was entered incorrectly. On modern systems they usually write “login or password is incorrect”
   
   

3. Due to the extensive links in the admin menu, the proxy config is difficult to read. Also, before each update, I will have to check if anything new has been added.

-----------
    root /var/www/davis/public/;
    index index.php;

    rewrite ^/.well-known/caldav /dav/ redirect;
    rewrite ^/.well-known/carddav /dav/ redirect;

    charset utf-8;

    location ~ /(\.ht) {
        deny all;
        return 404;
    }

    location / {
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location /login {
        # Redirect server auth pages
        include /etc/nginx/conf.d/include/authelia-authrequest.conf;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location /dashboard {
        # Redirect server auth pages
        include /etc/nginx/conf.d/include/authelia-authrequest.conf;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location /users {
        # Redirect server auth pages
        include /etc/nginx/conf.d/include/authelia-authrequest.conf;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location /calendars {
        # Redirect server auth pages
        include /etc/nginx/conf.d/include/authelia-authrequest.conf;
        try_files $uri $uri/ /index.php$is_args$args;
    }

    location /adressbooks {
        # Redirect server auth pages
        include /etc/nginx/conf.d/include/authelia-authrequest.conf;
        try_files $uri $uri/ /index.php$is_args$args;
    }
    
    location ~ ^(.+\.php)(.*)$ {
        try_files       $fastcgi_script_name =404;
        include         fastcgi_params;
        fastcgi_pass    docker-davis;
        fastcgi_param   SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param   PATH_INFO        $fastcgi_path_info;
        fastcgi_split_path_info  ^(.+\.php)(.*)$;
    }
}

4. I don't use LDAP yet. I'm using OAuth. But, I agree with Specifying admin user via LDAP #106

[tchapi]

Hi there @MuratovAS 👋🏼

Thanks a lot for your comprehensive issue

1. I could create a new flag to bypass auth entirely, yes.
2. Fair point, I could change the wording for that
3. Where is this proxy config coming from? It's not the one in the README. I doubt you need all the location /xyz blocks to be honest, as you can do:

   location ~ ^/(login|dashboard|users|calendars|adressbooks) {
       include /etc/nginx/conf.d/include/authelia-authrequest.conf;
       try_files $uri $uri/ /index.php$is_args$args;
   }
   

4. The issue you link is valid yes, I just haven't got enough experience in LDAP to be able to do this right now unfortunately.

[tchapi]

Hi there

1. Would you mind testing Allow admin auth bypass #130 and see if it fits your use case / works correctly?
2. Same PR, I changed the message to make it the same for username and password

Hope this helps

[MuratovAS]

Wow. Thank you.
I checked, everything is fine.

A few thoughts.

• Page /Login is still available. I don't think this is a problem.
• To implement reliable authorization is quite difficult. Perhaps it is worth deleting this function, offering to use nginxauth + limit_req/fail2ban or more complex options such as Authelia. This will give a higher level of protection.
  All of course depends on the user.

[tchapi]

• Page /Login is still available. I don't think this is a problem.

Agreed, it's expected yes

• To implement reliable authorization is quite difficult

Yes, but the login/password mechanism here is 1. not that bad, 2. relies on standards and on the Symfony stack which is ok and 3. a good option for 90% of users, so all in all I'm fine with leaving it + offering the option of strengthening the protection with each user's own choice by bypassing it (your suggestion that I added)

[tchapi]

I'm closing this for now since 4.4.1 was just released :)