feat: add authorizer enhanced context

[frsechet]

Serverless has this (not very-well documented) feature that passes lambda authorizer context data into the subsequent lambda execution event as enhancedAuthContext.

See serverless/serverless#4374 for more info about this feature.

This is the type of event available in live environments, that serverless-offline currently does not support:

{
  "event": {
    "body": {},
    "method": "GET",
    "principalId": "150efb8b-5e2d-4cdd-88a5-5e1c74d06861",
    "stage": "dev",
    "cognitoPoolClaims": {
      "sub": ""
    },
    "enhancedAuthContext": {
      "principalId": "150efb8b-5e2d-4cdd-88a5-5e1c74d06861",
      "integrationLatency": "583",
      "somekey": "xxxxx"
    },
    "headers": { ... },
    "query": {},
    "path": {},
    "identity": { ... },
    "stageVariables": {},
    "requestPath": "/"
  }
}

This PR adds the enhancedAuthContext property to all calls (as with serverless by default), and populates it with the context built in custom authorizers.

[frsechet]

edit: rebase against 5.x and merge into 5.x

[dnalborczyk]

thank you @frsechet !

does this apply only to lambda-integration and not to lambda-proxy-integration?

[dnalborczyk]

@frsechet could you also add (a/some) test(s) similar to: https://github.com/dherault/serverless-offline/tree/master/__tests__/integration/uncategorized

you can PR the test(s) against master, I'll backport your PR then. That would much appreciated!

[frsechet]

does this apply only to lambda-integration and not to lambda-proxy-integration?

Yes. Lambda-proxy already receives this as part of the requestContext.authorizer property.

I also took some time to add some missing properties in the event, such as the requestPath, stage, and cognitoPoolClaims properties.

There are minor differences there between sls and sls-offline (mostly as how the claims property is handled). There is no easy way to ignore that property in either integrations, and this PR does not introduce a new error, but the claims property should really be removed from the event, although $context.authorizer.claims.property is available in the velocity template. https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#context-variable-reference says $context.authorizer.claims should return null (but is absent from the event on Lambda).

I will add some tests, however I'm not confortable adding this to master as I can not get to run master on my computer, and will have no time to debug this in the coming weeks. Not even the tests are running locally :( Is that OK if I still do this PR against 5.x?

[dnalborczyk]

@frsechet

I will add some tests,

that would be really great! otherwise stuff might be breaking down the road.

however I'm not confortable adding this to master as I can not get to run master on my computer, and will have no time to debug this in the coming weeks. Not even the tests are running locally :(

that's fine. the tests should ideally be failing anyways on master, without the backport.

out of curiosity, what's the problem you are facing with master? it shouldn't really be any different than 5.x (other than some breaking changes, mainly flags removal). don't forget to run npm ci, as some deps have been added and changed.

Is that OK if I still do this PR against 5.x?

yeah, sure, no problem.

[frsechet]

Hi @dnalborczyk,

I can't find any tests at all that test authorizer behavior that I can expand on. Not sure at all where to begin then, as I do not have time currently to add a complete new class of tests just to add tests on a subproperty.

Any pointer how I would go to just test that enhancedContext is correctly added to authorized calls in a lambda integration?

[angel-carvajal]

Any news on this? It would be great to have this running asap!

[dnalborczyk]

hey @frsechet sorry, took me a while to get to this. I'm pulling this in for now.

There are minor differences there between sls and sls-offline (mostly as how the claims property is handled). There is no easy way to ignore that property in either integrations, and this PR does not introduce a new error, but the claims property should really be removed from the event, although $context.authorizer.claims.property is available in the velocity template.

It looks like the lambda integration code got quite convoluted over time and needs some serious refactoring and de-spaghettification.

[dnalborczyk]

@frsechet @angel-carvajal planning on a 5.x release soon (probably later today). stay tuned.

[angel-carvajal]

@dnalborczyk thanks for the update! I'll keep an eye on it