Benutzerdefinierte Autorisierungsdaten mit Amazon.Lambda.AspNetCoreServer

Question

Nachdem wir in der Vergangenheit intensiv mit Node.js gearbeitet haben, untersuchen wir derzeit ASP.NET Core als alternative Lambda-Plattform.

In der Vergangenheit verwendeten unsere API-Gateway-Frontend-Services einen benutzerdefinierten Autorizer, der den Benutzer authentifizierte und eine Liste mit ressourcenbasierten Berechtigungsrichtlinien aus dem IAM-Service unseres Unternehmens abruft. Der Autorisiert diese Liste an den Schlüssel authContext. Unsere Dienste würden über Lambda Proxy in das API Gateway integriert und das Hauptobjekt aus der Raw-Proxy-Anfrage extrahiert.

Wenn Sie Amazon.Lambda.AspNetCoreServer für die Übersetzung zwischen API Gateway und ASP.NET verwenden, können wir nicht zu einem ähnlichen Szenario gelangen.

Amazon.Lambda.AspNetCoreServer ApiGatewayProxyFunction :: :: FunctionHandlerAsync (Stream-Response, ILambdaContext lambdaContext) oder ein äquivalenter Lambda-Handler Signatur was das betrifft, erhält die vollständige, Rohanforderung in dem ersten Parameter. Es ist möglich den Stream zu serialisieren (zum Beispiel in ein JSON.NET JObject) und das Hauptobjekt dort zu extrahieren.

Was jedoch schwierig ist, ist Zugriff auf diese Daten innerhalb der ASP.NET-Anwendung. Ich bin nicht davon überzeugt, dass die Autorisierungsantwort an den HTTP-Kontext übergeben wird. Der ClaimsPrincipal context.User-Schlüssel enthält keine Daten.

Mehrere Lösungen wurden herumgeworfen:

• IAM Informationen in der überschriebenen FunctionHandlerAsync abzurufen und sie global mit Umgebungsvariablen oder Sitzungen
• die Schaffung einer Schnittstelle und eine komplementäre Implementierung eines IAM-Provider-Dienst zu speichern. Es würde eine Methode zum Abrufen von IAM-Informationen verfügbar machen. Die Implementierung würde einfach eine deserialisierte Liste von Ansprüchen zurückgeben. Der Dienst wird in einer überschriebenen Init-Methode (IWebHostBuilder) konfiguriert.
• miteinander verklebt werden (Ansprüche/General) Hauptobjekt und versucht, es an den HTTP-Kontext passieren

Gibt es eine Möglichkeit, diese sauber zu erreichen?

Answer 1

Wir haben in genau der gleichen Situation und ich kann auf keinen Fall eine schöne und saubere Lösung anbieten, aber ich habe einen Workaround.

Wenn Sie auf Wunsch Nutzlast aussehen, wird die json wie folgt formatiert:

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

In APIGatewayProxyFunction.FunctionHandlerAsync sie deserialisiert die requestStream in eine APIGatewayProxyRequest. Wenn Sie in dieser Klasse Schritt werden Sie feststellen, dass der Authorizer Teil des json in deserialisiert wird:

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

D.h. alle Forderungen in Deserialisierung verloren. Ich dieses Problem hier gepostet habe: https://github.com/aws/aws-lambda-dotnet/issues/98

Nun zum Problem zu umgehen, habe ich nur etwas setzen, das „Werk“ zusammen here (Kodex here):

Beachten Sie, dass es sehr ungetestet ist.:-)

Verbrauch:

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