使用Amazon.Lambda.AspNetCoreServer的自定义授权者数据 [英] Custom authorizer data with Amazon.Lambda.AspNetCoreServer

问题描述

过去与Node.js进行了广泛的合作，我们目前正在研究ASP.NET Core作为替代的Lambda平台.

Having worked extensively with Node.js in the past, we are currently investigating ASP.NET Core as an alternative Lambda platform.

过去，我们基于API网关的服务依赖于自定义授权者，该授权者对用户进行身份验证并从公司的IAM服务中检索基于资源的权限策略列表.授权者将该列表附加到 authContext 键.我们的服务将通过Lambda代理与API Gateway集成，并从原始代理请求中提取主体对象.

In the past, our API Gateway-fronted services relied on a custom authorizer, which authenticated the user and retrieved a list of resource-based permission policies from our company's IAM service. The authorizer attaches that list to the authContext key. Our services would integrate with API Gateway via Lambda Proxy and extract the principal object from the raw proxy request.

使用Amazon.Lambda.AspNetCoreServer在API网关和ASP.NET之间进行转换时，我们无法达到类似的情况.

When using Amazon.Lambda.AspNetCoreServer to translate between API Gateway and ASP.NET, we are unable to arrive at a similar scenario.

Amazon.Lambda.AspNetCoreServer :: ApiGatewayProxyFunction :: FunctionHandlerAsync( Stream responseStream，ILambdaContext lambdaContext )或与此等效的任何等效Lambda处理程序签名在第一个参数中接收完整的原始请求. 可以对流进行序列化(例如，转换为JSON.NET JObject)并在那里提取主体对象.

Amazon.Lambda.AspNetCoreServer::ApiGatewayProxyFunction::FunctionHandlerAsync(Stream responseStream, ILambdaContext lambdaContext), or any equivalent Lambda handler signature for that matter, receives the complete, raw request in the first parameter. It is possible to serialize the stream (for example, into a JSON.NET JObject) and extract the principal object there.

但是，证明困难的是在ASP.NET应用程序中访问该数据.我不相信授权者响应会传递到HTTP上下文.检查时，ClaimsPrincipal上下文.用户密钥不包含任何数据.

However, what proves difficult is accessing that data within the ASP.NET application. I am not convinced that the authorizer response is passed to the HTTP context. When checking it, the ClaimsPrincipal context.User key contains no data.

提出了几种解决方案:

• 在覆盖的FunctionHandlerAsync中检索IAM信息，并使用环境变量或会话将它们全局存储
• 创建IAM提供程序服务的接口和补充实现.它将公开一种检索IAM信息的方法.该实现将仅返回声明的反序列化列表.该服务将使用重写的Init(IWebHostBuilder)方法进行配置.
• 将(Claims/General)Principal对象粘合在一起，然后尝试将其传递给HTTP上下文

有没有办法做到这一点?

Is there a way to achieve this cleanly?

推荐答案

我们处于完全相同的情况，我绝对不能提供一个很好的解决方案，但是我有一种解决方法.

We've in the exact same situation and I can by no means offer a nice and clean solution, but I have a workaround.

如果您查看请求有效负载，则json的格式如下:

If you look at the request payload, the json is formatted like this:

{
    [...]
    "requestContext": {
        [...]
        "authorizer": {
            "claims": {
                "claim1": "value1",
                "claim2": "value2",
                "claim3": "value3",
            }
        },
        [...]

在APIGatewayProxyFunction.FunctionHandlerAsync中，它们将requestStream反序列化为APIGatewayProxyRequest.如果进入该类，您会发现json的Authorizer部分反序列化为:

In APIGatewayProxyFunction.FunctionHandlerAsync they deserialize the requestStream into an APIGatewayProxyRequest. If you step into that class you'll find that the Authorizer part of the json gets deserialized into:

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

即，所有要求都在反序列化中丢失.我已经在这里发布了此问题: https://github.com/aws/aws-lambda-dotnet/issues/98

I.e all claims are lost in deserialization. I've posted this issue here: https://github.com/aws/aws-lambda-dotnet/issues/98

现在要解决此问题，我已经将一些可以工作"的东西组合在一起

Now to the workaround, I've just put something that "works" together here (Code here):

请注意，这是未经测试的. :-)

Note that it's very untested. :-)

用法:

public class LambdaEntryPoint : APIGatewayAuthorizerProxyFunction
{
    protected override void Init(IWebHostBuilder builder)
    {
        builder
            .UseContentRoot(Directory.GetCurrentDirectory())
            .UseStartup<Startup>()
            .UseApiGateway();
    }
}

这篇关于使用Amazon.Lambda.AspNetCoreServer的自定义授权者数据的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！