Autenticazione e autorizzazione nell'app
La sicurezza è fondamentale per le applicazioni Web moderne. Fluid Framework, come parte dell'architettura dell'applicazione Web è un elemento importante dell'infrastruttura da proteggere. Fluid Framework è un'architettura a più livelli e i concetti correlati all'autenticazione vengono implementati in base al servizio Fluid a cui si connette. Ciò significa che, anche se sono presenti temi di autenticazione comuni in tutti i servizi Fluid, i dettagli e le specifiche saranno diversi per ogni servizio.
Servizio Inoltro fluido di Azure
A ogni tenant del servizio Inoltro fluido di Azure creato viene assegnato un ID tenant e la propria chiave privata del tenant univoca.
La chiave privata è un segreto condiviso. L'app o il servizio lo conosce e il servizio Inoltro fluido di Azure lo conosce. Poiché la chiave privata del tenant è associata in modo univoco al tenant, usandola per firmare le richieste al servizio Inoltro fluido di Azure che le richieste provengono da un utente autorizzato del tenant.
La chiave privata è il modo in cui il servizio Inoltro fluido di Azure sa che le richieste provengono dall'app o dal servizio. Questo aspetto è fondamentale, perché una volta che il servizio Inoltro fluido di Azure può considerare attendibile che si tratti dell'app che effettua le richieste, può considerare attendibili i dati inviati. Questo è anche il motivo per cui è importante che il segreto venga gestito in modo sicuro.
Attenzione
Chiunque abbia accesso al segreto può rappresentare l'applicazione durante la comunicazione con il servizio Inoltro fluido di Azure.
Token Web JSON e servizio Di inoltro fluido di Azure
Inoltro fluido di Azure usa token JSON Web (JWT) per codificare e verificare i dati firmati con la chiave privata. I token Web JSON sono un bit JSON firmato che può includere informazioni aggiuntive sui diritti e sulle autorizzazioni.
Nota
Le specifiche dei token JWT non rientrano nell'ambito di questo articolo. Per altre informazioni sullo standard JWT, vedere Introduzione ai token Web JSON.
Anche se i dettagli dell'autenticazione differiscono tra i servizi Fluid, è necessario che siano sempre presenti diversi valori.
- containerId Il servizio Fluid richiede l'ID contenitore per identificare quale servizio corrisponde al contenitore chiamante. Nota: JWT chiama questo field documentId, ma il servizio Fluid prevede un ID contenitore in questo campo.
- tenantId: il servizio Inoltro fluido di Azure usa l'ID tenant per recuperare il segreto condiviso che userà per autenticare la richiesta.
- ambiti: gli ambiti definiscono le autorizzazioni del contenitore chiamante. Il contenuto del campo ambiti è flessibile, consentendo di creare autorizzazioni personalizzate.
{
"alg": "HS256",
"typ": "JWT"
}.{
"documentId": "azureFluidDocumentId",
"scopes": [ "doc:read", "doc:write", "summary:write" ],
"user": {
"name": "TestUser",
"id": "Test-Id-123"
},
"iat": 1599098963,
"exp": 1599098963,
"tenantId": "AzureFluidTenantId",
"ver": "1.0"
}.[Signature]
La modalità dell'utente indica se la connessione è in modalità di lettura o lettura/scrittura. Può essere visualizzato dal connections campo in AzureAudience. Le autorizzazioni per l'ambito del token possono essere aggiornate nella funzione generateToken di Azure serverless.
const token = generateToken(
tenantId,
documentId,
key,
scopes ?? [ "Token Scope" ],
user
);
Gli ambiti del token insieme al comportamento e alle modalità del contenitore sono i seguenti:
| Ambito token | Comportamento del documento personale | Comportamento del documento gruppo di destinatari |
|---|---|---|
| DocRead | Leggere e scrivere nel documento. Le modifiche apportate al documento non vengono riflesse in alcun altro documento del gruppo di destinatari. Modalità: Lettura |
Leggere e scrivere nel documento. Le modifiche non vengono riflesse in alcun altro documento del gruppo di destinatari. Modalità: Scrittura |
| DocWrite | Leggere e scrivere nel documento. Le modifiche apportate vengono riflesse in tutti gli altri documenti del gruppo di destinatari. Modalità: Scrittura |
Leggere e scrivere nel documento. Le modifiche apportate vengono riflesse in tutti gli altri documenti del gruppo di destinatari. Modalità: Scrittura |
| DocRead, DocWrite | Leggere e scrivere nel documento. Le modifiche apportate vengono riflesse in tutti gli altri documenti del gruppo di destinatari. Modalità: Scrittura |
Leggere e scrivere nel documento. Le modifiche apportate vengono riflesse in tutti gli altri documenti del gruppo di destinatari. Modalità: Scrittura |
Nota
Si noti che il token include anche informazioni sull'utente (vedere le righe 7-9 precedenti). È possibile usarlo per aumentare le informazioni utente disponibili automaticamente per il codice Fluid usando la funzionalità destinatari . Per altre informazioni, vedere Aggiunta di dati personalizzati ai token .
Provider di token
Ogni richiesta ad Inoltro fluido di Azure deve essere firmata con un token JWT valido. Fluid delega la responsabilità di creare e firmare questi token ai provider di token.
Un provider di token è responsabile della creazione e della firma dei token usati @fluidframework/azure-client da per effettuare richieste al servizio Inoltro fluido di Azure. È necessario fornire l'implementazione del provider di token sicuro. Fluid fornisce tuttavia un oggetto InsecureTokenProvider che accetta il segreto tenant, quindi genera e restituisce un token firmato in locale. Questo provider di token è utile per i test, ma non può essere usato negli scenari di produzione.
Provider di token serverless sicuro
Un'opzione per la creazione di un provider di token sicuro consiste nel creare una funzione di Azure serverless ed esporla come provider di token. In questo modo è possibile archiviare la chiave privata del tenant in un server sicuro. L'applicazione chiamerebbe quindi la funzione di Azure per generare token anziché firmarli in locale come avviene.InsecureTokenProvider Per altre informazioni, vedere Procedura: Scrivere un tokenProvider con una funzione di Azure.
Connessione dell'autenticazione utente all'autenticazione del servizio Fluid
I servizi fluidi autenticano le chiamate in ingresso usando un segreto client condiviso, che non è associato a un utente specifico. L'autenticazione utente può essere aggiunta in base ai dettagli del servizio Fluid.
Un'opzione semplice per l'autenticazione utente consiste nell'usare semplicemente una funzione di Azure come provider di token e applicare l'autenticazione utente come condizione per ottenere un token. Se un'applicazione tenta di chiamare la funzione, l'operazione avrà esito negativo a meno che non sia stata autenticata con il sistema di autenticazione. Se si usa l'ID Microsoft Entra, ad esempio, è possibile creare un'applicazione Microsoft Entra per la funzione di Azure e collegarla al sistema di autenticazione dell'organizzazione.
In questo caso, l'utente accederà all'applicazione usando l'ID Entra Microsoft, tramite il quale si otterrebbe un token da usare per chiamare la funzione di Azure. La funzione di Azure si comporta allo stesso modo, ma ora è accessibile solo alle persone che hanno anche eseguito l'autenticazione con Microsoft Entra ID.
Poiché la funzione di Azure è ora il punto di ingresso per ottenere un token valido, solo gli utenti che hanno eseguito correttamente l'autenticazione alla funzione potranno quindi fornire tale token al servizio Inoltro fluido di Azure dall'applicazione client. Questo approccio in due passaggi consente di usare il proprio processo di autenticazione personalizzato insieme al servizio Inoltro fluido di Azure.