juzhiyuan commented on issue #12888:
URL: https://github.com/apache/apisix/issues/12888#issuecomment-4364995811

   Thanks for the detailed example @ch-gr!
   
   For Apache APISIX OSS today, this is not a built-in _`openid-connect` to 
Consumer mapping feature_. The `openid-connect` plugin authenticates against 
the external IdP and can expose token/userinfo data, but it does not create or 
associate an APISIX Consumer by itself. 
   
   The general direction can work for a custom plugin, but I would add a few 
guardrails:
   
   1. Make sure the plugin runs after `openid-connect` has validated the token 
and before plugins that read `ctx.consumer` / `ctx.consumer_name`, such as 
`consumer-restriction`. In 3.14.1, `openid-connect` has priority `2599` and 
`consumer-restriction` has priority `2400`, so the custom plugin priority 
should be between them.
   2. Do not trust a client-supplied `X-ID-Token` header. The plugin should 
only use data that was produced after successful OIDC validation, and incoming 
spoofed identity headers should be stripped or overwritten.
   3. This also will not create a real Admin API Consumer. It only attaches 
Consumer context for the current request, so it will not be listed or managed 
as a normal Consumer.
   
   If the goal is only role/scope-based authorization, using `openid-connect` 
`required_scopes` or a dedicated custom authorization plugin based on validated 
OIDC claims may be simpler than forcing the identity into the Consumer model.
   
   If the goal is first-class support for mapping OIDC/JWT claims to an APISIX 
Consumer or Consumer Group, I think this should be tracked as a feature 
request/product gap. For reference, #13037 is related and discusses some design 
concerns, especially around when claims are trusted and how this should fit 
into the existing Consumer/Consumer Group merge flow.
   


-- 
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.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to