Validate capability and provide proof of concept around request validation

[jentfoo]

Problem or feature statement

Customers may want to do some validation of requests before they are forwarded to their downstream. Some possible usage example to consider:

1. Want to validate the request has valid user authentication
2. Want to validate a basic CSRF token
3. Want to validate a client / source but IP Whitelisting is not possible

The common thread for this solution should be that the above is being solved by a signed token which larky then validates the signature.

Advised solution

Assume a client / browser has a signed token. This may be a JWT representing the client auth (ie 1 above), or a signed CSRF token (ie 2), or a token generated by a client having access to the private key (ie a WAF or 3).

When larky gets the request, it should be able to use a configured / stored public key to validate a token contained within a request header is valid.

Typically within the signed value is a timestamp so that these tokens can only be reused for a short period of time. Unfortunately because larky will not have precise clock access, this will not be completely effective.

If validation fails it is expected that:

1. Any aliased values will be immediately deleted (or prevent the creation of if possible)
2. There wont be billing impacts from the request
3. The request will be rejected without a call to the customer backend

Testing scenarios

We should clearly document what signing algorithms we support, as JWT's and others can come in a variety of algorithms.

[aslepakurov]

This should be a next step as we extend JWT support inside Larky