Allow the same OIDC configuration target multiple HTTPRoutes

[Huabing Zhao]

Initially raised by @sadovnikov in #2913. Spit it out since it's another issue.

The biggest inconvenience for us is the need to register in IDP additional allowed redirect URIs for every new service deployment, which can happen even from a fix/feature branch. And, of course, the cleaning up IDP upon removal of the temporary deployments.

Attaching OIDC security policies to Gateways (all HTTP Routes of the gateway) will lead to finding a way to detach them from HTTP Routes, which do not require oauth2 authentication. These are "welcome" pages with invitations to log in. Other examples are health and metrics probes, covered or not by JWT security policies.

I tried a workaround with a fallBack HTTP route on / and a fallback security policy with the identical configuration of the OIDC issuer. It failed with "too many redirects" because, I think, the two filters used different cookies and hmac secrets.

Gateway
  HTTPRoute /myapp
  FallBackRoute /. (using service without any endpoints)

  SecurityPolicy 
    target:  HTTPRoute
    OIDC:
      issuer ...
      redirectURL  https://www.example.com/oauth2/callback     # without /myapp in the path
	  
  SecurityPolicy (fallback)
    target:  FallBackRoute
    OIDC:
      issuer ...
      redirectURL  https://www.example.com/oauth2/callback     # without /myapp in the path

Should OIDC configuration be extracted into a separate resource? Then, security policies can reference both HTTP Route and the filter

[Viktor Sadovnikov]

Gateway API is changing support multiple targetRefs. However, using selector on labels instead of targetRefs[] is more in Kubernetes style and would allow pre-configuring the security policy for HTTP Routes, which can be created later.

[Huabing Zhao]

Gateway API is changing support multiple targetRefs. However, using selector on labels instead of targetRefs[] is more in Kubernetes style and would allow pre-configuring the security policy for HTTP Routes, which can be created later.

I prefer to keep it aligned with gateway API, but let's discuss it in next week's meeting.