Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

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

Answeredbymikyll
plamenlakov asked this question inQ&A
Discussion options

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: 1routes:  - 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
You must be logged in to vote

changed the uri to /* and it DID work, but obviously I'd like a prefix :D

To achieve what you described (and I think I understood 😄), you'll need to useproxy-rewrite plugin, to remove the prefix before forwarding the request to the upstream.

Here's an example with your configuration:

upstreams:  -name:backend-api-upstreamid:1type:roundrobinnodes:      -host:172.17.0.1port:3000weight:1routes:  -uri:/public/*upstream_id:1plugins:# This plugin will remove the prefix "/public"proxy-rewrite:regex_uri:          -^/public/(.*)          -/$1  -uri:/api/*upstream_id:1plugins:# Uncomment t…

Replies: 2 comments 3 replies

Comment options

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 themulti-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: Thepublic-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 thepublic-api plugin is correctly configured on this route. However, note that thepublic-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 themulti-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 toDosu, mention@dosu.

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

You must be logged in to vote
2 replies
@plamenlakov
Comment options

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

@dosubot
Comment options

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. Themulti-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 themulti-auth plugin for any additional plugin-based authentication methods you want to apply to the same route.

To continue talking toDosu, mention@dosu.

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

Comment options

changed the uri to /* and it DID work, but obviously I'd like a prefix :D

To achieve what you described (and I think I understood 😄), you'll need to useproxy-rewrite plugin, to remove the prefix before forwarding the request to the upstream.

Here's an example with your configuration:

upstreams:  -name:backend-api-upstreamid:1type:roundrobinnodes:      -host:172.17.0.1port:3000weight:1routes:  -uri:/public/*upstream_id:1plugins:# This plugin will remove the prefix "/public"proxy-rewrite:regex_uri:          -^/public/(.*)          -/$1  -uri:/api/*upstream_id:1plugins:# Uncomment this if you also need the same behaviour for "/api"# proxy-rewrite:#   regex_uri:#     - ^/api/(.*)#     - /$1openid-connect:client_id:apisixclient_secret:6dE1dzUQFX1r7wa1hgyYGknJjaNrhmi1discovery:http://172.17.0.1:8441/realms/users/.well-known/openid-configurationintrospection_endpoint:http://172.17.0.1:8441/realms/users/protocol/openid-connect/token/introspectbearer_only:truerealm:usersscope:openid email profilesession: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:3600allow_credential:true#END

The reason it works like that is due to how APISIX handles route pattern matching with wildcard characters: when you define a route like/public/*, the* wildcard in URI pattern matches anything that comes after/public/, but it also keeps/public/ prefix intact,by default. Without theproxy-rewrite plugin, as you already noticed, the upstream does, in fact, receive a request to/public/backend/version, which it doesn't handle.

You could also make it work by changing the upstream server/service to handle both/public/backend/version and/api/backend/version, but I don't think that's what you want.

Hope that helped 🙂

You must be logged in to vote
1 reply
@plamenlakov
Comment options

Thank you for the taking the time to propose a solution@mikyll. Incredibly appreciated :)

Answer selected byplamenlakov
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
2 participants
@plamenlakov@mikyll
[8]ページ先頭
©2009-2025 Movatter.jp