Claims from authorizer lost in deserialisation and not mapped to HttpContext.User

[ljacobsson]

In APIGatewayProxyFunction.FunctionHandlerAsync where the requestStream gets deserialised into APIGatewayProxyRequest we lose all custom claims that were present in the requestStream's json.

It'd be nice if apiGatewayRequest.RequestContext.Authorizer would contain a Dictionary<string,string> with claims which get added to HttpContext.User.

Thanks,
Lars

[ShaneGMamet]

Any updates on this, I have just experienced the same limitation. Having the apiGatewayRequest.RequestContext.Authorizer as a dictionary would be a great solution.

[ljacobsson]

@ShaneGMamet,

As a workaround until there's an official solution, I've written this https://www.nuget.org/packages/MhLabs.Lambda.ApiGatewayAuthorizer/1.0.1

https://github.com/mhlabs/MhLabs.Lambda.ApiGatewayAuthorizer

[MattEttler]

Also running into this. Would love a fix!

[PaulKGray]

I am also hitting this issue, Any idea on when a fix might become available?

[normj]

If somebody could send me a sample request that would speed up my time to getting this implemented. To send a sample request add the environment variable LAMBDA_NET_SERIALIZER_DEBUG with a value of true. Then after executing the request where the claims are stripped go to your CloudWatch logs and grab the JSON request string.

[PaulKGray]

Hi I added this but it didnt give me much info,

you can get the raw request by taking the input as a Stream

public APIGatewayProxyResponse ProxyFunctionHandler(System.IO.Stream input, ILambdaContext context) {
            StreamReader reader = new StreamReader(input);
            string request = reader.ReadToEnd();
            Console.WriteLine(request);
            return new APIGatewayProxyResponse { StatusCode = 200 };
}

The full request is quite big but the data that is missing looks like this.

{
    "requestContext": {
        "authorizer": {
            "claims": {
                "sub": "XXXX",
                "aud": "XXXX",
                "token_use": "id",
                "auth_time": "1503560181",
                "iss": "https://cognito-idp.eu-west-1.amazonaws.com/eu-west-1_XXXXXX",
                "cognito:username": "TestUser",
                "exp": "Thu Aug 24 08:36:21 UTC 2017",
                "iat": "Thu Aug 24 07:36:21 UTC 2017"
            }
        }
    }
}

It is possible to deserialize the object to the classes below using JsonConvert as a work around

var claimsFix = JsonConvert.DeserializeObject<ClaimsFix>(request);

   class ClaimsFix
    {
        public RequestContext RequestContext;
    }

    public class RequestContext
    {
        public Authorizer Authorizer;
    }

    public class Authorizer
    {
        public Dictionary<string, string> Claims { get; set; }
    }

[normj]

As part of the .NET Core 2.0 Lambda release today I updated Amazon.Lambda.APIGatewayEvents and Amazon.Lambda.AspNetCoreServer to pass along the claims and create the HttpContext.User similar to how @ljacobsson was doing in his code.

I'm going to close this as I believe that solves the problem. Feel free to reopen or open a new issue if there are more use cases that are not met.

[swlasse]

@normj Thanks for this.

I think it is a great addition that we can now use APIGatewayCustomAuthorizerContext as a dictionary, however, I'm not sure how I should go about this when returning an APIGatewayCustomAuthorizerResponse in my custom authorizer?

In particular, when doing a custom authorizer, we can return an APIGatewayCustomAuthorizerResponse with the Context property being of type: APIGatewayCustomAuthorizerContextOutput.

However, looking at APIGatewayCustomAuthorizerContextOutput, it is still using:

public string StringKey { get; set; }
public int? NumKey { get; set; }
public bool? BoolKey { get; set; }

... which are now marked obsolete in APIGatewayCustomAuthorizerContext.

I guess the APIGatewayCustomAuthorizerContextOutput should derive from Dictionary<string, object> as well, in order to make it compatible with the new APIGatewayCustomAuthorizerContext? ( and likewise, mark the StringKey, Numkey, and BoolKey attributes as obsolete? )

[normj]

@swlasse I believe your issue is covered by this github issue #159 which I still need to look into.

[swlasse]

@normj, yeah, that looks right. At the moment we serialize our custom context into the StringKey parameter of the APIGatewayCustomAuthorizerContextOutput. It works, but its not ideal.

It could be nice though if we could send through Claims and see them getting picked up by the new Claims property on APIGatewayCustomAuthorizerContext.