Bouncer

To protect a private party from hooligans, you could check the guests' invitations at the entrance yourself, or you could hire a bouncer. Authelia [1] acts as a bouncer for web applications to help you regulate access to services that do not offer their own access controls.

Thanks to Authelia, developers do not have to implement complex and time-consuming user management in their own web applications. Instead, they can deploy Authelia upstream of their own software with two-factor authentication and single sign-on (SSO) by default. In other words, you just need to log in to Authelia to access several authorized applications.

Authelia requires that communication with the web applications be protected by a reverse proxy. The software then connects to this reverse proxy (Figure 1) and checks all incoming requests, just as a bouncer would check invitations.

Figure 1: The reverse proxy submits every incoming request to Authelia to authorize access explicitly.

When you access a web application in a browser, your request is first sent to the reverse proxy, which forwards it directly to Authelia for inspection. When a browser knocks on the door for the first time, it does not have an Authelia session cookie. In this case, the tool redirects you to its own login page, where you first need to verify your ID by providing a username and password.

Double Security

Authelia can retrieve the login data from its own user database (a simple YAML file) or consult an LDAP server. Administrators can specify the password structure in a policy and, for example, stipulate that passwords need to contain at least one uppercase letter. To prevent attackers from simply brute-forcing the passwords, the number of login attempts can be limited. You can only log in again after a specified wait. Far more effective would be if the wait was automatically extended for each incorrect password, but that is beyond Authelia's capabilities.

To set the bar even higher for attackers, Authelia relies on two-factor authentication. The second factor is either one-time passwords, such as those generated by the Google Authenticator, push messages to cellphones, or hardware-based systems that comply with the FIDO2 WebAuthn standard (Yubikey USB sticks). Push messages require users to have the Duo Push app by Cisco on their smartphones.

After successfully logging in, Authelia transfers a session cookie to the browser. The reverse proxy submits all following requests to Authelia again. As the browser now has a session cookie, Authelia gives the reverse proxy the go-ahead to forward the request to the appropriate web application. By default, the session cookie then also applies to all subdomains of the domain controlled by the application. A flow chart in the Authelia documentation [2] demonstrates the process: On receiving the first request, Authelia redirects the browser to its own login page.

Because of this approach, Authelia does not need to know how a web application works, nor can it sniff the transmitted data (in the form of payloads). The tool itself only processes the authentication information. In principle, any HTTP-based services can be protected, such as microservice REST and GraphQL interfaces. Authelia currently works with the proxies listed in Table 1. Apache and Microsoft IIS are left out in the cold. As a general rule, all parties involved need to use HTTPS to prevent the session cookie from being tapped.

Authelia supports SSO on the basis of trusted headers, which both the proxy and the web applications must support. Authelia also acts as an OpenID Connect 1.0 provider, with authentication based on tokens. Although this function was still in beta when this issue went to press, it has already been received with great interest. The ownCloud Infinite Scale developers are planning to integrate Authelia into their groupware as an OpenID Connect provider [3].

Ruleset

Imagine you want a team to have access only to specific pages of a wiki. To do this, you would create a list of access rules that Authelia compares against every incoming request. In other words, the software also acts as an access control system.

The rules are stored in YAML format (Listing 1). The example is also based on the online documentation [4]. It allows all users from the hamburg group to access the wiki.example.com domain; the path must comply with the regular expression specified in resources. In the example, all the pages accessible below wiki.example.com/project/hamburg/ would be in the allowed scope. The requests must originate from the 192.168.2.0/24 subnet and are only allowed to use GET and POST methods.

§§number
access_control:
  rules:
    - domain: wiki.example.com
      resources:
        - '^/project/hamburg/.*$'
      subject: 'group:hamburg'
      policy: two_factor
      methods:
        - GET
        - POST
      networks:
        - 192.168.1.0/24

Authelia is implemented in Go as a compact binary that can be used directly without installation and without dependencies. The official packages on GitHub include templates for a systemd unit and a sample configuration. The developers recommend using their official Docker container, which only requires around 30MB of RAM [5]. Authelia is also designed for operation in Kubernetes. You can start several containers in parallel there to configure the tool for scaling or high availability. The official Helm chart ensures a quick setup.

In production operation, the tool requires further software components. It stores distributed session cookies in RAM or a Redis database. Log information, settings, and other data generated at runtime are encrypted and stored in a PostgreSQL, MySQL, or SQLite database. To verify the identity of new users, Authelia sends an email, so administrators must provide an SMTP server.

Conclusions

Authelia is not suitable for all use cases because of its mode of operation. For example, the software cannot help you if you want microservices to authenticate automatically. Also, some desirable functions for enterprises are still missing, including multidomain protection, although this feature is already on the project agenda.

The simple structure and clear configuration mean that Authelia can be set up quickly. This identity and access management software is therefore suitable for protecting small and medium-sized enterprises or retroactively protecting a domain's web applications against unauthorized access. Go developers in particular can integrate Authelia into their application and save themselves the trouble of having to program their own user management feature.