Show Menu
TÓPICOS×

Grupos de usuários fechados no AEM

Introdução

Desde o AEM 6.3, há uma nova implementação do Grupo de usuários fechado destinada a resolver os problemas de desempenho, escalabilidade e segurança presentes na implementação existente.
Por uma questão de simplicidade, a abreviação do CUG será utilizada ao longo desta documentação.
O objetivo da nova implementação é cobrir a funcionalidade existente quando necessário e, ao mesmo tempo, resolver problemas e limitações de design de versões mais antigas. O resultado é um novo design de CUG com as seguintes características:
  • Separação clara dos elementos de autenticação e autorização, que podem ser utilizados individualmente ou em combinação;
  • Modelo de autorização dedicado para refletir o acesso restrito de leitura nas árvores de CUG configuradas, sem interferir com outras configurações de controle de acesso e requisitos de permissão;
  • Separação entre a configuração do controle de acesso do acesso restrito de leitura, que geralmente é necessária em instâncias de criação, e a avaliação de permissão, que geralmente é desejada apenas na publicação;
  • Edição de acesso restrito de leitura sem escalonamento de privilégios;
  • Extensão de tipo de nó dedicada para marcar o requisito de autenticação;
  • Caminho de logon opcional associado ao requisito de autenticação.

A nova implementação personalizada do grupo de usuários

Um CUG, como é conhecido no contexto do AEM, consiste nas seguintes etapas:
  • Restrinja o acesso de leitura na árvore que precisa ser protegida e permita somente a leitura de principais listados com uma determinada instância CUG ou excluídos da avaliação CUG. Isso é chamado de elemento de autorização .
  • Impor autenticação em uma determinada árvore e, opcionalmente, especificar uma página de logon dedicada para essa árvore que será excluída subsequentemente. Isso é chamado de elemento de autenticação .
A nova implementação foi concebida para estabelecer uma linha entre a autenticação e os elementos de autorização. A partir do AEM 6.3, é possível restringir o acesso de leitura sem adicionar explicitamente um requisito de autenticação. Por exemplo, se uma determinada instância exigir autenticação completamente ou uma determinada árvore já residir em uma subárvore que já requer autenticação.
Da mesma forma, determinada árvore pode ser marcada com um requisito de autenticação sem alterar a configuração de permissão efetiva. As combinações e os resultados são listados na seção Políticas CUG combinadas e Requisito de autenticação.

Visão geral

Autorização: Restrição do acesso de leitura

O recurso principal de um CUG está restringindo o acesso de leitura em uma determinada árvore no repositório de conteúdo para todos, exceto os principais selecionados. Em vez de manipular o conteúdo de controle de acesso padrão imediatamente, a nova implementação adota uma abordagem diferente definindo um tipo dedicado de política de controle de acesso que representa um CUG.

Política de controle de acesso para CUG

Este novo tipo de política tem as seguintes características:
  • Política de controle de acesso do tipo org.apache.Jackrabbit.api.security.entitlement.PrincipalSetPolicy (definido pela API Apache Jackrabbit);
  • PrincipalSetPolicy concede privilégios a um conjunto modificável de principais;
  • Os privilégios concedidos e o âmbito da política são um detalhe de implementação.
A implementação de PrincipalSetPolicy usada para representar CUGs além disso define que:
  • As políticas CUG só concedem acesso de leitura a itens JCR regulares (por exemplo, o conteúdo de controle de acesso é excluído);
  • O escopo é definido pelo nó controlado de acesso que detém a política CUG;
  • As políticas CUG podem ser aninhadas, um CUG aninhado inicia um novo CUG sem herdar o conjunto principal do CUG 'pai';
  • O efeito da política, se a avaliação estiver ativada, será herdado para toda a subárvore até o próximo CUG aninhado.
Essas políticas de CUG são implantadas em uma instância do AEM por meio de um módulo de autorização separado, chamado cookie-autorização. Este módulo vem com seu próprio gerenciamento de controle de acesso e avaliação de permissões. Em outras palavras, a configuração padrão do AEM envia uma configuração de repositório de conteúdo Oak que combina vários mecanismos de autorização. Para obter mais informações, consulte esta página na Documentação do Apache Oak.
Nesta configuração composta, um novo CUG não substitui o conteúdo de controle de acesso existente anexado ao nó de destino, mas é projetado para ser um suplemento que também pode ser removido posteriormente sem afetar o controle de acesso original, que por padrão no AEM seria uma lista de controle de acesso.
Em contraste com a anterior implementação, as novas políticas de CUG são sempre reconhecidas e tratadas como conteúdo de controle de acesso. Isso implica que eles sejam criados e editados usando a API de gerenciamento do controle de acesso JCR. Para obter mais informações, consulte a seção Gerenciando Políticas CUG.

Avaliação de Permissão das Políticas CUG

Além de um gerenciamento de controle de acesso dedicado para CUGs, o novo modelo de autorização permite condicionalmente habilitar a avaliação de permissão para suas políticas. Isso permite configurar políticas CUG em um ambiente de preparo temporário e ativar somente a avaliação das permissões efetivas depois de replicadas no ambiente de produção.
A avaliação de permissão para políticas CUG e a interação com o padrão ou qualquer modelo de autorização adicional seguem o padrão projetado para vários mecanismos de autorização no Apache Jackrabbit Oak: um determinado conjunto de permissões é concedido se e somente se todos os modelos concederem acesso. Consulte esta página para obter mais detalhes.
As seguintes características se aplicam à avaliação de permissão associada ao modelo de autorização projetado para manipular e avaliar políticas de CUG:
  • Ele só lida com permissões de leitura para nós e propriedades comuns, mas não lendo o conteúdo de controle de acesso
  • Ele não lida com permissões de gravação nem com nenhum tipo de permissões necessárias para a modificação de conteúdo JCR protegido (controle de acesso, informações de tipo de nó, controle de versão, bloqueio ou gerenciamento de usuários entre outros); Essas permissões não são afetadas por uma política CUG e não serão avaliadas pelo modelo de autorização associado. A concessão ou não dessas permissões depende dos outros modelos configurados na configuração de segurança.
O efeito de uma única política de CUG na avaliação das permissões pode resumir-se do seguinte modo:
  • O acesso de leitura é negado a todos, exceto aos assuntos que contenham os principais ou principais excluídos enumerados na política;
  • A política produz efeitos no nó controlado de acesso que detém a política e as suas propriedades;
  • O efeito é adicionalmente herdado na hierarquia - isto é, a árvore de itens definida pelo nó controlado de acesso;
  • No entanto, não afeta irmãos nem antepassados do nó controlado de acesso;
  • A herança de um determinado CUG é interrompida em um CUG aninhado.

