"Higher level" policies investigation aka meta-policies

[alexsnaps]

The idea is to try to build upon what we already have to build higher level abstractions that provide users with easier tools to get started with. This is inspired by a use-case that was thought to not yet be feasible to fulfill with our current tools. As it turns out it is, but leaves many blanks for the user to fill and in order to do so, leaves it upon them to understand how our stack is built.

The proposal is to investigate whether we can lower the bar to entry for users to achieve their goals without requiring them to dig through all of manuals.

The use-case

John Doe is a Platform Engineer for example.org who has been asked to apply rate limits for any organization or user using their API’s. However, one of the requirements of the request is to change the rate limit thresholds based on the time of the day (higher thresholds during non-peak hours & lower thresholds during peak hours). A second requirement for John is that the fluctuating custom thresholds must be set to the API Plan that the user/organization has (3 Plan Packages - Gold, Silver & Bronze).

Breaking into down

There are two main parts to the problem here:

• identifying users
• mapping them to plans and as such rate limits

IdentityPolicy

Let's spec a policy down to its bare minimal to identify users and protect HttpRoutes with it, eventually translating to an AuthPolicy

Plans

Use some data from that identity (using CEL) to map these users to Limits as we know them from RateLimitPolicy.

Tying things together

The mapping of an identity to a plan probably belongs to the concept of Plan, in the sense that an Identity exists regardless of a Plan, while a Plan exists according to the Identity, even if that'd mean "absence of an identity` (i.e. an anonymous request).