Condividi tramite

Panoramica di autenticazione e autorizzazione back-end

  • Articolo

L'esempio di carico di lavoro per sviluppatori di Fabric include i flussi di autenticazione seguenti sul lato back-end.

Autenticazione e autorizzazione delle richieste da Fabric al carico di lavoro

Struttura dell'intestazione dell'autorizzazione

L'intestazione dell'autorizzazione usa un formato di token specifico:

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

Questo formato include due token distinti:

  • subjectToken: token delegato che rappresenta l'utente per conto del quale viene eseguita l'operazione.
  • appToken: token specifico dell'applicazione Fabric.

La logica alla base dell'uso di un'intestazione dual-token è triplice:

  • Convalida: il carico di lavoro può verificare che la richiesta abbia avuto origine da Fabric convalidando appToken.

  • Contesto utente: subjectToken fornisce un contesto utente per l'azione eseguita.

  • Comunicazione tra servizi: il carico di lavoro può acquisire un token OBO (On-Behalf-Of) usando subjectToken, consentendo di chiamare altri servizi con un token utente.

Autenticazione

I controlli di autenticazione principali eseguiti per SubjectAndAppToken sono:

  • La convalida e l'analisi del valore dell'intestazione di autorizzazione vengono eseguite nel metodo AuthenticateControlPlaneCall . Il token deve iniziare con il prefisso "SubjectAndAppToken1.0" e includere due token: subjectToken e appToken.

  • Convalida delle proprietà del token Entra: sia subjectToken che appToken vengono convalidate per le proprietà comuni del token Microsoft Entra nel metodo ValidateAadTokenCommon. Queste proprietà includono la firma del token, la durata del token, il gruppo di destinatari dei token (destinatari dell'app del carico di lavoro), la versione del token (1.0) e l'autorità emittente.

  • Convalida delle proprietà appToken: appToken non deve avere un'attestazione scp, ma deve avere un'attestazione idtyp con l'app come valore. È anche possibile verificare che l'attestazione tid sia presente nell'ID tenant del server di pubblicazione del carico di lavoro.

    Attestazioni appToken di esempio:

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700047232,
"nbf": 1700047232,
"exp": 1700133932,
"aio": "E2VgYLjBuv2l+c6cmm/iP/bnL2v+AQA=",
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"idp": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"idtyp": "app",
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"rh": "0.ACgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZAAA.",
"sub": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"uti": "5bgMXs3uMUSAHCruRjACAA",
"ver": "1.0"
}

  • Convalida delle proprietà subjectToken: assicurarsi che subjectToken includa un'attestazione scp con l'ambito FabricWorkloadControl, che non sia presente alcuna attestazione idtyp nel token e che abbia lo stesso appid di appToken.

    Attestazioni subjectToken di esempio:

    {
"aud": "api://localdevinstance/00001111-aaaa-2222-bbbb-3333cccc4444/Fabric.WorkloadSample/123",
"iss": "https://sts.windows.net/12345678-77f3-4fcc-bdaa-487b920cb7ee/",
"iat": 1700050446,
"nbf": 1700050446,
"exp": 1700054558,
"acr": "1",
"aio": "ATQAy/8VAAAAUgWRMRnBo4VGHvrKRykUXOXBNKS1cHnBxLrYkZJJGSjAVyJGBecbLdSud1GUakER",
"amr": [
    "pwd"
],
"appid": "11112222-bbbb-3333-cccc-4444dddd5555"
"appidacr": "2",
"ipaddr": "46.117.19.50",
"name": "john doe",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"rh": "0.ASgAGX-u-vN3zE-9qkh7kgy37hQbaU7-v2xFr59O_foS7VLZANQ.",
"scp": "FabricWorkloadControl",
"sub": "X0Wl85UA-uOmdkQz5MoT-hEgYZXDq9FYdS8g2bFUaZA",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff",
"unique_name": "user1@constso.com",
"upn": "user1@constso.com",
"uti": "_llZwmJoSUiHv-kw6tfDAA",
"ver": "1.0"
}

Vedere IAuthenticationService.

Nota

Tutte le convalide nel codice di esempio sono per i token della versione 1.0.

Autorizzazione

Dopo aver confermato che la richiesta ha origine dal servizio Fabric (tramite appToken), Fabric ha verificato che l'utente dispone delle autorizzazioni necessarie per eseguire l'azione, in base ai metadati delle autorizzazioni di Fabric.

Autenticazione e autorizzazione delle richieste dal carico di lavoro a Fabric

Richieste di controllo del carico di lavoro

Le API di controllo del carico di lavoro sono API Fabric speciali che supportano i carichi di lavoro con la gestione del ciclo di vita degli elementi di Fabric. Queste API usano lo stesso formato di intestazione dell'autorizzazione di SubjectAndAppToken1.0.

SubjectAndAppToken1.0 subjectToken="delegated token", appToken="S2S token"

Chiamate provenienti dal carico di lavoro, inclusi i token seguenti:

  • subjectToken: token delegato dall'utente (ottenuto tramite il flusso OBO) che rappresenta l'utente per conto del quale viene eseguita l'operazione. Fabric verifica che l'utente disponga delle autorizzazioni necessarie per eseguire l'azione necessaria.

  • appToken: token specifico dell'applicazione del carico di lavoro. Fabric verifica che questo token provenga dall'app Microsoft Entra del carico di lavoro a cui appartiene l'elemento fabric pertinente e che si trova nel tenant dell'editore del carico di lavoro.

Vedere il metodo ValidatePermissions in AuthorizationHandler.

API pubbliche

Per chiamare le API di Infrastruttura pubblica, il carico di lavoro deve acquisire un token OBO Microsoft Entra standard con gli ambiti API pertinenti e passarlo come token di connessione nell'intestazione di autorizzazione della richiesta.

Vedere FabricExtensionController.

Autenticazione e autorizzazione delle richieste dal carico di lavoro FE al carico di lavoro BE

Authorization header (Intestazione dell'autorizzazione)

L'intestazione dell'autorizzazione in una richiesta inviata dal carico di lavoro FE al carico di lavoro BE usa un bearer token standard.

Autenticazione

Il metodo AuthenticateControlPlaneCall nel carico di lavoro BE è responsabile della convalida del token. I principali controlli eseguiti sono:

  • Durata del token: assicura che il token si trovi entro il periodo di utilizzo valido.

  • Firma: verifica l'autenticità del token.

  • Destinatari: verifica che il gruppo di destinatari del token corrisponda al carico di lavoro Dell'app Microsoft Entra.

  • Emittente: convalida l'autorità di certificazione del token.

  • Ambiti consentiti: convalida gli ambiti a cui il token è autorizzato ad accedere.

L'autorizzazione viene ottenuta richiamando il metodo ValidatePermissions. Questo metodo chiama l'API resolvePermissions nell'endpoint di controllo del carico di lavoro Fabric per l'elemento Fabric pertinente e verifica che l'utente disponga delle autorizzazioni necessarie per l'operazione.

Operazioni a esecuzione prolungata - Token di aggiornamento

L'autorizzazione viene ottenuta richiamando il metodo ValidatePermissions. Questo metodo chiama l'API resolvePermissions nell'endpoint di controllo del carico di lavoro Fabric per l'elemento Fabric pertinente e verifica che l'utente disponga delle autorizzazioni necessarie per l'operazione.

Se i carichi di lavoro includono operazioni a esecuzione prolungata, ad esempio, come parte di JobScheduler , è possibile che si verifichi una situazione in cui la durata del token non è sufficiente. Per altre informazioni su come autenticare il processo a esecuzione prolungata, i processi OBO a esecuzione prolungata.