Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Authentifizieren von Benutzern mithilfe eines Application Load Balancers

Sie können einen Application Load Balancer so konfigurieren, dass Benutzer auf sichere Weise authentifiziert werden, wenn sie auf ihre Anwendungen zugreifen. So können Sie den Aufwand für das Authentifizieren der Benutzer auf Ihren Load Balancer verlagern, damit sich Ihre Anwendungen auf die Geschäftslogik konzentrieren können.

Vorbereiten der Nutzung eines OIDC-konformen Identitätsanbieters

Gehen Sie wie folgt vor, wenn Sie für Ihren Application Load Balancer einen OIDC-konformen Identitätsanbieter verwenden:

Vorbereitung für die Verwendung von Amazon Cognito

Gehen Sie wie folgt vor, wenn Sie Amazon-Cognito-Benutzerpools für Ihren Application Load Balancer verwenden:

Die Callback-URL in den App-Client-Einstellungen darf ausschließlich Kleinbuchstaben enthalten.

Damit ein Benutzer einen Load Balancer für die Verwendung von Amazon Cognito zum Authentifizieren von Benutzern konfigurieren kann, müssen Sie dem Benutzer die Berechtigung zum Aufrufen der Aktion cognito-idp:DescribeUserPoolClient gewähren.

Bereiten Sie sich auf die Nutzung von Amazon vor CloudFront

Aktivieren Sie die folgenden Einstellungen, wenn Sie eine CloudFront Distribution vor Ihrem Application Load Balancer verwenden:

Konfigurieren der Benutzerauthentifizierung

Sie konfigurieren die Benutzerauthentifizierung, indem Sie eine Authentifizierungsaktion für eine oder mehrere Listener-Regeln erstellen. Die Aktionstypen authenticate-cognito und authenticate-oidc werden nur mit HTTPS-Listenern unterstützt. Eine Beschreibung der entsprechenden Felder finden Sie unter AuthenticateCognitoActionConfigund AuthenticateOidcActionConfigin der Elastic Load Balancing API-Referenzversion 2015-12-01.

Der Load Balancer sendet ein Session-Cookie an den Client, um den Authentifizierungsstatus beizubehalten. Dieses Cookie enthält immer das Attribut secure, da die Benutzerauthentifizierung einen HTTPS-Listener erfordert. Dieses Cookie enthält das Attribut SameSite=None mit CORS-Anforderungen (Cross-Origin Resource Sharing).

Für einen Load Balancer, der mehrere Anwendungen unterstützt, die eine unabhängige Client-Authentifizierung verlangen, sollte jede Listener-Regel mit einer Authentifizierungsaktion einen eindeutigen Cookie-Namen haben. Dadurch wird sichergestellt, dass Clients immer beim IdP authentifiziert werden, bevor sie an die in der Regel angegebene Zielgruppe weitergeleitet werden.

Application Load Balancer unterstützen keine Cookie-Werte, die URL-codiert sind.

Das Feld SessionTimeout ist standardmäßig auf 7 Tage festgelegt. Wenn Sie kürzere Sitzungen benötigen, können Sie auch eine Sitzungs-Zeitbeschränkung von bis zu lediglich einer Sekunde konfigurieren. Weitere Informationen finden Sie unter Sitzungs-Timeout.

Legen Sie das Feld OnUnauthenticatedRequest je nach Bedarf für Ihre Anwendung fest. Beispielsweise:

Der Load Balancer muss mit dem Identitätsanbieter-Tokenendpunkt (TokenEndpoint) und dem Endpunkt mit den Benutzerinformationen (UserInfoEndpoint) des Identitätsanbieters kommunizieren können. Application Load Balancer unterstützen IPv4 nur bei der Kommunikation mit diesen Endpunkten. Wenn Ihr IdP öffentliche Adressen verwendet, stellen Sie sicher, dass die Sicherheitsgruppen für Ihren Load Balancer und die Netzwerk-ACLs für Ihre VPC den Zugriff auf die Endpunkte zulassen. Wenn Sie einen internen Load Balancer oder den IP-Adresstyp verwendendualstack-without-public-ipv4, kann ein NAT-Gateway dem Load Balancer die Kommunikation mit den Endpunkten ermöglichen. Weitere Informationen finden Sie unter Grundlagen zu NAT-Gateways im Amazon-VPC-Benutzerhandbuch.

