Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Autenticazione degli utenti tramite Application Load Balancer

È possibile configurare un Application Load Balancer per autenticare in modo sicuro gli utenti nel momento in cui accedono alle proprie applicazioni. Ciò consente di deviare il lavoro di autenticazione degli utenti per il sistema di bilanciamento del carico, in modo che le applicazioni possano concentrarsi sulla loro logica di business.

Preparazione all'uso di un provider di identità compatibile con OIDC

Eseguire le seguenti operazioni se si utilizza un provider di identità compatibile con OIDC con Application Load Balancer:

Preparazione all'uso di Amazon Cognito

Eseguire le seguenti operazioni se si utilizzano pool di utenti di Amazon Cognito con Application Load Balancer:

L'URL di richiamo nelle impostazioni dell'app client dev'essere in lettere minuscole.

Per consentire a un utente di configurare un sistema di bilanciamento del carico per autenticare gli utenti tramite Amazon Cognito, è necessario concedere all'utente l'autorizzazione di chiamare l'operazione cognito-idp:DescribeUserPoolClient.

Preparati a usare Amazon CloudFront

Abilita le seguenti impostazioni se utilizzi una CloudFront distribuzione davanti all'Application Load Balancer:

Configurazione dell'autenticazione utente

È possibile creare un'operazione di autenticazione per una o più regole di listener per configurare l'autenticazione utente. I tipi di operazione authenticate-cognito e authenticate-oidc sono supportati solo con i listener HTTPS. Per le descrizioni dei campi corrispondenti, consulta AuthenticateCognitoActionConfige AuthenticateOidcActionConfignella versione di riferimento dell'API Elastic Load Balancing 2015-12-01.

Il servizio di bilanciamento del carico invia un cookie di sessione al client per mantenere lo stato di autenticazione. Questo cookie contiene sempre l'attributo secure, perché l'autenticazione utente richiede un listener HTTPS. Questo cookie contiene l'attributo SameSite=None con le richieste CORS (cross-origin resource sharing).

Per un sistema di bilanciamento del carico che supporta più applicazioni che richiedono l'autenticazione client indipendente, ogni ascoltatore con un'operazione di autenticazione deve avere un nome di cookie univoco. Ciò garantisce che i client siano sempre autenticati tramite il provider di identità prima di essere instradato verso il gruppo di destinazioni specificato nella regola.

Gli Application Load Balancer non supportano i valori dei cookie codificati con URL.

Per impostazione predefinita, il campo SessionTimeout è impostato su 7 giorni. Se si desiderano sessioni più brevi, è possibile configurare un timeout della sessione di 1 secondo. Per ulteriori informazioni, consulta Timeout della sessione.

Impostare il campo OnUnauthenticatedRequest più appropriato per l'applicazione. Per esempio:

Il sistema di bilanciamento del carico deve essere in grado di comunicare con l'endpoint del token del provider di identità (TokenEndpoint) e con l'endpoint delle info sull'utente del provider di identità (UserInfoEndpoint). Gli Application Load Balancer supportano solo IPv4 quando comunicano con questi endpoint. Se il tuo IdP utilizza indirizzi pubblici, assicurati che i gruppi di sicurezza per il tuo sistema di bilanciamento del carico e gli ACL di rete per il tuo VPC consentano l'accesso agli endpoint. Quando si utilizza un sistema di bilanciamento del carico interno o il tipo di indirizzo IPdualstack-without-public-ipv4, un gateway NAT può consentire al sistema di bilanciamento del carico di comunicare con gli endpoint. Per ulteriori informazioni, consulta Nozioni di base sul gateway NAT nella Guida per l'utente di Amazon VPC.

Utilizzare il seguente comando create-rule per configurare l'autenticazione utente.

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

Di seguito è riportato un esempio del file actions.json che specifica un'operazione authenticate-oidc e un'operazione forward. AuthenticationRequestExtraParams consente di passare parametri extra a un provider di identità durante l'autenticazione. Seguire la documentazione fornita dal provider di identità per determinare quali campi sono supportati.

[{
    "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
}]

Di seguito è riportato un esempio di un file actions.json che specifica un'operazione authenticate-cognito e un'operazione forward.

[{
    "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
}]

Per ulteriori informazioni, consulta Regole dei listener.

Flusso di autenticazione

Il seguente diagramma di rete è una rappresentazione visiva di come un Application Load Balancer utilizza OIDC per autenticare gli utenti.

Gli articoli numerati di seguito evidenziano e spiegano gli elementi mostrati nel diagramma di rete precedente.

Ogni nuova richiesta segue i passaggi da 1 a 11, mentre le richieste successive seguono i passaggi da 9 a 11. Ciò significa che ogni richiesta successiva inizia al passaggio 9 purché il cookie non sia scaduto.

Il cookie AWSALBAuthNonce viene aggiunto all'intestazione della richiesta dopo l'autenticazione dell'utente da parte del provider di identità. Questo non modifica il modo in cui l'Application Load Balancer elabora le richieste di reindirizzamento del provider di identità.

