apache / apisix

The Cloud-Native API Gateway
https://apisix.apache.org/blog/
Apache License 2.0
14k stars 2.45k forks source link

help request: openid-connect different clients unexpectedly shared the same auth session #11229

Open RobWagMLP opened 2 months ago

RobWagMLP commented 2 months ago

Description

Hi, first of all, thanks a lot for that great piece of software. So far the only open source gateway that has (almost) all you need. I am just facing one issue, that i am not sure about, if it is intended or if i might be doing something wrong.

I am having 2 apps, with a frontend and a backend each, running under different hosts. These are handled in an apisisx-instance together with keycloak as idp and oidc-plugin. my keycloak has 2 different clients, one for App A and one for App B. I defined rules in apisix, to use the corresponding client-id and client-secret according to path and host. So something like that:

- uri: /web/app1
          hosts:
            - app1.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_a}
              client_secret: ${client_secret_a}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: auth
              logout_path: /logout
              session: 
                secret: ${session_secret_a}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-web.domain.node_a": 1
1- uri: /api/*
          hosts:
            - app1.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_a}
              client_secret: ${client_secret_a}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: deny
              logout_path: /logout
              session: 
                secret: ${session_secret_a}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-api.domain.node_a": 1

 - uri: /web/app2
          hosts:
            - app2.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_b}
              client_secret: ${client_secret_b}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: auth
              session: 
                secret: ${session_secret_b}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-web.domain.node_b": 1
1- uri: /api/*
          hosts:
            hosts:
            - app2.mydomain.de
          plugins:
            openid-connect:
              client_id: ${client_id_b}
              client_secret: ${client_secret_b}
              discovery: {kc_uri}/realms/{kc_realm}/.well-known/openid-configuration
              realm: {kc_realm}
              unauth_action: deny
              session: 
                secret: ${session_secret_b}             
          upstream:
            type: roundrobin
            discovery_type: dns
            nodes:
              "internal-api.domain.node_b": 1

The behaviour i would have expected here, is that when logging into A, a session for A is created. And when accessing B, apisix would recognize that this is a different app with a different client and different session secret, and therefor the session from A should not be applied here and another login is enforced when accessing web2.

Instead i am simply also already logged in against B with the user from A.

The only way i can think of atm, to overcome this is running one apisix instance per application, but thats propably not how it should be.. So what i would like to have, is that a session is only valid for the client, we used for login, or some other way to configure the scope of session-validity. Easiest way would be to propably simply define the session-cookie name, that is checked against. As far as i can see cookies always identify like "session=", and if something like that is found, it is simply treated as authenticated. Using different session-secrets also didnt do the job. So am i missing something here, or is this intended? And if not, could this be added? Would be a really helpful feature :) Best regards Robert

kayx23 commented 2 months ago

Instead i am simply also already logged in against B with the user from A.

Can you describe this behaviour more in details? Is it like:

RobWagMLP commented 2 months ago

Yes of course, sorry if i was not precise enough. So what i want is

instead it is like you described, user A is also logged in app2 , instead of beeing asked for credentials for app2. Basically what i am asking for is an option to configure which routes belong to a session. So for example that i could say routes /web/app1 and /api/ with host app1.mydomain.de get session_id A, and /web/app2 and api with host app2.mydomain.de get session_id B, so that if a user with session_id A comes to web/app2, he is not treated as authenticated. Maybe thats already somewaht there and its a bug on my side, but so far i couldnt figure anything out that would trigger that behaviour. Already checked a bit of the code to to figure out if can make some plugin for myself here, but my lua-knowledge tends towards zero :\

kayx23 commented 2 months ago

That is so very strange... Especially if you said using different session secrets also doesn't work as intended. I understand your issue now but I'm working on other things at the moment. I can surely circle back when I have time.

RobWagMLP commented 2 months ago

That would be really great. The only way i could achieve that target is by having my kc-clients in different realms, wich is actually okay for the moment, but it would be really nice to be able to configure that a bit more independently from that. I can provide you my full configuration if you want, its just a bit longer and the example i provided mirrors pretty well what i have there :)

kayx23 commented 2 months ago

cc @shreemaan-abhishek

damoshushu commented 1 month ago

I encountered the same issue, and I had made a pull request https://github.com/apache/apisix/pull/11286 to solve this problem. Test passed