Show Menu
TÓPICOS×

Suporte a token encapsulado

Introdução

Por padrão, o AEM usa o Token Authentication Handler para autenticar cada solicitação. No entanto, para atender às solicitações de autenticação, o Token Authentication Handler requer acesso ao repositório para cada solicitação. Isso ocorre porque os cookies são usados para manter o estado de autenticação. Logicamente, o estado precisa ser persistente no repositório para validar solicitações subsequentes. Com efeito, isto significa que o mecanismo de autenticação é estável.
Isto é de particular importância para a escalabilidade horizontal. Em uma configuração de várias instâncias, como o farm de publicação descrito abaixo, o balanceamento de carga não pode ser obtido da maneira ideal. Com a autenticação com estado, o estado de autenticação persistente só estará disponível na instância em que o usuário foi autenticado pela primeira vez.
Veja 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 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 tem seu próprio repositório.
A solução para isso é configurar conexões rígidas 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. Consequentemente, não é possível um equilíbrio de carga verdadeiramente ótimo.
Caso uma instância de publicação fique 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

A solução para a escalabilidade horizontal é a autenticação sem estado com o uso do novo suporte a token encapsulado no AEM.
O token encapsulado é uma parte da criptografia que permite ao 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. 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 MongoMK e instâncias de publicação TarMK abaixo:
Observe que o Encapsulated Token é sobre autenticação. Ela garante que o cookie possa ser validado sem precisar acessar o repositório. No entanto, ainda é necessário que o usuário exista em todas as instâncias e que as informações armazenadas nesse usuário possam ser acessadas por cada instância.
Por exemplo, se um novo usuário for criado na instância número um da publicação, devido ao modo como o Token encapsulado funciona, ele será autenticado com êxito na publicação número dois. Se o usuário não existir na segunda instância de publicação, a solicitação ainda não terá êxito.

Configuração do token encapsulado

Há algumas coisas que você precisa levar em consideração ao configurar o token encapsulado:
  1. 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 o da(s) instância(s) de destino para a qual você deseja replicar as chaves. Consulte mais informações em "Replicando a chave HMAC" abaixo.
  2. O token encapsulado precisa ser ativado. Isso pode ser feito por meio do Console da Web.

Replicação da chave HMAC

A chave HMAC está presente como uma propriedade binária do /etc/key repositório. Você pode baixá-lo separadamente pressionando o link de visualização ao lado dele:
Para replicar a chave entre instâncias, é necessário:
  1. Acesse a instância do AEM, normalmente uma instância do autor, que contém o material principal a ser copiado;
  2. Localize o com.adobe.granite.crypto.file pacote no sistema de arquivos local. Por exemplo, neste caminho:
    • <author-aem-install-dir>/crx-quickstart/launch/felix/bundle21
    O bundle.info arquivo dentro de cada pasta identificará o nome do pacote.
  3. Navegue até a pasta de dados. Por exemplo:
    • <author-aem-install-dir>/crx-quickstart/launchpad/felix/bundle21/data
  4. Copie os arquivos HMAC e master.
  5. 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
  6. Cole os dois arquivos copiados anteriormente.
  7. Atualize o Conjunto de criptografia se a instância de destino já estiver em execução.
  8. Repita as etapas acima para todas as instâncias às quais deseja replicar a chave.

Ativação do token encapsulado

Depois que a chave HMAC tiver sido replicada, você poderá ativar o token encapsulado por meio do console da Web:
  1. Aponte seu navegador para https://serveraddress:port/system/console/configMgr
  2. Procure uma entrada chamada Day CRX Token Authentication Handler e clique nela.
  3. Na janela a seguir, marque a caixa Ativar suporte a token encapsulado e pressione Salvar .