Support for Envoy's Ext Authz Dynamic Metadata

[guicassolato]

Right now, the only way to retrieve information from the auth pipeline is through the Festival Wristbands and their support for custom claims. This will probably not play well for the Envoy feature for emiting "dynamic metadata" from the external authorization to be consumed by other filters (e.g. rate limit). See External Authorization Dynamic Metadata for more info.

Ideas for the implementation
To introduce a new phase to the auth pipeline, to be defined by the user in the CR. This phase will build a JSON (map[string]string) with entries declared in the CR and dynamically resolved in the auth pipeline, similarly to how it's done for wristband custom claims. See

authorino/pkg/config/wristband.go

Lines 67 to 70 in 7612c49

	type WristbandClaim struct {
	Name string
	Value *ClaimValue
	}

and

authorino/pkg/config/wristband.go

Lines 125 to 132 in 7612c49

	for _, claim := range w.CustomClaims {
	value := claim.Value
	if value.FromJSON != "" {
	claims[claim.Name] = gjson.Get(authJSON, value.FromJSON).String()
	} else {
	claims[claim.Name] = value.Static
	}
	}

Another possible implementation could be by continuing relying on the wristband to be the vessel but setting a different location for it to be passed back (#113), perhaps enhanced with additional support for non-signed and non-encoded wristbands issued. I'm afraid that this might be an overuse of the wristband feature though.

[guicassolato]

A more concrete implementation idea for this:

To define a new (final) phase for the auth pipeline called response, i.e. another array of evaluators (or "response configs"), just like we have for the other phases (identity, metadata and authorization), to be cached within the APIConfig object as ResponseConfigs []common.AuthConfigEvaluator.

After authorization phase is finished (and successful), the AuthPipeline would call the evaluators of the response phase (concurrently between them, as usual), handling the evaluated objects like it does for the other 3 phases, i.e. storing them in a map Response map[*config.ResponseConfig]interface{}.

The wristband issuer would become a type of evaluator of the response phase. Another type of response evaluator would be the DynamicMetadata evaluator:

type ResponseConfig struct {
	Name string `yaml:"name"`

	Wristband        *response.WristbandIssuer     `yaml:"wristband,omitempty"`
	DynamicMetadata  *response.DynamicMetadata `yaml:"dynamicMetadata,omitempty"`
}

with

type DynamicMetadata struct {
	Name  string
	Value struct {
		Static   string
		FromJSON string
	}
}

evaluateAllAuthConfigs strategy would be used at the response phase. Once finished with all evaluators of the phase and returned control to AuthPipeline.Evaluate(), the pipeline would then build the AuthResult object, now:

type AuthResult struct {
	Code            rpc.Code
	Message         string
	Headers         []map[string]string
	DynamicMetadata interface{} // or perhaps `map[string]interface{}`
}

OTB, this implementation would enable having multiple wristbands issued at the end of an auth pipeline instead of just one (if that even makes sense for any use case), as well as multiple “dynamic metadata” objects (probably to be merged into a single one before responding back to Envoy).

Something that would make this even more interesting would be modifying the AuthPipeline so the evaluated objected returned in the authorization phase also end up in the authorization JSON – i.e., an extension of what goes in

authorino/pkg/service/auth_pipeline.go

Line 338 in 7612c49

AuthData: authData,

So the response evaluators (wristband issuer and dynamic metadata) could select values from the authorization phase as well (aside from the already possible ones identity and metadata). This could open up for solving #109.