Práticas recomendadas

As práticas recomendadas a seguir devem ser levadas em conta para a definição de acesso restrito de leitura por meio de CUGs:
  • Tome uma decisão consciente sobre se sua necessidade de um CUG é restringir o acesso de leitura ou um requisito de autenticação. No caso deste último, ou se houver necessidade de ambos, consulte a seção Práticas recomendadas para obter detalhes sobre o requisito de autenticação
  • Crie um modelo de ameaça para os dados ou conteúdo que precisam ser protegidos para identificar os limites de ameaça e obter uma visão clara sobre a sensibilidade dos dados e as funções associadas ao acesso autorizado
  • Modelar o conteúdo do repositório e os CUGs, tendo em mente aspectos e práticas recomendadas gerais relacionados à autorização:
    • Lembre-se de que a permissão de leitura só será concedida se um determinado CUG e a avaliação de outros módulos implantados na concessão de configuração permitirem que um determinado sujeito leia um determinado item do repositório
    • Evite criar CUGs redundantes onde o acesso de leitura já esteja restrito por outros módulos de autorização
    • A necessidade excessiva de CUGs aninhados pode potencialmente destacar problemas no design de conteúdo
    • Uma necessidade muito excessiva de CUGs (por exemplo, em cada página) pode indicar a necessidade de um modelo de autorização personalizado potencialmente mais adequado para atender às necessidades de segurança específicas do aplicativo e do conteúdo em questão.
  • Limite os caminhos suportados para políticas CUG a algumas árvores no repositório para permitir desempenho otimizado. Por exemplo, permita apenas CUGs abaixo do nó /content como enviado como valor padrão desde o AEM 6.3.
  • As políticas de CUG são projetadas para conceder acesso de leitura a um pequeno conjunto de principais. A necessidade de um grande número de principais pode destacar problemas no conteúdo ou no design do aplicativo e deve ser reconsiderada.

Autenticação: Definição do requisito de autenticação

As partes relacionadas à autenticação do recurso CUG permitem marcar árvores que exigem autenticação e, opcionalmente, especificar uma página de logon dedicada. De acordo com a versão anterior, a nova implementação permite marcar árvores que exigem autenticação no repositório de conteúdo e ativar condicionalmente a sincronização com o Sling org.apache.sling.api.auth.Authenticator responsável por, em última análise, aplicar o requisito e redirecionar para um recurso de logon.
Esses requisitos são registrados no Autenticador por meio de um serviço OSGi que fornece a propriedade de sling.auth.requirements registro. Essas propriedades são então usadas para estender dinamicamente os requisitos de autenticação. Para obter mais detalhes, consulte a documentação do Sling.

Definição do requisito de autenticação com um tipo de combinação dedicado

Por motivos de segurança, a nova implementação substitui o uso de uma propriedade JCR residual por um tipo de combinação dedicada chamado granite:AuthenticationRequired , que define uma propriedade opcional única do tipo STRING para o caminho de login granite:loginPath . Somente as alterações de conteúdo relacionadas a esse tipo de mixagem levarão à atualização dos requisitos registrados no Autenticador Apache Sling. As modificações são rastreadas após a persistência de modificações transitórias e, portanto, exigem uma javax.jcr.Session.save() chamada para se tornar efetiva.
O mesmo se aplica à granite:loginPath propriedade. Só será respeitado se for definido pelo tipo de mistura relacionado com os requisitos de autenticação. Adicionar uma propriedade residual com esse mesmo nome em um nó JCR não estruturado não mostrará o efeito desejado e a propriedade será ignorada pelo manipulador responsável pela atualização do registro OSGi.
A configuração da propriedade de caminho de login é opcional e só é necessária se a árvore que requer autenticação não puder voltar para a página de logon padrão ou herdada. Consulte a Avaliação do caminho de logon abaixo.

Registrando o requisito de autenticação e o caminho de logon com o Sling Authenticator

Como é esperado que esse tipo de requisito de autenticação esteja limitado a determinados modos de execução e a um pequeno subconjunto de árvores no repositório de conteúdo, o rastreamento do tipo de combinação necessário e das propriedades do caminho de login é condicional e vinculado a uma configuração correspondente que define os caminhos suportados (consulte Opções de configuração abaixo). Consequentemente, somente as alterações dentro do escopo desses caminhos suportados acionarão uma atualização do registro OSGi, em qualquer outro lugar, tanto o tipo de mistura quanto a propriedade serão ignorados.
A configuração padrão do AEM agora utiliza essa configuração permitindo definir a mixin no modo de execução do autor, mas somente para que ela seja aplicada na replicação para a instância de publicação. Consulte esta página para obter detalhes sobre como o Sling aplica o requisito de autenticação.
A adição do tipo de granite:AuthenticationRequired mistura nos caminhos suportados configurados fará com que o registro OSGi do manipulador responsável seja atualizado com uma nova entrada adicional com a sling.auth.requirements propriedade. Se um determinado requisito de autenticação especificar a granite:loginPath propriedade opcional, o valor será registrado adicionalmente no Autenticador com um prefixo '-' para ser excluído do requisito de autenticação.

Avaliação e herança do requisito de autenticação

Espera-se que os requisitos de autenticação do Apache Sling sejam herdados por meio da hierarquia de página ou nó. Os detalhes da herança e a avaliação dos requisitos de autenticação, como ordem e precedência, são considerados detalhes da implementação e não serão documentados neste artigo.

Avaliação do caminho de logon

A avaliação do caminho de logon e o redirecionamento para o recurso correspondente após a autenticação é atualmente um detalhe de implementação do Adobe Granite Login Seletor Authentication Handler ( com.day.cq.auth.impl.LoginSelectorHandler ), que é um Apache Sling AuthenticationHandler configurado com AEM por padrão.
Ao chamar AuthenticationHandler.requestCredentials esse manipulador, é feita uma tentativa de determinar a página de logon de mapeamento para a qual o usuário será redirecionado. Isso inclui as seguintes etapas:
  • Distinguir entre a senha expirada e a necessidade de login regular como motivo para o redirecionamento;
  • No caso de um login regular, testa se um caminho de login pode ser obtido na seguinte ordem:
    • do LoginPathProvider conforme implementado pelo novo com.adobe.granite.auth.requirement.impl.RequirementService ,
    • da implementação antiga e obsoleta do CUG,
    • nos Mapeamentos de página de logon, conforme definido com o LoginSelectorHandler ,
    • e, finalmente, retorne para a Página de logon padrão, conforme definido com o LoginSelectorHandler .
  • Assim que um caminho de logon válido for obtido por meio das chamadas listadas acima, a solicitação do usuário será redirecionada para essa página.
