Support for filter on webhook json response body

[gberche-orange]

Is your feature request related to a problem? Please describe.

Need to leverage a 3rd party authorization endpoint which returns the authZ decison in json body (and not as http status/headers)

Describe the solution you would like

a new filter which would combine

• webhook filter, to specify which authZ endpoint to query
• an opa policy on the webhook response, sharing some similarities with opaAuthorizeRequest

Describe alternatives you've considered (optional)

Using existing filters

• webhook
• opa filters

Additional context (optional)

Some 3rd party systems provide authorization decisions as Json documents instead of HTTP headers.

The cloudfoundry platform as a service, relies on such mechanism, where it exposes an api endpoint /v3/service_instances/:guid/permission to verify whether the current browser session is authenticated and authorized to perform two static actions: read and manage. This endpoint returns a json payload such as

{
  "manage": true,
  "read": true
}

See more details in https://docs.cloudfoundry.org/services/dashboard-sso.html#checking-user-permissions

The service uses a GET to the /v3/service_instances/:guid/permissions endpoint on the Cloud Controller. The request must include a token for an authenticated user and the service instance GUID.

Would you like to work on it?
Yes, but no golang skills and little time

[AlexanderYastrebov]

Hello,
this sounds similar to https://github.com/zalando/skipper/blob/master/docs/reference/filters.md#tokenintrospection (which performs some standard endpoint discovery) and https://github.com/zalando/skipper/blob/master/docs/reference/filters.md#tokeninfo

If you have only a single service guid (e.g. when running skipper as auth sidecar for a microservice) then maybe it could be possible to configure https://auth.test/v3/service_instances/foobar/permission as a tokeninfo url via commandline flag and use existing filter like oauthTokeninfoAllKV("manage", "true", "read", "true") (we may need to add some implicit type conversion to support boolean KVs though).
For multiple guids maybe we could consider adding parametrized tokeninfo family of filters that accept tokeninfo url as an argument per filter instance.

[gberche-orange]

Thanks a lot for your prompt answer! My use case requires verifying permission for a single single guid so your proposal sounds great. How hard would be the type conversion from boolean to string ? Is it something that could fit a release soon ?

[gberche-orange]

Sorry, the guid to check is indeed dynamic, and I need to use the filter within the k8s ingress controller, so as you said this would require a "new tokeninfo family of filters that accept tokeninfo url as an argument per filter instance"