Verwenden Sie den folgenden create-rule-Befehl, um die Benutzerauthentifizierung zu konfigurieren.

aws elbv2 create-rule --listener-arn listener-arn --priority 10 \
--conditions Field=path-pattern,Values="/login" --actions file://actions.json

Im Folgenden finden Sie ein Beispiel für die actions.json-Datei, die eine authenticate-oidc-Aktion und eine forward-Aktion angibt. AuthenticationRequestExtraParams ermöglicht es Ihnen, während der Authentifizierung zusätzliche Parameter an einen IdP zu übergeben. In der Dokumentation Ihres Identitätsanbieters ist angegeben, welche Felder unterstützt werden.

[{
    "Type": "authenticate-oidc",
    "AuthenticateOidcConfig": {
        "Issuer": "https://idp-issuer.com",
        "AuthorizationEndpoint": "https://authorization-endpoint.com",
        "TokenEndpoint": "https://token-endpoint.com",
        "UserInfoEndpoint": "https://user-info-endpoint.com",
        "ClientId": "abcdefghijklmnopqrstuvwxyz123456789",
        "ClientSecret": "123456789012345678901234567890",
        "SessionCookieName": "my-cookie",
        "SessionTimeout": 3600,
        "Scope": "email",
        "AuthenticationRequestExtraParams": {
            "display": "page",
            "prompt": "login"
        },
        "OnUnauthenticatedRequest": "deny"
    },
    "Order": 1
},
{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
    "Order": 2
}]

Unten ist ein Beispiel für die Datei actions.json angegeben, in der die Aktion authenticate-cognito und die Aktion forward enthalten sind.

[{
    "Type": "authenticate-cognito",
    "AuthenticateCognitoConfig": {
        "UserPoolArn": "arn:aws:cognito-idp:region-code:account-id:userpool/user-pool-id",
        "UserPoolClientId": "abcdefghijklmnopqrstuvwxyz123456789",
        "UserPoolDomain": "userPoolDomain1",
        "SessionCookieName": "my-cookie",
        "SessionTimeout": 3600,
        "Scope": "email",
        "AuthenticationRequestExtraParams": {
            "display": "page",
            "prompt": "login"
        },
        "OnUnauthenticatedRequest": "deny"
    },
    "Order": 1
},
{
    "Type": "forward",
    "TargetGroupArn": "arn:aws:elasticloadbalancing:region-code:account-id:targetgroup/target-group-name/target-group-id",
    "Order": 2
}]

Weitere Informationen finden Sie unter Listener-Regeln.

Authentifizierungsfluss

Das folgende Netzwerkdiagramm ist eine visuelle Darstellung dazu, wie ein Application Load Balancer OIDC zur Benutzerauthentifizierung verwendet.

Die folgenden nummerierten Punkte heben die im vorangehenden Netzwerkdiagramm gezeigten Elemente hervor und erläutern sie.

Jede neue Anforderung durchläuft die Schritte 1 bis 11, während nachfolgende Anforderungen die Schritte 9 bis 11 durchlaufen. Das heißt, jede nachfolgende Anforderung beginnt bei Schritt 9, solange das Cookie nicht abgelaufen ist.

Das AWSALBAuthNonce-Cookie wird dem Anforderungsheader hinzugefügt, nachdem sich der Benutzer beim IdP authentifiziert hat. Dies ändert nichts daran, wie der Application Load Balancer Anfragen zur Umleitung vom IdP verarbeitet.

