Autenticazione e autorizzazione YARP

Articolo
2025-02-15

Introduzione

Il proxy inverso può essere usato per autenticare e autorizzare le richieste prima che vengano inoltrate tramite proxy ai server di destinazione. Ciò può ridurre il carico nei server di destinazione, aggiungere un livello di protezione e garantire l'implementazione di criteri coerenti nelle applicazioni.

Impostazioni predefinite

Non viene eseguita alcuna autenticazione o autorizzazione nelle richieste, a meno che non sia abilitata nella configurazione della route o dell'applicazione.

Configurazione

I criteri di autorizzazione possono essere specificati per ogni route tramite RouteConfig.AuthorizationPolicy e possono essere associati dalle sezioni Routes del file di configurazione. Come per altre proprietà di route, è possibile modificare e ricaricare senza riavviare il proxy. I nomi dei criteri non fanno distinzione tra maiuscole e minuscole.

Esempio:

{
  "ReverseProxy": {
    "Routes": {
      "route1" : {
        "ClusterId": "cluster1",
        "AuthorizationPolicy": "customPolicy",
        "Match": {
          "Hosts": [ "localhost" ]
        }
      }
    },
    "Clusters": {
      "cluster1": {
        "Destinations": {
          "cluster1/destination1": {
            "Address": "https://localhost:10001/"
          }
        }
      }
    }
  }
}

criteri di autorizzazione sono un concetto di base ASP.NET utilizzato dal proxy. Il proxy fornisce la configurazione precedente per specificare un criterio per ogni route e il resto viene gestito dai componenti esistenti di autenticazione e autorizzazione di ASP.NET core.

I criteri di autorizzazione possono essere configurati nell'applicazione come segue:

services.AddAuthorization(options =>
{
    options.AddPolicy("customPolicy", policy =>
        policy.RequireAuthenticatedUser());
});

In Program.cs aggiungere il middleware di autorizzazione e autenticazione.

app.UseAuthentication();
app.UseAuthorization();

app.MapReverseProxy();

Vedere la documentazione autenticazione per configurare il tipo di autenticazione preferito.

Valori speciali:

Oltre ai nomi di criteri personalizzati, esistono due valori speciali che possono essere specificati nel parametro di autorizzazione di una route: default e anonymous. ASP.NET Core include anche un'impostazione FallbackPolicy applicabile alle route che non specificano criteri.

PoliticaPredefinita

Se si specifica il valore default nel parametro di autorizzazione di una route, la route userà i criteri definiti in AuthorizationOptions.DefaultPolicy. Questo criterio è preconfigurato per richiedere utenti autenticati.

Anonimo

Se si specifica il valore anonymous nel parametro di autorizzazione di una route, la route non richiederà l'autorizzazione indipendentemente da qualsiasi altra configurazione nell'applicazione, ad esempio FallbackPolicy.

FallbackPolicy

AuthorizationOptions.FallbackPolicy è la politica che verrà usata per qualsiasi richiesta o percorso non configurato con una politica. FallbackPolicy non ha un valore per impostazione predefinita, tutte le richieste saranno consentite.

Credenziali di flusso

Anche dopo che una richiesta è stata autorizzata nel proxy, il server di destinazione potrebbe comunque dover sapere chi è l'utente (autenticazione) e cosa è autorizzato a eseguire (autorizzazione). Il flusso delle informazioni dipenderà dal tipo di autenticazione in uso.

Questi tipi di autenticazione passano già i valori nelle intestazioni della richiesta e questi verranno trasmessi al server di destinazione per impostazione predefinita. Tale server dovrà comunque verificare e interpretare tali valori, causando un doppio lavoro.

OAuth2, OpenIdConnect, WsFederation

Questi protocolli vengono comunemente usati con provider di identità remoti. Il processo di autenticazione può essere configurato nell'applicazione proxy e comporterà un'autenticazione cookie. Tale cookie verrà inoltrato al server di destinazione come un'intestazione di richiesta normale.

Windows, Negotiate, NTLM, Kerberos

Questi tipi di autenticazione sono spesso associati a una connessione specifica. Non sono supportati come mezzo per autenticare un utente in un server di destinazione dietro il proxy YARP (vedere #166. Possono essere usati per autenticare una richiesta in ingresso al proxy, ma tali informazioni sull'identità dovranno essere comunicate al server di destinazione in un altro modulo. Possono anche essere utilizzati per autenticare il proxy presso i server di destinazione, ma solo come propri utenti del proxy; l'impersonificazione del client non è supportata.

Certificati client

I certificati client sono una funzionalità TLS e vengono negoziati come parte di una connessione. Per altre informazioni, vedere questi documenti. Il certificato può essere inoltrato al server di destinazione come intestazione HTTP usando la trasformazione ClientCert.

Scambio dei tipi di autenticazione

I tipi di autenticazione come Windows che non vengono trasmessi naturalmente al server di destinazione dovranno essere convertiti nel proxy in un modulo alternativo. Ad esempio, è possibile creare un token di connessione JWT con le informazioni utente e impostare nella richiesta proxy.

Questi scambi possono essere eseguiti usando trasformazioni di richieste personalizzate. È possibile sviluppare esempi dettagliati per scenari specifici se è presente un interesse della community sufficiente. Sono necessari altri commenti e suggerimenti dalla community su come convertire e gestire le informazioni sull'identità.

Condividi tramite