Feature request - configurable Principal field about aws-serverless-java-container HOT 6 CLOSED

I've implemented these changes. You can now cast the Principal field to CognitoUserPoolPrincipal and call the getClaims() method to extract all of the claims in the token. I have also added support for custom claims in the object. You can get custom claims using the getClaim(String key) method of the CognitoAuthorizerClaims object.

Resolving the issue.

from aws-serverless-java-container.

This is possible today by creating a custom SecurityContextWriter and passing it to the library.

We could solve this easily by giving you an easy way to inject the security context writer without having to manually create the full object constructor, perhaps just add it as a parameter to the static getAwsProxyHandler?

from aws-serverless-java-container.

We discussed this offline. We see two option:

1. Create a new HandlerMethodArgumentResolver for Spring and a ContextResolver in Jersey. All you'd have to do then is:

@RequestMapping(path = "/pets", method = RequestMethod.POST)
public Pet createPet(@RequestBody Pet newPet, ApiGatewayAuthorizerContext context) {
...
}

2. Extend the Principal interface with a few methods to access the additional properties of the authorization context from API Gateway:

public Pet createPet(@RequestBody Pet newPet, Principal principal) {
((CognitoUserPoolPrincipal)principal).getClaims();
}

Would love to hear from the community what the preferred option is.

from aws-serverless-java-container.

Since there is no feedback and this is not a high priority fix I'm pulling it out of 0.7. The data is still accessible through the request attributes.

from aws-serverless-java-container.

I'm not a user of Spring or Jersey, so I see a lot of benefit in option 2

from aws-serverless-java-container.

I think option 2, as much as I hate casting or doing instanceof, is the most consistent with Spring Security. this also seems to be backward compatible.

from aws-serverless-java-container.