Wenn der Identitätsanbieter ein gültiges Aktualisierungstoken im ID-Token bereitstellt, speichert der Load Balancer das Aktualisierungstoken und nutzt es jeweils zum Aktualisieren der Benutzeransprüche, sobald das Zugriffstoken abgelaufen ist. Dieser Vorgang wird fortgesetzt, bis für die Sitzung der Wert für die Zeitüberschreitung erreicht ist oder die Identitätsanbieter-Aktualisierung fehlschlägt. Wenn sich der Benutzer abmeldet, tritt für die Aktualisierung ein Fehler auf und der Load Balancer leitet den Benutzer an den Identitätsanbieter-Autorisierungsendpunkt weiter. Auf diese Weise kann der Load Balancer Sitzungen verwerfen, nachdem sich der Benutzer abgemeldet hat. Weitere Informationen finden Sie unter Sitzungs-Timeout.

Codierung von Benutzeransprüchen und Signaturverifizierung

Nachdem der Load Balancer einen Benutzer erfolgreich authentifiziert hat, sendet er die vom Identitätsanbieter erhaltenen Benutzeransprüche an das Ziel. Der Load Balancer signiert den Benutzeranspruch, damit diese Anwendungen die Signatur prüfen und sicherstellen können, dass die Ansprüche vom Load Balancer gesendet wurden.

Zugriffstoken und Benutzeransprüche unterscheiden sich von den ID-Token. Zugriffstoken und Benutzeransprüche ermöglichen nur den Zugriff auf Serverressourcen, während ID-Token zusätzliche Informationen zur Authentifizierung eines Benutzers enthalten. Der Application Load Balancer erstellt bei der Authentifizierung eines Benutzers ein neues Zugriffstoken und leitet nur die Zugriffstoken und Ansprüche an das Backend weiter, nicht jedoch die ID-Token-Informationen.

Diese Token weisen zwar das JWT-Format auf, sind aber keine ID-Token. Das JWT-Format umfasst einen Header, eine Nutzlast und eine Signatur (jeweils mit base64-URL-Verschlüsselung) und beinhalten Padding-Zeichen am Ende. Ein Application Load Balancer verwendet ES256 (ECDSA verwendet P-256 und SHA256), um die JWT-Signatur zu generieren.

Der JWT-Header ist ein JSON-Objekt mit den folgenden Feldern:

{
   "alg": "algorithm",
   "kid": "12345678-1234-1234-1234-123456789012",
   "signer": "arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id", 
   "iss": "url",
   "client": "client-id",
   "exp": "expiration"
}

Die JWT-Nutzlast ist ein JSON-Objekt mit den Benutzeransprüchen, die vom Identitätsanbieterendpunkt mit den Benutzerinformationen empfangen wurden.

{
   "sub": "1234567890",
   "name": "name",
   "email": "alias@example.com",
   ...
}

Da der Load Balancer die Benutzeransprüche nicht verschlüsselt, empfehlen wir Ihnen, für die Zielgruppe die Nutzung von HTTPS zu konfigurieren. Wenn Sie für Ihre Zielgruppe die Nutzung von HTTP konfigurieren, sollten Sie darauf achten, den Datenverkehr mithilfe von Sicherheitsgruppen auf Ihren Load Balancer zu beschränken.

Um die Sicherheit zu gewährleisten, müssen Sie die Signatur überprüfen, bevor Sie eine Autorisierung auf der Grundlage der Ansprüche vornehmen, und überprüfen, ob das signer Feld im JWT-Header den erwarteten Application Load Balancer Balancer-ARN enthält.

Sie erhalten den öffentlichen Schlüssel, indem Sie die Schlüssel-ID aus dem JWT-Header verwenden, um den öffentlichen Schlüssel aus dem Endpunkt zu suchen. Der Endpunkt für jede AWS -Region lautet wie folgt:

https://public-keys.auth.elb.region.amazonaws.com/key-id

Denn AWS GovCloud (US) die Endpunkte lauten wie folgt:

https://s3-us-gov-west-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-west-1/key-id
https://s3-us-gov-east-1.amazonaws.com/aws-elb-public-keys-prod-us-gov-east-1/key-id

Im folgenden Beispiel wird veranschaulicht, wie Sie die Schlüssel-ID, den öffentlichen Schlüssel und die Nutzlast in Python 3.x abrufen:

import jwt
import requests
import base64
import json

