jenskeiner opened a new issue #2857: URL: https://github.com/apache/apisix/issues/2857
### Issue description The `authz-keycloak` plugin currently runs in the Openresty *rewrite* lifecycle phase. This is in line with the plugin development guidelines: "In APISIX, the authentication logic is implemented in the rewrite phase." However, this means it will run before most, if not all, other authentication plugins, e.g. `openid-connect`. I also think that authentication and authorization should both be done in the *access * phase which seems the most appropriate. I stumbled upon this when trying to set up authentication via OIDC (provided by a Keycloak instance) together with additional authorization (again via the same Keycloak instance). It seems appropriate to handle both in separate plugins, first authentication via `openid-connect` and then authorization via `authz-keycloak`. But since the used plugins run in different phases, they run in the wrong order. Wrong order here means that before the `openid-connect` plugin gets a chance to obtain an access token on behalf of the user via the Relying Party flow -- in a situation where no token is provided in the original incoming request -- the `authz-keycloak` plugin will already reject the request due to the missing token. A related issue, but one that should be fixed separately in the `openid-connect` plugin, is that the access token, if it is contained in a session cookie header, is not added in an "Authorization" header. So even if `authz-keycloak` would be running after `openid-connect`, it would not be able to extract the token if it was contained in a session cookie in the original request. A separate issue will be created to look into this. ### Environment * apisix version (cmd: `apisix version`): 2.0 * OS: Alpine Linux Docker image ### Minimal test code / Steps to reproduce the issue 1. Create a route with plugins `openid-connect` and `authz-keycloak` appropriately configured. 2. Verify that `authz-keycloak` runs before `openid-connect`. ### What's the actual result? (including assertion message & call stack if applicable) The result is explained above. A route that is protected only through `openid-connect` may work correctly with the plugin automatically redirecting to the authentication endpoint if no access token is provided in the request. Adding `authz-keycloak` to the route breaks that process by rejecting immediately when no token is found in the request. ### What's the expected result? The `authz-keycloak` plugin should run in the *access* phase so that it always runs after `openid-connect`. The respective plugin priorities are already ok, it's just that `authz-keycloak` needs to run in a different phase. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