O destino desta documentação é a avaliação do caminho de logon como exposto pela LoginPathProvider interface interna. A implementação enviada desde o AEM 6.3 se comporta da seguinte maneira:
  • O registro de caminhos de login depende da distinção entre a senha expirada e a necessidade de login regular como motivo para o redirecionamento
  • No caso de login regular, testa se um caminho de login pode ser obtido na seguinte ordem:
    • a partir da data LoginPathProvider em que a nova diretiva for aplicada com.adobe.granite.auth.requirement.impl.RequirementService ,
    • da implementação antiga e obsoleta do CUG,
    • nos Mapeamentos de página de logon, conforme definido com o LoginSelectorHandler ,
    • e, por fim, voltar para a Página de logon padrão, conforme definido com o LoginSelectorHandler .
  • Assim que um caminho de logon válido for obtido por meio das chamadas listadas acima, a solicitação do usuário será redirecionada para essa página.
O LoginPathProvider conforme implementado pelo novo suporte de auth-requirements em Granite expõe os caminhos de login, conforme definido pelas granite:loginPath propriedades, que, por sua vez, são definidos pelo tipo de combinação, conforme descrito acima. O mapeamento do caminho do recurso que contém o caminho de logon e o próprio valor da propriedade é mantido na memória e será avaliado para encontrar um caminho de logon adequado para outros nós na hierarquia.
A avaliação só é executada para solicitações associadas a recursos localizados nos caminhos suportados configurados. Para quaisquer outras solicitações, as formas alternativas de determinar o caminho de logon serão avaliadas.

Práticas recomendadas

Ao definir os requisitos de autenticação, devem ser tidas em conta as seguintes práticas recomendadas:
  • Evite aninhar os requisitos de autenticação: colocar um único marcador de requisito de autenticação no início de uma árvore deve ser suficiente e é herdado para toda a subárvore definida pelo nó de destino. Os requisitos de autenticação adicionais dentro dessa árvore devem ser considerados redundantes e podem levar a problemas de desempenho ao avaliar o requisito de autenticação dentro do Apache Sling. Com a separação das áreas de autorização e autenticação relacionadas ao CUG, é possível restringir o acesso de leitura por meio do CUG ou de outro tipo de políticas, além de impor a autenticação para toda a árvore.
  • Modelo do conteúdo do repositório de modo que os requisitos de autenticação se apliquem a toda a árvore sem a necessidade de excluir as subárvores aninhadas do requisito novamente.
  • Para evitar especificar e, posteriormente, registrar caminhos de logon redundantes:
    • depender da herança e evitar definir caminhos de logon aninhados,
    • não defina o caminho de logon opcional para um valor que corresponda ao valor padrão ou herdado,
    • os desenvolvedores do aplicativo devem identificar quais caminhos de logon devem ser configurados nas configurações globais de caminho de login (padrão e mapeamentos) associadas ao LoginSelectorHandler .

Representação no repositório

Representação de política CUG no repositório

A documentação do Oak cobre como as novas políticas de CUG são refletidas no conteúdo do repositório. Para obter mais informações, consulte esta página .

Requisito de autenticação no repositório

A necessidade de um requisito de autenticação separado é refletida no conteúdo do repositório com um tipo de nó de mixagem dedicado colocado no nó de destino. O tipo de mixin define uma propriedade opcional para especificar uma página de logon dedicada para a árvore definida pelo nó de destino.
A página associada ao caminho de logon pode estar localizada dentro ou fora dessa árvore. Será excluído do requisito de autenticação.
[granite:AuthenticationRequired]
      mixin
      - granite:loginPath (STRING)

Gerenciando políticas e requisitos de autenticação do CUG

Gerenciando Políticas de CUG

O novo tipo de políticas de controle de acesso para restringir o acesso de leitura para um CUG é gerenciado usando a API de gerenciamento de controle de acesso do JCR e segue os mecanismos descritos com a especificação do JCR 2.0.

Definir uma nova política de CUG

Código para aplicar uma nova política CUG em um nó que não tinha um CUG definido antes. Observe que só getApplicablePolicies retornará novas políticas que não foram definidas antes. No final, a política precisa de ser reformulada e as mudanças precisam de ser mantidas.
String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

AccessControlPolicyIterator it = acMgr.getApplicablePolicies(path);
while (it.hasNext()) {
        AccessControlPolicy policy = it.nextAccessControlPolicy();
        if (policy instanceof PrincipalSetPolicy) {
           cugPolicy = (PrincipalSetPolicy) policy;
           break;
        }
}

if (cugPolicy == null) {
   log.debug("no applicable policy"); // path not supported or no applicable policy (e.g.
                                                   // the policy was set before)
   return;
}

cugPolicy.addPrincipals(toAdd1, toAdd2);
cugPolicy.removePrincipals(toRemove));

acMgr.setPolicy(path, cugPolicy); // as of this step the policy can be edited/removed
session.save();

Editar uma política de CUG existente

As etapas a seguir são necessárias para editar uma política de CUG existente. Observe que a política modificada precisa ser retornada e as alterações precisam ser mantidas usando javax.jcr.Session.save() .
String path = [...] // needs to be a supported, absolute path

Principal toAdd1 = [...]
Principal toAdd2 = [...]
Principal toRemove = [...]

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
     if (policy instanceof PrincipalSetPolicy) {
        cugPolicy = (PrincipalSetPolicy) policy;
        break;
     }
}

if (cugPolicy == null) {
   log.debug("no policy to edit"); // path not supported or policy not set before
   return;
}

if (cugPolicy.addPrincipals(toAdd1, toAdd2) || cugPolicy.removePrincipals(toRemove)) {
   acMgr.setPolicy(path, cugPolicy);
   session.save();
} else {
     log.debug("cug policy not modified");
}

Recuperar Políticas de CUG Efetivas

O gerenciamento de controle de acesso JCR define um método de melhor esforço para recuperar as políticas que entram em vigor em um determinado caminho. Devido ao fato de que a avaliação das políticas CUG é condicional e depende da configuração correspondente para ser ativada, chamar getEffectivePolicies é uma maneira conveniente de verificar se determinada política CUG está sendo aplicada em uma determinada instalação.
Observe a diferença entre getEffectivePolicies o exemplo de código subsequente e o exemplo de código subsequente que apresenta a hierarquia para descobrir se um determinado caminho já faz parte de um CUG existente.
String path = [...] // needs to be a supported, absolute path

