Hierarquia de finalidade e multilocação em ASP.NET Core

Como um IDataProtector também é implicitamente um IDataProtectionProvider, as finalidades podem ser encadeadas. Nesse sentido, provider.CreateProtector([ "purpose1", "purpose2" ]) é equivalente a provider.CreateProtector("purpose1").CreateProtector("purpose2").

Isso permite algumas relações hierárquicas interessantes por meio do sistema de proteção de dados. No exemplo anterior de Contoso.Messaging.SecureMessage, o componente SecureMessage pode chamar provider.CreateProtector("Contoso.Messaging.SecureMessage") uma vez antecipadamente e armazenar o resultado em cache em um campo privado _myProvider . Os protetores futuros podem ser criados por meio de chamadas a _myProvider.CreateProtector("User: username") e esses protetores seriam usados para proteger as mensagens individuais.

Isso também pode ser invertido. Considere um único aplicativo lógico que hospeda vários locatários (um CMS parece razoável) e cada locatário pode ser configurado com seu próprio sistema de gerenciamento de estado e autenticação. O aplicativo guarda-chuva tem um único provedor mestre e chama provider.CreateProtector("Tenant 1") e provider.CreateProtector("Tenant 2") para dar a cada locatário sua própria fatia isolada do sistema de proteção de dados. Os locatários poderiam então derivar seus próprios protetores individuais com base em suas próprias necessidades, mas não importa o quanto tentem, eles não podem criar protetores que colidam com qualquer outro locatário no sistema. Graficamente, isso é representado conforme mostrado abaixo.

Aviso

Isso pressupõe que o aplicativo guarda-chuva controla quais APIs estão disponíveis para locatários individuais e que os locatários não podem executar código arbitrário no servidor. Se um locatário puder executar um código arbitrário, ele poderá executar reflexão privada para quebrar as garantias de isolamento ou pode apenas ler o material de chave mestra diretamente e derivar quaisquer subchaves desejadas.

Na verdade, o sistema de proteção de dados usa uma espécie de multilocação em sua configuração pronta para uso padrão. Por padrão, o material de chave mestra é armazenado na pasta de perfil de usuário da conta de processo de trabalho (ou no registro, para identidades do pool de aplicativos do IIS). Mas, na verdade, é bastante comum usar uma única conta para executar vários aplicativos e, portanto, todos esses aplicativos acabariam compartilhando o material de chave mestra. Para resolver isso, o sistema de proteção de dados insere automaticamente um identificador exclusivo por aplicativo como o primeiro elemento na cadeia de finalidade geral. Essa finalidade implícita serve para isolar aplicativos individuais uns dos outros, tratando efetivamente cada aplicativo como um locatário exclusivo dentro do sistema, e o processo de criação do protetor parece idêntico à imagem acima.