First class support for path based APIs in AuthConfig

[eshepelyuk]

Currently, AuthConfig should be unique per host. In case of path based API, i.e. when routing is path based, using the same host, AuthConfig becames monstrous, since rules for every API should be put inside the same AuthConfig. Another disadvantage is that rules must be delivered seperately from API, i.e. when API is deployed or removed, the central AuthConfig must be patched.

It would be great to have path based support as 1st level functionality, so every path based API could bring its own AuthConfig without needling to maintain single monolithic instance.

I am aware of this functionality
https://github.com/Kuadrant/authorino/blob/main/docs/user-guides/host-override.md

but its main disadvantage - is mandatory access to raw Envoy config, that may be impossible if Envoy is used as a part of API Gateway product like Envoy Gateway or Contour etc

[guicassolato]

Thanks for opening this discussion, @eshepelyuk!

Have you considered specifying the host key in the Attributes.ContextExtensions of the CheckRequest message?

This is described in the Host lookup section of the docs. Basically it means the hosts field of the AuthConfig can be any arbitrary string you want actually, not necessarily the host of the context HTTP request, as long as you can tweak with the context extensions.

A host entry supplied in the CheckRequest.Attributes.ContextExtensions map supersedes the original host of the request in the AuthConfig lookup.

Envoy, for example, allows you to set context extensions per-route (i.e. per HTTP path, or any HTTP route matcher really). You can define as many AuthConfigs as route path matchers. Just inject a different host=<some-unique-identifier> in the context extensions of each route. Authorino will then lookup for the right AuthConfig for each path.

[eshepelyuk]

Hello @guicassolato
In the end of my post, I've described why me and others can't use this feature.

[guicassolato]

Roger that, @eshepelyuk. The GitHub notification I received by email did not include that extra detail added later on, but good to know.

[guicassolato]

The main problem with path-based lookup is that paths are complex structs, often including variable parts and requiring matching rules beyond 'exact match'.

Say, e.g., hosts (the AuthConfig field, which probably would have to be renamed to something else) lists example.com/my-path. First problem we have is what do we do if the request goes to example.com/my-path/something-else? Either the patch matcher only supports exact paths or we need to introduce complexity. I.e. some example.com/my-path* regex/glob to represent path prefix instead of exact path.

