Suporte a token encapsulado encapsulated-token-support
Introdução introduction
Por padrão, o AEM usa o Manipulador de autenticação de token para autenticar cada solicitação. No entanto, para servir solicitações de autenticação, o Manipulador de Autenticação de Token requer acesso ao repositório para cada solicitação. Isso acontece porque os cookies são usados para manter o estado de autenticação. Logicamente, o estado precisa ser mantido no repositório para validar solicitações subsequentes. Na verdade, isso significa que o mecanismo de autenticação é estático.
Este aspecto reveste-se de especial importância para a escalabilidade horizontal. Em uma configuração de várias instâncias, como o farm de publicação mostrado abaixo, o balanceamento de carga não pode ser obtido de maneira ideal. Com a autenticação de estado, o estado de autenticação persistente só estará disponível na instância em que o usuário é autenticado pela primeira vez.
Tome o seguinte cenário como exemplo:
Um usuário pode ser autenticado na instância de publicação um, mas se uma solicitação subsequente for para a instância de publicação dois, essa instância não terá esse estado de autenticação persistente, pois esse estado persistiu no repositório de publicar um e publicar dois terá seu próprio repositório.
A solução para isso é configurar conexões aderentes no nível do balanceador de carga. Com conexões aderentes, um usuário sempre seria direcionado para a mesma instância de publicação. Como consequência, não é possível um equilíbrio de carga verdadeiramente ótimo.
Caso uma instância de publicação se torne indisponível, todos os usuários autenticados nessa instância perderão sua sessão. Isso ocorre porque o acesso ao repositório é necessário para validar o cookie de autenticação.
Autenticação sem estado com o token encapsulado stateless-authentication-with-the-encapsulated-token
A solução para a escalabilidade horizontal é a autenticação sem estado com o uso do novo suporte de Token Encapsulado no AEM.
O Token Encapsulado é uma parte da criptografia que permite AEM criar e validar com segurança as informações de autenticação offline, sem acessar o repositório. Dessa forma, uma solicitação de autenticação pode ocorrer em todas as instâncias de publicação e sem necessidade de conexões aderentes. Ela também tem a vantagem de melhorar o desempenho da autenticação, pois o repositório não precisa ser acessado para cada solicitação de autenticação.
Você pode ver como isso funciona em uma implantação distribuída geograficamente com autores do MongoMK e instâncias de publicação do TarMK abaixo:
Configuração do token encapsulado configuring-the-encapsulated-token
-
As sessões adesivas estão ativadas ou
-
Os usuários já são criados no AEM quando a sincronização é iniciada. Isso significa que os tokens encapsulados não serão aceitos em situações em que os manipuladores criar durante o processo de sincronização.
Há algumas coisas que você precisa considerar ao configurar o Token encapsulado:
- Devido à criptografia envolvida, todas as instâncias precisam ter a mesma chave HMAC. Desde o AEM 6.3, o material principal não é mais armazenado no repositório, mas no sistema de arquivos real. Com isso em mente, a melhor maneira de replicar as chaves é copiá-las do sistema de arquivos da instância de origem para a instância de destino para a qual você deseja replicar as chaves. Consulte mais informações em "Replicação da chave HMAC" abaixo.
- O token encapsulado precisa ser ativado. Isso pode ser feito através do Console da Web.
Replicação da chave HMAC replicating-the-hmac-key
A chave HMAC está presente como uma propriedade binária de /etc/key no repositório. Você pode baixá-lo separadamente pressionando a tecla exibir link ao lado dele:
Para replicar a chave entre instâncias, é necessário:
-
Acesse a instância AEM, normalmente uma instância de autor, que contém o material principal a ser copiado;
-
Localize a variável
com.adobe.granite.crypto.fileno sistema de arquivos local. Por exemplo, neste caminho:- <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21
O
bundle.infoo arquivo dentro de cada pasta identificará o nome do pacote. -
Navegue até a pasta de dados. Por exemplo:
<author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Copie o HMAC e os arquivos principais.
-
Em seguida, vá para a instância de destino para a qual deseja duplicar a chave HMAC e navegue até a pasta de dados. Por exemplo:
<publish-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
-
Cole os dois arquivos copiados anteriormente.
-
Atualizar o pacote de criptografia se a instância de destino já estiver em execução.
-
Repita as etapas acima para todas as instâncias para as quais deseja replicar a chave.
Ativação do token encapsulado enabling-the-encapsulated-token
Depois que a chave HMAC tiver sido replicada, você poderá habilitar o Token Encapsulado por meio do Console da Web:
- Aponte seu navegador para
https://serveraddress:port/system/console/configMgr - Procure uma entrada chamada Manipulador de autenticação de token CRX do dia e clique nele.
- Na janela a seguir, marque a opção Ativar suporte a token encapsulado e pressione Salvar.