Access control through headers

[schklom]

Some projects use headers to authenticate users. For example, Radarr and Sonarr allow access to their API using either a query parameter (http://site.com/api/...?apikey=mykey) or a header (X-API-Key: mykey).

It would be good to add headers to access control in Authelia.
What I mean could look like the following, where only queries to ^/groups/dev/.*$ with X-API-Key set to mykey, or queries with X-API-Key set to mykey2, would be allowed

access_control:
  rules:
    - domain: dev.example.com
      policy: bypass
      resources:
        - - header: X-API-Key
            value: mykey
            query: '^/groups/dev/.*$'
        - - header: X-API-Key
            value: mykey2

and a similar logic to https://www.authelia.com/configuration/security/access-control/#query could be used.

I'm sure there is a better way to do this, but this is all i can think of tonight :P

Edit: forgot about policy

[james-d-elliott]

This will be something we have to carefully consider.

The issues with this are actually quite substantial and not trivial at all. To list a few:

• Headers are not something that can easily be controlled by client applications such as browsers or via values set by an application in said client application. This means this is only really useful for programmatic use.
• The redirection flow for an invalid credential is likely to be a bad UX. It would be better to handle this via a means that is backed by standards which work well for programmatic use.
• Administrators are very likely (due to ignorance) to use this in insecure ways which we will have to aim to prevent due to our security by design mantra. Allowing a misunderstanding to break security easily is a very bad choice.
• This method is arbitrary and can't associate users with requests which is bad for auditability (the rule MUST be bypass for this to be useful), other methods would permit this and probably solve a lot of the other issues (i.e. OAuth 2.0 / OAuth 2.1 / OpenID Connect 1.0 access tokens via the bearer scheme could be linked to subjects / users and audiences which would remove this additional configuration requirement entirely)

[james-d-elliott]

We will likely not be implementing this specific architecture, instead we've implemented this comparable feature:

https://www.authelia.com/integration/openid-connect/oauth-2.0-bearer-token-usage/

[tcurdt]

Thanks for the pointer @james-d-elliott. To me it's not clear how the interaction flow would look like when protecting a non-interactive resource though. How does the user grant access to the client? They cannot be redirected to authelia as such.

[james-d-elliott]

For machine requests the client credentials flow can be used so the client can just perform the request from the token endpoint providing the required parameters. For user-interactive implementations the authorization code flow would be appropriate.

There is an example configuration for each but I have no documentation on the specific flows. These flows work exactly per the standards however with the addition that we support an audience parameter which can request a subset of audiences rather than relying on the implicit audience policy.

This section describes how you'd grant access to a token using the client credentials flow, and this one describes how to configure the authorization endpoint (utilized by your proxy) to accept such a bearer token (keep in mind there is also a HeaderProxyAuthorization variant of the HeaderAuthorization strategy which uses the other header).

[tcurdt]

Maybe I am just lacking knowledge of the standards.
Let me be a little more specific:

What I was hoping to find:

1. user creates API credentials in authelia
2. client uses these API credentials

How it sounds like:

1. client makes request to API
2. response informs that auth is required
3. client is non-interactive and cannot open a web page or get a token without having prior credentials
4. fulfil OAuth by looking at the logs and opening an URL to finish the auth returning a token
5. client can now use new token to make the API request

Am I on the right track?

[james-d-elliott]

Somewhat, the only exception is the Client Credentials flow has no UI interaction at all. It's entirely an API flow. Hence why an admin must be extremely explicit about what clients can access what via the subject ACL enhancement which specifies a client id.

As far as users requesting credentials, technically we have a very alpha and work in progress CLI which allows users to obtain tokens which will be the basis for any UI variant of this kind of feature in the future. It allows requesting tokens but it's not documented or well tested yet.

The tokens are effectively impersonation tokens which have access to everything the user has access to provided the configuration allows that particular audience.