Se il provider di identità fornisce un token di aggiornamento valido nel token ID, il sistema di bilanciamento del carico salva il token di aggiornamento e lo utilizza per aggiornare le richieste dell'utente ogni volta che il token di accesso scade, fino a quando la sessione scade o l'aggiornamento del provider di identità ha esito negativo. Se l'utente si disconnette, l'aggiornamento ha esito negativo e il sistema di bilanciamento del carico reindirizza l'utente all'endpoint di autorizzazione del provider di identità. In questo modo il sistema di bilanciamento del carico archivia le sessioni dopo la disconnessione dell'utente. Per ulteriori informazioni, consulta Timeout della sessione.

Codifica delle richieste dell'utente e verifica della firma

Dopo che il sistema di bilanciamento del carico è riuscito ad autenticare un utente, invia alla destinazione le richieste dell'utente ricevute dal provider di identità. Il sistema di bilanciamento del carico firma le richieste dell'utente in modo che le applicazioni possano verificare la firma e verificare che le richieste siano state inviate dal sistema di bilanciamento del carico.

I token di accesso e le richieste dell'utente sono diverse dai token ID. I token di accesso e le richieste dell'utente consentono l'accesso solo alle risorse del server, mentre i token ID contengono informazioni aggiuntive per autenticare un utente. L'Application Load Balancer crea un nuovo token di accesso durante l'autenticazione di un utente e passa solo i token di accesso e le attestazioni al backend, tuttavia non trasmette le informazioni sul token ID.

Tali token seguono il formato JWT, ma non sono token ID. Il formato JWT include un'intestazione, un payload e una firma con codifica URL base64, oltre ai caratteri padding alla fine.. Un An Application Load Balancer utilizza ES256 (ECDSA con P-256 e SHA256) per generare la firma JWT.

L'intestazione JWT è un oggetto JSON con i seguenti campi:

{
   "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"
}

Il carico utile JWT è un oggetto JSON che contiene le richieste dell'utente ricevute dall'endpoint delle informazioni sull'utente del provider di identità.

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

Poiché il sistema di bilanciamento del carico non consente di crittografare le richieste dell'utente, è consigliabile configurare il gruppo target per l'utilizzo di HTTPS. Se si configura il gruppo target per l'utilizzo di HTTP, assicurarsi di limitare il traffico verso il sistema di bilanciamento del carico utilizzando i gruppi di sicurezza.

Per garantire la sicurezza, è necessario verificare la firma prima di eseguire qualsiasi autorizzazione in base alle affermazioni e verificare che il signer campo nell'intestazione JWT contenga l'ARN Application Load Balancer previsto.

Per ottenere la chiave pubblica, ottenere la chiave ID dall'intestazione JWT e utilizzarla per cercare la chiave pubblica dall'endpoint. L'endpoint per ogni regione AWS è il seguente:

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

Infatti AWS GovCloud (US), gli endpoint sono i seguenti:

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

L'esempio seguente mostra come ottenere la chiave ID, la chiave pubblica e il payload in Python 3.x:

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'])

L'esempio seguente mostra come ottenere la chiave ID, la chiave pubblica e il payload in Python 2.7:

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'])

Timeout

Timeout della sessione

Il token di aggiornamento e il timeout della sessione funzionano congiuntamente come segue:

Timeout di accesso client

Un client deve avviare e completare il processo di autenticazione entro 15 minuti. Se un client non riesce a completare l'autenticazione entro il limite di 15 minuti, riceve un errore HTTP 401 dal sistema di bilanciamento del carico. Non è possibile modificare o rimuovere questo timeout.

Ad esempio, se un utente carica la pagina di accesso tramite l'Application Load Balancer, deve completare il processo di accesso entro 15 minuti. Se l'utente aspetta e prova a effettuare l'accesso dopo la scadenza del timeout di 15 minuti, il sistema di bilanciamento del carico restituisce un errore HTTP 401. L'utente dovrà aggiornare la pagina e riprovare a effettuare l'accesso.

Autenticazione di disconnessione

Quando un'applicazione deve disconnettere un utente autenticato, è necessario impostare la data di scadenza del cookie di sessione per l'autenticazione su -1 e reindirizzare il client all'endpoint di disconnessione del provider di identità (se il provider di identità lo supporta). Per impedire agli utenti di riutilizzare un cookie eliminato, è consigliabile configurare un periodo di scadenza ragionevolmente breve per il token di accesso. Se un client fornisce un sistema di bilanciamento del carico con un cookie di sessione che dispone di un token di accesso scaduto con un token di aggiornamento non NULL, il sistema di bilanciamento del carico contatta il provider di identità per determinare se l'utente è ancora connesso.

La pagina di destinazione della disconnessione del client è una pagina non autenticata. Ciò significa che non può trovarsi dietro una regola dell'Application Load Balancer che richiede un'autenticazione.