AccessControlManager acMgr = session.getAccessControlManager();
PrincipalSetPolicy cugPolicy = null;

// log an debug message of all CUG policies that take effect at the given path
// there could be zero, one or many (creating nested CUGs is possible)
for (AccessControlPolicy policy : acMgr.getEffectivePolicies(path) {
     if (policy instanceof PrincipalSetPolicy) {
        String policyPath = "-";
        if (policy instanceof JackrabbitAccessControlPolicy) {
           policyPath = ((JackrabbitAccessControlPolicy) policy).getPath();
        }
        log.debug("Found effective CUG for path '{}' at '{}', path, policyPath);
     }
}

Recuperar Políticas de CUG Herdadas

Encontrar todos os CUGs aninhados que foram definidos em um determinado caminho independentemente de terem ou não efeito. Para obter mais informações, consulte a seção Opções de configuração.
String path = [...]

List<AccessControlPolicy> cugPolicies = new ArrayList<AccessControlPolicy>();
while (isSupportedPath(path)) {
     for (AccessControlPolicy policy : acMgr.getPolicies(path)) {
         if (policy instanceof PrincipalSetPolicy) {
            cugPolicies.add(policy);
         }
      }
      path = (PathUtils.denotesRoot(path)) ? null : PathUtils.getAncestorPath(path, 1);
}

Gerenciamento de políticas de CUG por princípio

As extensões definidas por JackrabbitAccessControlManager aquela que permite editar as políticas de controle de acesso por principal não são implementadas com o gerenciamento de controle de acesso CUG, já que por definição uma política CUG sempre afeta todos os principais: os listados com o PrincipalSetPolicy estão recebendo acesso de leitura, enquanto todos os outros principais serão impedidos de ler o conteúdo na árvore definida pelo nó de destino.
Os métodos correspondentes sempre retornam uma matriz de política vazia, mas não lançam exceções.

Gerenciamento do requisito de autenticação

A criação, modificação ou remoção de novos requisitos de autenticação é alcançada pela alteração do tipo de nó efetivo do nó de destino. A propriedade opcional de caminho de login pode ser gravada usando a API JCR comum.
As modificações em um determinado nó de destino mencionado acima só serão refletidas no Autenticador Sling do Apache se o objeto RequirementHandler tiver sido configurado e o destino estiver contido nas árvores definidas pelos caminhos suportados (consulte as Opções de configuração da seção).
Para obter mais informações, consulte #de nós mistos (https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.10.3 Atribuição de tipos de nós mistos) e #(https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.4 adição de nós e configuração de propriedades)

Adicionando um novo requisito de autenticação

As etapas para criar um novo requisito de autenticação estão detalhadas abaixo. Observe que o requisito só será registrado com o Autenticador Apache Sling se o RequirementHandler tiver sido configurado para a árvore que contém o nó de destino.
Node targetNode = [...]

targetNode.addMixin("granite:AuthenticationRequired");
session.save();

Adicionar um novo requisito de autenticação com caminho de logon

Etapas para criar um novo requisito de autenticação incluindo um caminho de logon. Observe que o requisito e a exclusão do caminho de logon só serão registrados com o Autenticador Apache Sling se o RequirementHandler tiver sido configurado para a árvore que contém o nó de destino.
Node targetNode = [...]
String loginPath = [...] // STRING property

Node targetNode = session.getNode(path);
targetNode.addMixin("granite:AuthenticationRequired");

targetNode.setProperty("granite:loginPath", loginPath);
session.save();

Modificar um caminho de logon existente

As etapas para alterar um caminho de login existente estão detalhadas abaixo. A modificação só será registrada com o Autenticador Sling do Apache se o RequirementHandler tiver sido configurado para a árvore que contém o nó de destino. O valor do caminho de login anterior será removido do registro. O requisito de autenticação associado ao nó de destino não é afetado por essa modificação.
Node targetNode = [...]
String newLoginPath = [...] // STRING property

if (targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", newLoginPath);
   session.save();
} else {
     log.debug("cannot modify login path property; mixin type missing");
}

Remover um caminho de logon existente

Etapas para remover um caminho de logon existente. A entrada do caminho de logon só será cancelada do Autenticador Apache Sling se o RequirementHandler tiver sido configurado para a árvore que contém o nó de destino. O requisito de autenticação associado ao nó de destino não é afetado.
Node targetNode = [...]

if (targetNode.hasProperty("granite:loginPath") &&
   targetNode.isNodeType("granite:AuthenticationRequired")) {
   targetNode.setProperty("granite:loginPath", null);
   session.save();
} else {
     log.debug("cannot remove login path property; mixin type missing");
}

Ou, você pode usar o método abaixo para atingir o mesmo objetivo:
String path = [...] // absolute path to target node

String propertyPath = PathUtils.concat(path, "granite:loginPath");
if (session.propertyExists(propertyPath)) {
    session.getProperty(propertyPath).remove();
    // or: session.removeItem(propertyPath);
    session.save();
}

Remover um requisito de autenticação

Etapas para remover um requisito de autenticação existente. O requisito só será cancelado do Autenticador Apache Sling se o RequirementHandler tiver sido configurado para a árvore que contém o nó de destino.
Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");

session.save();

Recuperar requisitos de autenticação efetivos

Não há API pública dedicada para ler todos os requisitos de autenticação efetiva, conforme registrado no Autenticador Sling do Apache. No entanto, a lista é exposta no console do sistema https://<serveraddress>:<serverport>/system/console/slingauth na seção "Configuração do requisito de autenticação".
A imagem a seguir mostra os requisitos de autenticação de uma instância de publicação do AEM com conteúdo de demonstração. O caminho destacado da página da comunidade ilustra como um requisito adicionado pela implementação descrita neste documento é refletido no Autenticador Apache Sling.
Neste exemplo, a propriedade de caminho de login opcional não foi definida. Consequentemente, não foi registrada nenhuma segunda entrada no autenticador.

Recuperar o caminho de logon efetivo

Atualmente, não há API pública para recuperar o caminho de logon que entrará em vigor ao acessar anonimamente um recurso que requer autenticação. Consulte a seção Avaliação do caminho de logon para obter detalhes sobre a implementação de como o caminho de logon é recuperado.
Entretanto, observe que, além dos caminhos de logon definidos com esse recurso, há maneiras alternativas de especificar o redirecionamento para o logon, que devem ser consideradas ao projetar o modelo de conteúdo e os requisitos de autenticação de uma determinada instalação do AEM.

Recuperar o requisito de autenticação herdado

Como no caminho de logon, não há uma API pública para recuperar os requisitos de autenticação herdados definidos no conteúdo. A amostra a seguir ilustra como listar todos os requisitos de autenticação que foram definidos com uma hierarquia específica independentemente de terem ou não efeito. Para obter mais informações, consulte Opções Configuration Options de configuração.
É recomendável confiar no mecanismo de herança tanto para os requisitos de autenticação quanto para o caminho de logon e evitar a criação de requisitos de autenticação aninhados.
Para obter mais informações, consulte Avaliação e herança do requisito de autenticação, Avaliação do caminho de logon e práticas Práticas recomendadas recomendadas.
String path = [...]
Node node = session.getNode(path);

Map<String, String> authRequirements = new ArrayList<String, String>();
while (isSupported(node)) {
     if (node.isNodeType("granite:AuthenticationRequired")) {
         String loginPath = (node.hasProperty("granite:loginPath") ?
                                     node.getProperty("granite:loginPath").getString() :
                                     "";
        authRequirements.put(node.getPath(), loginPath);
        node = node.getParent();
     }
}

Combinando políticas CUG e o requisito de autenticação

A tabela a seguir lista as combinações válidas de políticas CUG e o requisito de autenticação em uma instância do AEM que tem ambos os módulos habilitados pela configuração.
Autenticação necessária
Caminho de login
Acesso de leitura restrito
Efeito esperado
Sim
Sim
Sim
Um determinado usuário só poderá exibir a subárvore marcada com a política CUG se uma avaliação de permissão efetiva conceder acesso. Um usuário não autenticado será redirecionado para a página de logon especificada.
Sim
Não
Sim
Um determinado usuário só poderá exibir a subárvore marcada com a política CUG se uma avaliação de permissão efetiva conceder acesso. Um usuário não autenticado será redirecionado para uma página de logon padrão herdada.
Sim
Sim
Não
Um usuário não autenticado será redirecionado para a página de logon especificada. Se é permitido ou não exibir a árvore marcada com o requisito de autenticação depende das permissões efetivas dos itens individuais contidos nessa subárvore. Nenhum CUG dedicado restringindo o acesso de leitura no local.
Sim
Não
Não
Um usuário não autenticado será redirecionado para uma página de logon padrão herdada. Se é permitido ou não exibir a árvore marcada com o requisito de autenticação depende das permissões efetivas dos itens individuais contidos nessa subárvore. Nenhum CUG dedicado restringindo o acesso de leitura no local.
Não
Não
Sim
Um determinado usuário autenticado ou não autenticado só poderá exibir a subárvore marcada com a política CUG se uma avaliação de permissão efetiva conceder acesso. Um usuário não autenticado será tratado igualmente e não será redirecionado para logon.
A combinação de 'Requisito de autenticação' = Não e 'Caminho de logon' = Sim não está listada acima, pois 'Caminho de logon' é um atributo opcional associado a um Requisito de autenticação. A especificação de uma propriedade JCR com esse nome sem adicionar o tipo de combinação de definição não terá efeito e será ignorada pelo manipulador correspondente.

Componentes e configuração do OSGi

Esta seção fornece uma visão geral dos componentes do OSGi e das opções de configuração individuais introduzidas com a nova implementação do CUG.
Consulte também a documentação de mapeamento CUG para obter um mapeamento abrangente das opções de configuração entre a implementação antiga e a nova.

Autorização: Configuração e configuração

As novas partes relacionadas à autorização estão contidas no pacote de autorização Oak CUG ( org.apache.jackrabbit.oak-authorization-cug ), que faz parte da instalação padrão do AEM. O pacote define um modelo de autorização separado que deve ser implantado como uma forma adicional de gerenciar o acesso de leitura.

Configurando a Autorização de CUG

A configuração da autorização CUG é descrita em detalhe na Documentação Apache relevante. Por padrão, o AEM tem autorização CUG implantada em todos os modos de execução. As instruções passo a passo também podem ser usadas para desativar a autorização de CUG nas instalações que exigem uma configuração de autorização diferente.

Configuração do filtro do referenciador

Você também precisa configurar o Filtro do Referenciador de Sling com todos os nomes de host que podem ser usados para acessar o AEM; por exemplo, por meio de CDN, Balanceador de Carga e qualquer outro.
Se o filtro do referenciador não estiver configurado, serão observados erros, semelhantes aos seguintes, quando um usuário tentar fazer logon em um site CUG:
31.01.2017 13:49:42.321 *INFO* [qtp1263731568-346] org.apache.sling.security.impl.ReferrerFilter Rejected referrer header for POST request to /libs/granite/core/content/login.html/j_security_check : https://hostname/libs/granite/core/content/login.html?resource=%2Fcontent%2Fgeometrixx%2Fen%2Ftest-site%2Ftest-page.html&$$login$$=%24%24login%24%24&j_reason=unknown&j_reason_code=unknown

Características dos componentes OSGi

Os dois componentes OSGi a seguir foram introduzidos para definir os requisitos de autenticação e especificar caminhos de logon dedicados:
  • org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugConfiguration
  • org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.CugExcludeImpl
org.apache.Jackrabbit.oak.spi.security.license.impl.CugConfiguration
Etiqueta Configuração do Apache Jackrabbit Oak CUG
Descrição Configuração de autorização dedicada à configuração e avaliação de permissões de CUG.
Propriedades de configuração
  • cugSupportedPaths
  • cugEnabled
  • configurationRanking
Além disso, consulte Opções #configuration-options de configuração abaixo.
Política de configuração ConfigurationPolicy.REQUIRE
Referências CugExclude (ReferenceCardinality.OPTIONAL_UNARY)
org.apache.Jackrabbit.oak.spi.security.license.impl.CugExcludeImpl
Etiqueta Lista de exclusões do Apache Jackrabbit Oak CUG
Descrição Permite excluir o(s) principal(s) com os nomes configurados da avaliação CUG.
Propriedades de configuração
  • principalNames
Consulte também a seção Opções de configuração abaixo.
Política de configuração ConfigurationPolicy.REQUIRE
Referências ND

Configuration Options

As principais opções de configuração são:
  • cugSupportedPaths : especificar as subárvores que podem conter CUGs. Nenhum valor padrão está definido
  • cugEnabled : opção de configuração para ativar a avaliação de permissão para as políticas atuais de CUG.
As opções de configuração disponíveis associadas ao módulo de autorização CUG são listadas e descritas com mais detalhes na Documentação do Apache Oak.

Excluindo Principais da Avaliação de CUG

Foi adotada a isenção dos principais individuais da avaliação da CUG da execução anterior. A nova autorização do CUG cobre isso com uma interface exclusiva chamada CugExclude. O Apache Jackrabbit Oak 1.4 é enviado com uma implementação padrão que exclui um conjunto fixo de principais, bem como uma implementação estendida que permite configurar nomes de principais individuais. O último está configurado nas instâncias de publicação do AEM.
O padrão, pois o AEM 6.3, impede que os seguintes principais sejam afetados pelas políticas de CUG:
  • principais administrativos (usuário administrador, grupo de administradores)
  • principais de usuários de serviços
  • principal do sistema interno do repositório
Para obter mais informações, consulte a tabela na seção Configuração padrão desde o AEM 6.3 abaixo.
A exclusão do grupo 'administradores' pode ser alterada ou expandida no console do sistema na seção de configuração da lista de exclusões do Apache Jackrabbit Oak CUG.
Como alternativa, é possível fornecer e implantar uma implementação personalizada da interface CugExclude para ajustar o conjunto de principais excluídos em caso de necessidades especiais. Consulte a documentação sobre a capacidade de CUG para obter detalhes e obter um exemplo de implementação.

Autenticação: Configuração e configuração

As novas peças relacionadas à autenticação estão contidas no pacote do Adobe Granite Authentication Handler ( com.adobe.granite.auth.authhandler versão 5.6.48). Esse pacote faz parte da instalação padrão do AEM.
Para configurar a substituição do requisito de autenticação para o suporte obsoleto ao CUG, alguns componentes do OSGi devem estar presentes e ativos em uma determinada instalação do AEM. Para obter mais detalhes, consulte Características dos componentes OSGi abaixo.
Devido à opção de configuração obrigatória com o RequirementsHandler, as partes relacionadas à autenticação só estarão ativas se o recurso tiver sido ativado especificando um conjunto de caminhos suportados. Com uma instalação padrão do AEM, o recurso é desativado no modo de execução do autor e ativado para /content no modo de execução de publicação.
Características dos componentes OSGi
Os dois componentes OSGi a seguir foram introduzidos para definir os requisitos de autenticação e especificar caminhos de logon dedicados:
  • com.adobe.granite.auth.requirement.impl.RequirementService
  • com.adobe.granite.auth.requirement.impl.DefaultRequirementHandler
com.adobe.granite.auth.requirements.impl.RequirementsService
Etiqueta -
Descrição O serviço OSGi dedicado para requisitos de autenticação que registram um observador para alterações de conteúdo que afetam os requisitos de autenticação (por meio do tipo de granite:AuthenticationRequirement mistura) e caminhos de logon com são expostos ao LoginSelectorHandler .
Propriedades de configuração -
Política de configuração ConfigurationPolicy.OPTIONAL
Referências
  • RequirementHandler (ReferenceCardinality.MANDATORY_UNARY)
  • Executor (ReferenceCardinality.MANDATORY_UNARY)
com.adobe.granite.auth.requirements.impl.DefaultRequirementsHandler
Etiqueta
Requisitos de autenticação do Adobe Granite e manipulador de caminho de logon
Descrição
RequirementHandler implementação que atualiza os requisitos de autenticação do Apache Sling e a exclusão correspondente para os caminhos de logon associados.
Propriedades de configuração
supportedPaths
Política de configuração
ConfigurationPolicy.REQUIRE
Referências
ND

Configuration Options

As partes relacionadas à autenticação da regravação de CUG só vêm com uma única opção de configuração associada ao requisito de autenticação do Adobe Granite e ao manipulador de caminho de logon:
"Requisito de autenticação e manipulador de caminho de logon"
Propriedade Tipo Valor padrão Descrição
Rótulo = Caminhos suportados
Nome = 'supportedPaths'
Set<String> - Caminhos sob os quais os requisitos de autenticação serão respeitados por este manipulador. Deixe essa configuração desdefinida se desejar adicionar o tipo de granite:AuthenticationRequirement combinação aos nós sem que eles sejam aplicados (por exemplo, em instâncias do autor). Se estiver ausente, o recurso será desativado.

Configuração padrão desde o AEM 6.3

Por padrão, novas instalações do AEM usarão as novas implementações tanto para as partes relacionadas à autorização quanto à autenticação do recurso CUG. A implementação antiga "Suporte a CUG (Adobe Granite Closed User Group)" foi substituída e será desativada em todas as instalações do AEM por padrão. As novas implementações serão ativadas da seguinte maneira:

Instâncias do autor

"Configuração Apache Jackrabbit Oak CUG"
Explicação
Caminhos suportados /content
O gerenciamento de controle de acesso para políticas CUG está habilitado.
FALSE Ativada para Avaliação de CUG
A avaliação de permissão está desativada. As políticas de CUG não têm efeito.
Classificação
200
Nenhuma configuração para Apache Jackrabbit Oak CUG Excluir Lista e Requisito de Autenticação do Adobe Granite e Manipulador de Caminho de Login está presente nas instâncias de criação padrão.

Instâncias de publicação

"Configuração Apache Jackrabbit Oak CUG"
Explicação
Caminhos suportados /content
O gerenciamento de controle de acesso para políticas CUG está habilitado abaixo dos caminhos configurados.
Avaliação de CUG ativada TRUE
A avaliação de permissão está ativada abaixo dos caminhos configurados. As políticas de CUG entram em vigor no momento Session.save() .
Classificação
200
"Apache Jackrabbit Oak CUG Excluir Lista"
Explicação
Administradores de nomes principais
Exclui o principal administrador da avaliação CUG.
"Requisitos de autenticação do Adobe Granite e manipulador de caminho de logon"
Explicação
Caminhos suportados /content
Os requisitos de autenticação definidos no repositório por meio do tipo de granite:AuthenticationRequired mistura entram em vigor abaixo /content sobre Session.save() . O Sling Authenticator é atualizado. A adição do tipo de mistura fora dos caminhos suportados é ignorada.

Desabilitando o requisito de autorização e autenticação do CUG

A nova implementação pode ser desabilitada no caso de uma determinada instalação não utilizar CUGs ou usar meios diferentes para autenticação e autorização.

Desativar Autorização CUG

Consulte a documentação do plug-in CUG para obter detalhes sobre como remover o modelo de autorização CUG da configuração de autorização composta.

Desative o requisito de autenticação

Para desativar o suporte para o requisito de autenticação fornecido pelo granite.auth.authhandler módulo, basta remover a configuração associada ao requisito de autenticação do Adobe Granite e ao manipulador de caminho de logon.
Entretanto, observe que a remoção da configuração não cancelará o registro do tipo de mixina, que ainda era aplicável aos nós sem ter efeito.

Interação com outros módulos

API Apache Jackrabbit

Para alterar o novo tipo de política de controle de acesso usada pelo modelo de autorização CUG, a API definida pelo Apache Jackrabbit foi estendida. Desde a versão 2.11.0 do jackrabbit-api módulo que define uma nova interface chamada org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy , que se estende de javax.jcr.security.AccessControlPolicy .

Arquivo Apache Jackrabbit

O mecanismo de importação do Apache Jackrabbit FileVault foi ajustado para lidar com políticas de controle de acesso de tipo PrincipalSetPolicy .

Distribuição de conteúdo do Apache Sling

Consulte a seção Apache Jackrabbit FileVault acima.

Adobe Granite Replication

O módulo de replicação foi ligeiramente ajustado para poder replicar as políticas de CUG entre diferentes instâncias do AEM:
  • DurboImportConfiguration.isImportAcl() é interpretada literalmente e afetará somente as políticas de controle de acesso que implementam javax.jcr.security.AccessControlList
  • DurboImportTransformer respeitará somente esta configuração para ACLs verdadeiras
  • Outras políticas, como org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy instâncias criadas pelo modelo de autorização CUG, sempre serão replicadas e a opção de configuração DurboImportConfiguration.isImportAcl () será ignorada.
Há uma limitação da replicação das políticas de CUG. Se uma determinada política CUG for removida sem remover o tipo de nó de mixagem correspondente, rep:CugMixin, a remoção não será refletida na replicação. Isso foi resolvido removendo sempre a combinação após a remoção da política. A limitação pode, no entanto, aparecer se o tipo de mistura for adicionado manualmente.

Adobe Granite Authentication Handler

O manipulador de autenticação Adobe Granite HTTP Header Authentication Handler fornecido com o com.adobe.granite.auth.authhandler conjunto contém uma referência à CugSupport interface definida pelo mesmo módulo. É usado para calcular o 'realm' em determinadas circunstâncias, voltando para o realm configurado com o manipulador.
Isso foi ajustado para tornar a referência opcional a fim de garantir a compatibilidade retroativa máxima se uma determinada configuração decidir reativar a implementação obsoleta. CugSupport As instalações que usam a implementação não serão mais extraídas do realm da implementação CUG, mas sempre exibirão o realm conforme definido com o Adobe Granite HTTP Header Authentication Handler .
Por padrão, o Adobe Granite HTTP Header Authentication Handler só está configurado no modo de execução de publicação com a opção "Desativar página de logon" ( auth.http.nologin ) ativada.

AEM LiveCopy

A configuração de CUGs em conjunto com o LiveCopy é representada no repositório pela adição de um nó extra e de uma propriedade extra, da seguinte forma:
  • /content/we-retail/us/en/blueprint/rep:cugPolicy
  • /content/we-retail/us/en/LiveCopy@granite:loginPath
Ambos os elementos são criados sob o cq:Page . Com o design atual, o MSM trata somente dos nós e propriedades que estão sob o nó cq:PageContent ( jcr:content ).
Portanto, os grupos CUG não podem ser revertidos de um blueprint para um Live Copy. Planeje adequadamente isso ao configurar uma Live Copy.

Alterações na nova implementação do CUG

O objetivo desta seção é fornecer uma panorâmica das alterações introduzidas na característica CUG, bem como uma comparação entre a antiga e a nova implementação. Ele lista as alterações que afetam a forma como o suporte a CUG é configurado e descreve como e por quem os CUGs são gerenciados no conteúdo do repositório.

Diferenças na configuração e configuração do CUG

O componente obsoleto do OSGi Adobe Granite Closed User Group (CUG) Support ( com.day.cq.auth.impl.cug.CugSupportImpl ) foi substituído por novos componentes para poder manipular separadamente as partes relacionadas à autorização e autenticação da antiga funcionalidade CUG.

Diferenças no gerenciamento de CUGs no conteúdo do repositório

As seções a seguir descrevem as diferenças entre as novas implementações e as antigas, do ponto de vista da implementação e da segurança. Embora a nova implementação tenha como objetivo fornecer a mesma funcionalidade, há alterações sutis que são importantes ao usar o novo CUG.

Diferenças No Que Respeita À Autorização

As principais diferenças do ponto de vista da autorização são resumidas na lista seguinte:
Conteúdo dedicado de controle de acesso para CUGs
Na implementação antiga, o modelo de autorização padrão era usado para manipular as políticas de lista de controle de acesso na publicação, substituindo quaisquer ACEs existentes pela configuração exigida pelo CUG. Isso foi acionado ao escrever propriedades do JCR regulares e residuais que foram interpretadas ao publicar.
Com a nova implementação, a configuração do controle de acesso do modelo de autorização padrão não é afetada por nenhum CUG que esteja sendo criado, modificado ou removido. Em vez disso, um novo tipo de política chamada PrincipalSetPolicy é aplicado como conteúdo de controle de acesso adicional ao nó de destino. Essa política adicional será localizada como um filho do nó de destino e seria um irmão do nó de política padrão, se presente.
Editando Políticas CUG No Gerenciamento De Controle De Acesso
Essa mudança das propriedades residuais do JCR para uma política de controle de acesso dedicada tem impacto na permissão necessária para criar ou modificar a parte de autorização do recurso CUG. Como isso é considerado uma modificação para acessar o conteúdo de controle, ele requer jcr:readAccessControl e jcr:modifyAccessControl privilégios para ser gravado no repositório. Portanto, somente os autores de conteúdo autorizados a modificar o conteúdo de controle de acesso de uma página podem configurar ou modificar esse conteúdo. Isso contrasta com a implementação antiga, na qual a capacidade de gravar propriedades JCR regulares era suficiente, resultando em um escalonamento de privilégio.
Nó de destino definido pela política
Espera-se que as políticas de CUG sejam criadas no nó JCR que define a subárvore a ser sujeita a acesso de leitura restrito. Essa provavelmente será uma página do AEM caso o CUG afete a árvore inteira.
Observe que colocar a política CUG somente no nó jcr:content localizado abaixo de uma determinada página restringirá o acesso ao conteúdo s.str de uma determinada página, mas não entrará em vigor em quaisquer páginas semelhantes ou secundárias. Esse pode ser um caso de uso válido e é possível obtê-lo com um editor de repositório que permite aplicar conteúdo de conteúdo de acesso aprimorado. No entanto, contrasta a implementação anterior, onde colocar uma propriedade cq:cugEnabled no nó jcr:content foi mapeada internamente para o nó da página. Esse mapeamento não é mais executado.
Avaliação de Permissão com Políticas de CUG
Mudar do suporte antigo a CUG para um modelo de autorização adicional altera a forma como as permissões de leitura eficazes são avaliadas. Conforme descrito na documentação do Jackrabbit, um determinado principal autorizado a exibir o CUGcontent terá acesso de leitura somente se a avaliação de permissão de todos os modelos configurados no repositório Oak conceder acesso de leitura.
Em outras palavras, para a avaliação das permissões efetivas, as entradas de controle de acesso CUGPolicy e padrão serão consideradas e o acesso de leitura no conteúdo CUG só será concedido se for concedido por ambos os tipos de políticas. Em uma instalação de publicação padrão do AEM, na qual o acesso de leitura à árvore completa é concedido a todos, o efeito das políticas CUG será o mesmo da implementação antiga. /content
Avaliação sob demanda
O modelo de autorização CUG permite ativar individualmente o gerenciamento do controle de acesso e a avaliação de permissões:
  • o gerenciamento do controle de acesso será ativado se o módulo tiver um ou vários caminhos suportados nos quais os CUGs possam ser criados
  • a avaliação de permissão só será ativada se a opção Avaliação CUG Ativada estiver marcada adicionalmente.
Na nova avaliação de configuração padrão do AEM das políticas CUG, ela só é ativada com o modo de execução "publicar". Consulte os detalhes sobre a configuração padrão desde o AEM 6.3 para obter mais detalhes. Isso pode ser verificado comparando as políticas eficazes de um determinado caminho com as políticas armazenadas no conteúdo. As políticas eficazes só serão exibidas se a avaliação de permissão para CUGs estiver ativada.
Como explicado acima, as políticas de controle de acesso CUG agora são sempre armazenadas no conteúdo, mas a avaliação das permissões efetivas resultantes dessas políticas só será aplicada se a Avaliação CUG Ativada estiver ativada no console do sistema na Configuração CUG Apache Jackrabbit Oak. Por padrão, ele é ativado somente com o modo de execução "publicar".

Diferenças No Que Diz Respeito À Autenticação

As diferenças em relação à autenticação são descritas abaixo.

Tipo de mistura dedicado para requisito de autenticação

Na primeira implementação, tanto os aspectos de autorização como de autenticação de um CUG foram acionados por uma única propriedade do JCR ( cq:cugEnabled ). No que diz respeito à autenticação, isso resultou em uma lista atualizada de requisitos de autenticação, conforme armazenados com a implementação do Autenticador Apache Sling. Com a nova implementação, o mesmo resultado é obtido marcando o nó de destino com um tipo de combinação dedicado ( granite:AuthenticationRequired ).

Propriedade Para Excluir Caminho De Logon

O tipo de mixin define uma única propriedade opcional chamada granite:loginPath , que corresponde basicamente à cq:cugLoginPage propriedade. Em contraste com a implementação anterior, a propriedade de caminho de logon só será respeitada se o tipo de nó declarativo for a combinação mencionada. A adição de uma propriedade com esse nome sem definir o tipo de mixin não terá efeito e nem um novo requisito nem uma exclusão para o caminho de login serão reportados ao autenticador.

Privilégio Para Requisito De Autenticação

A adição ou remoção de um tipo de combinação requer jcr:nodeTypeManagement a concessão de privilégio. Na implementação anterior, o privilégio jcr:modifyProperties é usado para editar a propriedade residual.
No que granite:loginPath se refere à propriedade, é necessário o mesmo privilégio para a adição, modificação ou remoção da propriedade.

Nó de destino definido por tipo de combinação

Espera-se que os requisitos de autenticação sejam criados no nó JCR que define a subárvore a ser sujeita ao logon forçado. Isso provavelmente será uma página AEM caso o CUG afete a árvore inteira e a interface do usuário para a nova implementação, consequentemente, adicionará o tipo de combinação de requisito de autenticação no nó da página.
Colocar a política CUG somente no nó jcr:content localizado abaixo de uma determinada página restringirá o acesso ao conteúdo, mas não afetará o nó da página nem as páginas secundárias.
Esse pode ser um cenário válido e é possível com um editor de repositório que permite colocar o mixin em qualquer nó. No entanto, o comportamento contrasta com a implementação anterior, onde colocar uma propriedade cq:cugEnabled ou cq:cugLoginPage no nó jcr:content foi remapeada internamente no nó da página. Esse mapeamento não é mais executado.

Caminhos suportados configurados

O tipo de granite:AuthenticationRequired mixin e a propriedade granite:loginPath só serão respeitados dentro do escopo definido pelo conjunto de opções de configuração Caminhos suportados presentes com o Requisito de autenticação do Adobe Granite e o Manipulador de caminho de logon. Se nenhum caminho for especificado, o recurso de requisito de autenticação será desabilitado completamente. Nesse caso, o tipo de combinação e a propriedade não têm efeito ao serem adicionados ou definidos para um determinado nó JCR.

Mapeamento de conteúdo JCR, serviços e configurações OSGi

O documento abaixo fornece um mapeamento abrangente dos serviços OSGi, configurações e conteúdo do repositório entre a implementação antiga e a nova.
Mapeamento de CUG desde o AEM 6.3

Atualizar CUG

Instalações existentes usando o CUG obsoleto

A antiga implementação de suporte do CUG foi substituída e será removida para versões futuras. É recomendável passar para as novas implementações ao atualizar de versões anteriores ao AEM 6.3.
Para a instalação do AEM atualizada, é importante garantir que somente uma implementação do CUG esteja ativada. A combinação do suporte novo e antigo e obsoleto ao CUG não é testada e provavelmente causa comportamento indesejado:
  • colisões no Autenticador Sling no que diz respeito aos requisitos de autenticação
  • negado o acesso de leitura quando a configuração de ACL associada ao CUG antigo entra em conflito com uma nova política de CUG.

Migração de conteúdo atual do CUG

A Adobe fornece uma ferramenta para migrar para a nova implementação do CUG. Para usá-lo, execute as seguintes etapas:
  1. Vá até https://<serveraddress>:<serverport>/system/console/cug-migration para acessar a ferramenta.
  2. Digite o caminho raiz para o qual deseja verificar os CUGs e pressione o botão Executar execução seca. Isso verificará os CUGs elegíveis para conversão no local selecionado.
  3. Depois de revisar os resultados, pressione o botão Executar migração para migrar para a nova implementação.
Se você encontrar problemas, será possível configurar um registrador específico no nível DEBUG para obter com.day.cq.auth.impl.cug a saída da ferramenta de migração. Consulte Registro para obter mais informações sobre como fazer isso.