Say we support path prefixes, would example.com/my-path* mean the same as example.com/my-path/*? Only the leading / alone is yet another problem to have in mind – optional or not optional for the lookup.

Another problem is path with variables, especially variables in the middle of the path, where the disambiguation may depend on what comes after the variable value but possibly also on the variable value itself. E.g. example.com/{var}/my-path. In this example, the user wants to convey that the /my-path suffix matters, but should we support specific rules for matching the {var} bit as well? (Is it like a *? Does it include multiple path segments or just one? Etc.)

If one can index an AuthConfig to be looked up from the path of the request, should we allow only a path with no host at all? E.g. hosts: ["/my-path*"]. Would the disambiguation between host name and path be based on starting with a slash? Or should we require it to be explicit – e.g. hosts: ["path=/my-path*", "host=example.com"]?

And why stop at paths? Should we also support query string params? Headers?

Hopefully, it's becoming clear that either it would be a very limited feature (e.g. exact path match only, always requiring a host name preceding it) or what we want to replace hosts really is a list of more complex request matchers, with a proper language to express them (e.g. HTTPRouteMatch or CEL).

Currently, the AuthConfig lookup is very efficient. This is because the index is modeled as a trie, whose only complexity added comes from the host wildcards and sub-domains. Paths (and possibly other kinds of matchers) add new dimensions to this data struct, which may no longer be able to navigate as efficiently.

Likely, the whole lookup model would have to change to iterating through a list of matchers, evaluating one by one. I don't know what that would mean for the falling back to an upper AuthConfig when we miss a specific host domain today but still have one indexed to a super domain (see the "Host lookup with wildcards" example.)

Sorry for the text wall. But, at the same time, thank you for the opportunity to document this. It's not the first time path-based lookup comes around. It's important for contributors to understand the complexity involved with this request, as much as it is for us to understand the concrete use cases... which I hope you can share more about.

[guicassolato]

As for host overriding being hard (impossible) to use via Gateway API, unfortunately that is true. I wish there's something the implementations could about it.

Maybe Envoy Gateway can work on its SecurityPolicy so perhaps a sectionName in a targetRef field, in a policy targeting a HTTPRoute, could open room for setting Envoy ExtAuthzPerRoute configs.

I know Istio AuthorizationPolicy will hardly support context extensions, due to it's approach combining Envoy RBAC filter instead of proper per-route ext-authz.

[guicassolato]

One thing I should mention is that soon Kuadrant will fix this problem by letting its AuthPolicy to target individual sections of a HTTPRouteRule.

Kuadrant uses Authorino underneath. It creates AuthConfigs out of AuthPolicies. Because it's moving away from configuring the underlying Gateway API implementation using auth-specific policies (SecurityPolicy in the case of Envoy Gateway and AuthorizationPolicy in the case of Istio), to favour wasm integration instead, it will reclaim control over the CheckRequest message. Effectively, the AuthConfigs Kuadrant creates will be split based on the targets of the AuthPolicy, including defining AuthConfigs that only trigger for specific Gateway API HTTPRouteRules, such as ones that define specific path-based HTTPRouteMatches.

in summary, one who is willing to use Authorino via Kuadrant will be able to achieve path-based AuthConfigs soon.

[eshepelyuk]

First of all, I am appreciated for such detailed answers. Unfortunately any proposed options are not suitable for my project case. But because it's in a "startup stage" we've decided to change our API exposure approach from path based to host based, to be able to leverage Authorino. And we are already using it for protecting some of the endpoints.

But let me be frank with you, the lack of path based routing support will be a red flag for any big established project that uses path based routing, when assesing Authorino. My experience maybe limited but I haven't met the host based API exposure approach in any real life project I've been working on.

So if you're open for advices, I do suggest you folks to implement incomplete, very basic but first class path based routing in Authorino itself. Even if it would cover 50% of users needs - it will be a huge benefit for Authorino, since peoples of CTO\principal architects\tech lead positions woud be much more eager to consider and adopt Authorino in their existing project with parh based routing.

Thanks for your work and community support.

[guicassolato]

I think this is fair feedback which we deeply appreciate, @eshepelyuk. We are definitely open for advice, even more so when it's backed by real use cases such as yours.

To be clear, I am not against this proposal at all. I just felt the need to slice it well so the complexity involved (or at least the one I anticipate) is transparent to anybody interested in working on this feature, rather than the typical kind that reveals itself only when you're already halfway into it.

I'm happy to reopen #486 now maybe aiming for something simple initially, that does not involve redesigning the index of AuthConfigs entirely if possible. I imagine that could be perhaps the addition of "path nodes" to the trie. First, lookup happens based on host, then if the host-node found has a path-node attached to it, try to match that. No regexes or globs at first; just exact matches. Do you think that could be a good start?

[eshepelyuk]

Ok, so path based AuthConfig should address two main issues

• applying security on particular URL path itself
• ability to decouple monolithic AuthConfig into several path related instances

Assuming that API could look smth like

kind: AuthConfig
metadata:
   name: monolithic
spec: 
  hosts:
    - host: api.127-0-0-1.nip.io
      paths:
        - /users
        - /users/orders

1. The configuration above should match application of security:

• /users ✅
• /users/orders ✅
• /users/orders ✅
• /users/orders/vip ❌
• /users/orders/123 ❌
• /other/api ❌

2. It should be possible to separate configuration from above into two instances:

kind: AuthConfig
metadata:
   name: users
spec: 
  hosts:
    - host: api.127-0-0-1.nip.io
      paths:
        - /users

kind: AuthConfig
metadata:
   name: orders
spec: 
  hosts:
    - host: api.127-0-0-1.nip.io
      paths:
        - /users/orders

[eshepelyuk]

This discussion goes out of control a bit, but I'd like to share some info i recently discovered.

Users of Envoy Gateway can leverage Host override via context extension by using EnvoyPatchPolicy CRD that combines JSONPatch and JSONPath standards and allows to modify any arbitrary section of generated Envoy config. It's recently released and not completely covered in docs but it covers all the customization needs.

• https://gateway.envoyproxy.io/docs/tasks/extensibility/envoy-patch-policy/
• JSONPath not correctly translated to JSONPatch paths envoyproxy/gateway#4162