You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@apisix.apache.org by GitBox <gi...@apache.org> on 2020/11/17 10:28:18 UTC

[GitHub] [apisix] jenskeiner commented on issue #2764: bug: OIDC plugin may not be setting request headers correctly.

jenskeiner commented on issue #2764:
URL: https://github.com/apache/apisix/issues/2764#issuecomment-728837269


   @spacewander I'm open to submitting a PR, but would need to set up a proper development environment on my end first. I was hoping original developers would be quicker to fix for that reason, but I'll see what I can do. Can't guess an ETA at the moment.
   
   Also, the reason I noticed the issue was when I tried to combine this plugin with the `authz-keycloak` one. Once a request is authenticated, subsequent requests from the user should contain an access and/or ID token in suitable headers or a cookie header. However, `authz-keycloak` only looks for a bearer token in the `Authorization` header and doesn't seem to consider cookie headers or the `X-Access-Token` header used by this plugin.
   
   Another issue to consider in a separate ticket is that `authz-keycloak` runs in the rewrite phase, so always before this plugin which runs in the access phase. This means that unauthenticated requests don't go through the OIDC Relying Party flow so that an access token can be obtained, but are rejected by `authz-keycloak` right away. I think `authz-keycloak` should always run after this one, and both plugins need to use a consistent scheme of handling tokens and other information.
   
   In the end, my goal is to have a clean flow that can re-direct unauthenticated requests to an identity provider and obtain tokens et cetera transparently, and after that, for authenticated requests, can use token contents and Keycloak to check authorization. I imagine this is a fairly common case for securing APIs.
   
   Any thoughts on these other issues?


----------------------------------------------------------------
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:
users@infra.apache.org