Add support for Request Lambda Event Payload Authorizers

[ivandjuricic]

@app.authorizer once deployed creates a new authorizer that is using Token in the Lambda event handler options.

Adding a new authorizer (or extending the existing ChaliceAuthorizer) that would be able to create the one with Request option would be greatly beneficial:

1. this type of authorizer provide much more flexibility in terms of authorizing request
2. from what I see the WebSockets authorizers utilizes this kind of authorizer, so it could be the first step of resolving https://github.com/aws/chalice/issues/1457

With some guidance I could possibly start working on this

[jamesls]

Sounds great. The first thing we should do before getting started on a PR is make sure we have the API we like. I'd need to look into this in more detail, but my initial hunch is that this should probably be a new type of authorizer, but ideally we can share that new authorizer between the REST API and the (soon to be added) websocket authorizers. Any thoughts/sample code on how you'd like this to look?

Anyone else that's curious, here's some relevant links:

• https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html
• https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-lambda-authorizer-input.html

[ivandjuricic]

Hi @jamesls glad you liked the idea!!

Something I had in mind is creating a new decorator method and a new authorizer class (yet very similar to ChaliceAuthorizer one). From user perspective it would look something like:

@app.request_authorizer(identity_sources=RequestAuthorizerIdentitySources(query_strings=['test']))
def request_athorizer(auth_request):
    if auth_request.queryStringParameters.get('test') == ['123']:
        return AuthResponse(path=['/protected'], principal_id='user')
    return AuthResponse(path=[], principal_id='user')

@app.route('/protected', authorizer= request_athorizer)
def protected_view():
    return {"status": "OK"}

I quckly sketch up some initial work to get authorizers like this local working correctly, basically just tinkered around to check out how things are put together and commited here https://github.com/aws/chalice/compare/master...ivandjuricic:authorizerv1

If you think that's a good way to go, I can start expanding the idea further

[ivandjuricic]

Hi, @jamesls, I wanted to showcase the progress on implementation of the Request authorizers and created a Draft pull request for that, didn't know it would show up basically as a regular PR. Hope that's ok!

[jamesls]

Yeah no problem, thanks for starting this.

I was trying to think through if it makes sense to have a separate decorator or just add new kwargs to the existing @app.authorizer decorator. On the one hand, they're conceptually pretty similar in the sense that the main differences are you have access to more attributes of the HTTP request in the incoming event and you can configure what your identity cache key is. Everything else (from the app writer's perspective) is similar. On the other hand, it seems cleaner to keep to the "one decorator == one input event type" by having separate decorators. As a side-effect it's also easier to implement because this is what the chalice internals assume. I think I'm leaning towards how you have them, as separate decorators.

Smaller nitpick but the RequestAuthorizerIdentitySources name seems verbose. We might be able to just make that a dictionary, and we can still get the typechecking/autocompletion via a TypedDict.

[ediskandarov-cur]

I'm missing this functionality too. Authentication based on a cookie is not available in the current implementation.

[xingyi111]

Currently chalice only support token Lambda Event Payload Authorizers,more information about the request,such as query param and body could not be retrieved.This is not friendly for operations such as verifying signatures. Add support for Request Lambda Event Payload Authorizers is needful.