Gerarchia degli scopi e multi-tenancy in ASP.NET Core

Poiché un IDataProtector oggetto è anche implicitamente un oggetto IDataProtectionProvider, gli scopi possono essere concatenati. In questo senso, provider.CreateProtector([ "purpose1", "purpose2" ]) equivale a provider.CreateProtector("purpose1").CreateProtector("purpose2").

Ciò consente alcune relazioni gerarchica interessanti tramite il sistema di protezione dei dati. Nell'esempio precedente di Contoso.Messaging.SecureMessage, il componente SecureMessage può chiamare provider.CreateProtector("Contoso.Messaging.SecureMessage") una volta in anticipo e memorizzare nella cache il risultato in un campo privato _myProvider . È quindi possibile creare protezioni future tramite chiamate a _myProvider.CreateProtector("User: username")e queste protezioni verranno usate per proteggere i singoli messaggi.

Questo può anche essere capovolto. Si consideri una singola applicazione logica che ospita più tenant (un CMS sembra ragionevole) e ogni tenant può essere configurato con il proprio sistema di autenticazione e gestione dello stato. L'applicazione umbrella ha un singolo provider master e chiama provider.CreateProtector("Tenant 1") e provider.CreateProtector("Tenant 2") per assegnare a ogni tenant una sezione isolata del sistema di protezione dei dati. I tenant potrebbero quindi derivare le proprie protezioni individuali in base alle proprie esigenze, ma indipendentemente dal livello di difficoltà che provano a creare protezioni che si scontrano con qualsiasi altro tenant nel sistema. Graficamente, questo è rappresentato come riportato di seguito.

Avviso

Ciò presuppone che l'applicazione generica controlli quali API sono disponibili per i singoli tenant e che i tenant non possono eseguire codice arbitrario nel server. Se un tenant può eseguire codice arbitrario, potrebbe eseguire la reflection privata per interrompere le garanzie di isolamento oppure semplicemente leggere il materiale di keying master direttamente e derivare le sottochiavi desiderate.

Il sistema di protezione dei dati usa effettivamente una sorta di multi-tenancy nella configurazione predefinita predefinita. Per impostazione predefinita, il materiale per la chiave master viene archiviato nella cartella del profilo utente dell'account del processo di lavoro (o nel Registro di sistema per le identità del pool di applicazioni IIS). Ma in realtà è piuttosto comune usare un singolo account per eseguire più applicazioni e quindi tutte queste applicazioni finirebbero per condividere il materiale di keying master. Per risolvere questo problema, il sistema di protezione dei dati inserisce automaticamente un identificatore univoco per applicazione come primo elemento nella catena globale degli scopi. Questo scopo implicito serve a isolare le singole applicazioni l'una dall'altra trattando in modo efficace ogni applicazione come tenant univoco all'interno del sistema e il processo di creazione della protezione è identico all'immagine precedente.