# Step 1: Validate the signer
expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id'

encoded_jwt = headers.dict['x-amzn-oidc-data']
jwt_headers = encoded_jwt.split('.')[0]
decoded_jwt_headers = base64.b64decode(jwt_headers)
decoded_jwt_headers = decoded_jwt_headers.decode("utf-8")
decoded_json = json.loads(decoded_jwt_headers)
received_alb_arn = decoded_json['signer']

assert expected_alb_arn == received_alb_arn, "Invalid Signer"

# Step 2: Get the key id from JWT headers (the kid field)
kid = decoded_json['kid']

# Step 3: Get the public key from regional endpoint
url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid
req = requests.get(url)
pub_key = req.text

# Step 4: Get the payload
payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

Im folgenden Beispiel wird veranschaulicht, wie Sie die Schlüssel-ID, den öffentlichen Schlüssel und die Nutzlast in Python 2.7 abrufen:

import jwt
import requests
import base64
import json

# Step 1: Validate the signer
expected_alb_arn = 'arn:aws:elasticloadbalancing:region-code:account-id:loadbalancer/app/load-balancer-name/load-balancer-id'

encoded_jwt = headers.dict['x-amzn-oidc-data']
jwt_headers = encoded_jwt.split('.')[0]
decoded_jwt_headers = base64.b64decode(jwt_headers)
decoded_json = json.loads(decoded_jwt_headers)
received_alb_arn = decoded_json['signer']

assert expected_alb_arn == received_alb_arn, "Invalid Signer"

# Step 2: Get the key id from JWT headers (the kid field)
kid = decoded_json['kid']

# Step 3: Get the public key from regional endpoint
url = 'https://public-keys.auth.elb.' + region + '.amazonaws.com/' + kid
req = requests.get(url)
pub_key = req.text

# Step 4: Get the payload
payload = jwt.decode(encoded_jwt, pub_key, algorithms=['ES256'])

Zeitüberschreitung

Sitzungs-Timeout

Das Aktualisierungstoken und die Sitzungs-Zeitüberschreitung arbeiten wie folgt zusammen:

Client-Anmelde-Timeout

Ein Client muss den Authentifizierungsprozess innerhalb von 15 Minuten einleiten und abschließen. Wenn ein Client die Authentifizierung nicht innerhalb der 15-minütigen Frist abschließt, erhält er vom Load Balancer einen HTTP-401-Fehler. Dieses Timeout kann nicht geändert oder entfernt werden.

Wenn ein Benutzer beispielsweise die Anmeldeseite über den Application Load Balancer lädt, muss er den Anmeldevorgang innerhalb von 15 Minuten abschließen. Wenn der Benutzer wartet und dann versucht, sich nach Ablauf des 15-Minuten-Timeouts anzumelden, gibt der Load Balancer einen HTTP-401-Fehler zurück. Der Benutzer muss die Seite aktualisieren und erneut versuchen, sich anzumelden.

Authentifizierung und Abmeldung

Wenn eine Anwendung einen authentifizierten Benutzer abmelden muss, sollte die Ablaufzeit des Cookies für die Authentifizierungssitzung auf „-1“ festgelegt und der Client an den Identitätsanbieteredpunkt für die Abmeldung (falls vom Identitätsanbieter unterstützt) weitergeleitet werden. Um zu verhindern, dass Benutzer ein gelöschtes Cookie wiederverwenden, empfehlen wir Ihnen, die Ablaufzeit für das Zugriffstoken so kurz wie möglich zu konfigurieren. Wenn ein Client für einen Load Balancer ein Sitzungs-Cookie bereitstellt, das über ein abgelaufenes Zugriffstoken mit einem Nicht-NULL-Aktualisierungstoken verfügt, fragt der Load Balancer beim Identitätsanbieter nach, ob der Benutzer noch angemeldet ist.

Die Zielseite zur Client-Abmeldung ist eine nicht authentifizierte Seite. Das bedeutet, dass sie nicht hinter einer Application-Load-Balancer-Regel stehen kann, die eine Authentifizierung erfordert.