Unable to use bypass policy with basic authentication

[WiiPlayer2]

Bug Report

Description

I have a service for which I need basic authentication when accessed from outside my cluster but when inside my cluster the authentication should be bypassed. Using "normal" authentication everything works as intended but then the service is unusable from the outside because the Authorization header is not used. Using basic authentication I can authenticate myself from outside the cluster but requests inside it get an Unauthorized as response.

If it's relevant: I'm using traefik, authelia and whoami inside a kubernetes cluster + an external ldap backend.

Note: I probably already saw the relevant method(s) in handler_verify.go#399 but I'm not proficient in go (yet).

Expected Behaviour

Authelia authorizes requests inside the cluster but not outside it.

Reproduction Steps

N/A

Additional Information

access_control section:

  access_control:
    default_policy: one_factor

    networks:
      - name: cluster
        networks:
          - '10.42.0.0/16'

    rules:
      - domain: '*.{{ .Values.mainDomain }}'
        networks:
          - cluster
        policy: bypass

It might be (almost) enough to move the isTargetURLAuthorized call above the error check or handle a missing Authorization header as an anonymous user like when using a session cookie.

[nightah]

Thanks for filing the issue. Looking at the code we can confirm the scenario you suggested, so this is indeed a bug.

We'll refactor this to fix the issue and ensure that we have appropriate integration tests for this scenario.
If you feel comfortable enough to take a stab at it feel free, otherwise we'll try to get to it as soon as possible.

[WiiPlayer2]

Thank you very much for your response.
It would be fun to delve a little deeper into go and this project but at the moment I'm unable to promise I'll fix it myself but if I'll do I'll definitely link this issue.

[verybadsoldier]

I stumbled upon this behavior also and my use case is pretty much identical to the one described in the first post. So a fix would be awesome, thanks alot in advance!

[verybadsoldier]

As this issue is closed, I assume the issue is supposed to be fixed, right? I tested with latest master but it still happens for me.
Is there anything that needs to be taken into account?

I just played around with a very simple config that basically should always bypass:

access_control:
  default_policy: bypass
  rules:
    - domain:
      - notexisting.fantasy.org
      policy: bypass

When I access a domain using basic auth then I still need to login. I would have expected Authelia would just pass me through.

The log:

authelia | time="2023-05-13T20:34:01+02:00" level=info msg="Authelia untagged-v4.37.5 (master, 45a754d) is starting"
authelia | time="2023-05-13T20:34:01+02:00" level=info msg="Log severity set to trace"
authelia | time="2023-05-13T20:34:01+02:00" level=trace msg="Starting scan of directory  for certificates"
authelia | time="2023-05-13T20:34:01+02:00" level=debug msg="Registering client nextcloud with policy two_factor (two_factor)"
authelia | time="2023-05-13T20:34:01+02:00" level=debug msg="Registering client grafana with policy one_factor (one_factor)"
authelia | time="2023-05-13T20:34:01+02:00" level=info msg="Storage schema is being checked for updates"
authelia | time="2023-05-13T20:34:01+02:00" level=info msg="Storage schema is already up to date"
authelia | time="2023-05-13T20:34:03+02:00" level=trace msg="Registering Authz Endpoint" implementation=AuthRequest methods="[GET HEAD]" path=/api/authz/auth-request
authelia | time="2023-05-13T20:34:03+02:00" level=trace msg="Registering Authz Endpoint" implementation=ForwardAuth methods="[GET HEAD]" path=/api/authz/forward-auth
authelia | time="2023-05-13T20:34:03+02:00" level=trace msg="Registering Authz Endpoint" implementation=ExtAuthz methods="*" path_prefix=/api/authz/ext-authz
authelia | time="2023-05-13T20:34:03+02:00" level=trace msg="Registering Authz Endpoint" implementation=Legacy methods="*" path_prefix=/api/verify
authelia | time="2023-05-13T20:34:03+02:00" level=debug msg="Create Server Service (metrics) skipped"
authelia | time="2023-05-13T20:34:03+02:00" level=info msg="Startup complete"

...

authelia | time="2023-05-13T20:34:59+02:00" level=trace msg="Request hit" method=GET path=/api/verify remote_ip=192.168.2.230
authelia | time="2023-05-13T20:34:59+02:00" level=error msg="Error occurred while attempting to authenticate a request" error="header Authorization expected" method=GET path=/api/verify remote_ip=192.168.2.230 stack="github.com/authelia/authelia/v4/internal/handlers/handler_authz.go:63 (*Authz).Handler\ngithub.com/authelia/authelia/v4/internal/middlewares/bridge.go:54     (*BridgeBuilder).Build.func1.1\ngithub.com/authelia/authelia/v4/internal/middlewares/headers.go:16    SecurityHeaders.func1\ngithub.com/fasthttp/router@v1.4.18/router.go:433                      (*Router).Handler\ngithub.com/valyala/fasthttp@v1.47.0/http.go:158                       (*Response).StatusCode\ngithub.com/valyala/fasthttp@v1.47.0/server.go:2365                    (*Server).serveConn\ngithub.com/valyala/fasthttp@v1.47.0/workerpool.go:224                 (*workerPool).workerFunc\ngithub.com/valyala/fasthttp@v1.47.0/workerpool.go:196                 (*workerPool).getCh.func1\nruntime/asm_amd64.s:1598                                              goexit"
authelia | time="2023-05-13T20:35:00+02:00" level=info msg="Access to 'https://myreal.domain.org/' is not authorized to user '<anonymous>', sending 401 response with WWW-Authenticate header requesting Basic scheme" method=GET path=/api/verify remote_ip=192.168.2.230
authelia | time="2023-05-13T20:35:00+02:00" level=trace msg="Replied (status=401)" method=GET path=/api/verify remote_ip=192.168.2.230

[verybadsoldier]

@WiiPlayer2
Is this fixed for you?

[james-d-elliott]

It's fixed with the new authz endpoints.

[rocket357]

Just wanted to drop a quick add to this (I'm not sure if this is expected behavior), if I have two domains listed separately, as in:

    - domain: change.TLD
      policy: bypass
      networks:
      - net1
    - domain: wbo.TLD
      policy: bypass
      networks:
      - net1
      - net2

Everything works as expected. If, however, I attempt to "compact" these rules into a domain_regex, it gives the following in the logs:

time="2023-11-20T12:53:15-06:00" level=info msg="Access to https://change.TLD/ is forbidden to user " method=GET path=/api/verify remote_ip=10.X.X.X

Is that expected behavior? I have no issue listing them separately (as I have running currently) but I thought I'd mention that domain_regex breaks the bypass rules unexpectedly (for me, at least).

[james-d-elliott]

This is unrelated to the original issue, I'd suggest opening a discussion and include your full ACL's as with most functionality within authelia this is tested and unlikely to be a bug.

[rocket357]

Ahh, while gathering data to open a discussion, I stumbled upon the cause. Order matter, friends. I had a match higher up the chain that was interfering, so when I moved these rules to the top (domain or domain_regex...didn't matter), everything worked as expected.

Sorry for the noise!

[james-d-elliott]

Figured it'd be that or a problem with the regex. Glad you sorted it. No worries. For reference this discusses this issue in detail: https://www.authelia.com/configuration/security/access-control/#rule-matching-concept-1-sequential-order