Add an "is in group" verification endpoint

[SerialVelocity]

Hey,

It would be great if it was possible to verify whether a user was in a group (similar to your /verify endpoint but for groups instead of users).

Use-case

When using software such as rancher/traefik/docker-gen, you try and keep all configuration for that service together.

For instance, you add a label to your docker container for traefik like:

traefik.frontend.rule=Host:test.traefik.io

and that will expose your application on the host test.traefik.io.

Custom labels can be used by docker-gen (and soon traefik will do something similar) to generate blocks to insert into their nginx configuration. One example of this would be adding a label such as virtual.auth.group: admin would generate a block to add to nginx such as:

        location /auth_verify {
            internal;
            proxy_set_header  X-Original-URI $request_uri;
            proxy_set_header  X-Real-IP $remote_addr;
            proxy_set_header  Host $http_host;

            proxy_pass        http://authelia/verify?group=admin;
        }

and this would make it so only people in the admin group can access the secured endpoints.

Cheers,
Ben

[SerialVelocity]

Oh, btw, the way Traefik does authentication from version 1.4 (unsupported before 1.4) is that if it is a 2XX error code, it continues, otherwise it returns the authentication server's response, so to get Traefik working with Authelia, an nginx proxy layer has to be running which converts 401 responses to 302 forwards.

[clems4ever]

Hello @SerialVelocity, I don't get exactly what you are trying to solve here. Is it the fact that the nginx block is not automatically generated for you or any issue while authenticating some user by his/her group?

Btw, Authelia is not meant to be bound to any reverse proxy so it is expected that Authelia's container does not generate the proxy block for nginx in particular and that you should convert the response in each specific proxy (be it nginx, Traefik or any other).

[clems4ever]

Can you please clarify the title and/or split the ticket for treating the issues separately?
Thank you very much for the feedback btw. I'd be glad to know if you already use Authelia in any way?

[SerialVelocity]

So, it would be nice to have an endpoint like /verify-group that just checks you are part of the specified group. This then allows the reverse proxy to handle which services are accessible to which groups rather than having to modify and bounce Authelia. (Maybe /verify-user would also be good if I want a service to only be accessible by one user)

Main use-case: Without Authelia, all of my routing config lives in the service configuration. For instance, to add things to my NGINX front-door, I add virtual.host and virtual.port tags (see here). To add things to my traefik "middle-door", I add traefik.enable, traefik.port, and traefik.frontend.rule tags (see here). It would be nice if I could add another tag (something like virtual.auth.group) which I could automatically convert into an nginx "auth" block (using docker-gen, I don't expect Authelia to handle the configuration generation).

Hope this makes it clearer.

You can ignore the second post, I already created a ticket about that :)

[clems4ever]

Hello @SerialVelocity, I agree that defining specific endpoints for that matter would allow you to handle the access control at the level of the proxy but unfortunately it does not prevent you to change Authelia's config anyway since Authelia needs at least the global domain to create correct session cookies. Isn't it a problem for you?

[SerialVelocity]

Things like the global domain are unlikely to change and therefore are fine to set in config. Variables like that are usually thought about as constants.

Containers change more often. The main use-case is to centralise the subdomain configuration so when adding a new subdomain you don't need to change NGINX, DNS, auth, etc.

Another way of putting this is, things you define once for Authelia (like global domain) as fine. Things that you define once per subdomain/path are the issue.

An alternative way of doing this, is to add support for backends. For instance, traefik supports many backends ranging from file to Kubernetes or Rancher. That is a huge investment though so probably not worth it.

[clems4ever]

I see your point. I will implement a new endpoint where one could combine parameters 'users' and 'groups' in the query.

With nginx, it would give you the same level of granularity for access control as the new embedded per-resource mechanism I merged yesterday (not true for Traefik since the forwarded auth request is a global config applying to all the frontends). So I guess after the new endpoint is implemented, one could go one way or the other simply depending on the use case.

[rlex]

was this ever implemented? oauth2_proxy deals with that in a very nice way - you just append ?allowed_groups=admin to /auth endpoint, basically the same as OP said

[infused-kim]

I am also looking for exactly this and am actually considering switching to a different solution if it doesn't exist.

[james-d-elliott]

I am also looking for exactly this and am actually considering switching to a different solution if it doesn't exist.

The OP's feature request wasn't no. If some additional context is given that would help identify the feature expected, I'd be willing to spend some time getting something like this to work. Additionally there have been multiple ideas discussed here.

The specific concern I have is how should a request like this actually be authorized, is it based on only the criteria of the endpoint itself? Or is it expected the ACL also be taken into account? I feel like there is a lot of room here for misconfiguration and misunderstandings. If you'd like you can reply here or chat on our matrix server/discord server if that's easier.

The most logical approach I can see without making it hard to maintain is:

1. A new endpoint is created called /api/verify/advanced or /api/verify/custom.
2. The endpoint by default uses the default_policy unless it's deny in which case it uses two_factor.
3. The endpoint accepts multiple query arguments:
   1. Action Arguments:
      1. policy: optional, specifies a policy to override the default_policy, must be one_factor, or two_factor.
   2. Criteria Arguments (each item in the list must match, logical AND):
      1. domain: required, specifies the domain the request is for similar to the domains endpoint
      2. users/groups: optional, specifies a comma delimited list of user and group names that are authorized, performed as a logical OR (i.e. users=john&groups=admin,dev would allow either john OR anyone who's a member of admin or dev.
      3. networks: a list of NAMED access control networks that are allowed (least important and most likely one to be difficult to implement).
4. The endpoint will not be compatible with subject (other than what is specified above), methods or resources rule.
5. The endpoint will not take into account any other access control rule.