Why using the same upstream twice w/ different auth methods does not work?

[plamenlakov]

Hello, I've been struggling a bit configuring APISIX with multiple authentication methods for the same upstream. That's why I've decided to only protect one of my routes and leave the other "public" so that I can at least test that it works.

Running APISIX 3.11.0 in STANDALONE mode

Unfortunately that's not the case:

• /api/* works (/api/backend/version), successfully protected by OIDC consequently serving responses from the specified upstream
• /public/* does NOT work responding with "Cannot GET /public/backend/version"

I've tried/looked into the following things:

• set public-api plugin on the /public/* route and did NOT work.
• changed the uri to /* and it DID work, but obviously I'd like a prefix :D
• double-checked if served upstream is even functional
• containers logs show no exceptions

I know it's pretty stupid to serve the same upstream both protected and public but for the sake of testing I've decided to pick this approach. It might very well be the sole reason why it's not working in the first place but I could not find any information regarding this. Ultimately I'd like to be able to setup mTLS authentication for the /public/* route, essentially providing two methods of authentication for the same backend resource.

Would be greatly appreciated if I can get some pointers as to why this is not working in the first place.

upstreams:
  - name: backend-api-upstream
    id: 1
    type: roundrobin
    nodes:
      - host: 172.17.0.1
        port: 3000
        weight: 1

routes:
  - uri: /public/*
    upstream_id: 1

  - uri: /api/*
    upstream_id: 1
    plugins:
      openid-connect:
        client_id: apisix
        client_secret: 6dE1dzUQFX1r7wa1hgyYGknJjaNrhmi1
        discovery: http://172.17.0.1:8441/realms/users/.well-known/openid-configuration
        introspection_endpoint: http://172.17.0.1:8441/realms/users/protocol/openid-connect/token/introspect
        bearer_only: true
        realm: users
        scope: openid email profile
        session:
          secret: "MjMzZDFlYzAtN2Y3OC00M2MyLTg1OGYtZTk1NGVkZDEyZjZhCg=="
      cors:
        allow_origins: "https://localhost:8000"
        allow_methods: "GET, POST, OPTIONS"
        allow_headers: "Authorization, Content-Type"
        expose_headers: "Content-Length, X-Access-Token"
        max_age: 3600
        allow_credential: true

#END

[dosubot[bot]]

I found a similar closed issue that might be relevant to your situation: Allow multiple authentication methods per route. This issue was resolved by a pull request that added the multi-auth plugin, which allows multiple authentication methods to be configured on the same route ^[1].

In your case, it seems like the issue might be related to how the routes are configured. Here are a few pointers that might help:

1. Route Matching: Ensure that the route /public/* is correctly defined and not being overridden by other routes. APISIX uses a priority system for route matching, so you might want to explicitly set a priority for your routes to ensure they are matched in the desired order.

2. Public API Plugin: The public-api plugin is used to expose APIs that are not exposed by default. If you want to make the /public/* route accessible without authentication, ensure that the public-api plugin is correctly configured on this route. However, note that the public-api plugin is typically used for exposing custom plugin APIs, so it might not be necessary for your use case ^[2].

3. mTLS Authentication: If you plan to use mTLS for the /public/* route, you can configure it by setting up SSL with client certificate verification. This can be done by configuring the SSL settings in APISIX to require client certificates for the /public/* route ^[3].

4. Testing and Debugging: Double-check the logs for any errors or warnings that might indicate why the /public/* route is not working. Ensure that the upstream is reachable and correctly configured.

If you want to provide multiple authentication methods for the same backend resource, consider using the multi-auth plugin to configure both OIDC and mTLS on the same route. This would allow you to test both authentication methods without needing to separate the routes.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}

[plamenlakov]

@dosu sure makes sense but as far as I'm aware mTLS configuration is not a plugin of type auth

[dosubot[bot]]

You're correct that mTLS is not configured as an authentication plugin in APISIX. Instead, mTLS is set up through SSL configuration, where you specify client certificate verification as part of the SSL settings for a route or service. This is done by configuring the SSL settings in APISIX to require client certificates, which is separate from the plugin-based authentication methods like OIDC.

To use mTLS alongside other authentication methods, you would configure mTLS at the SSL level and use plugins for additional authentication methods. The multi-auth plugin is specifically for combining multiple plugin-based authentication methods, so it wouldn't directly apply to mTLS configuration. Instead, you would configure mTLS as part of the SSL setup and then use the multi-auth plugin for any additional plugin-based authentication methods you want to apply to the same route.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}