Desde a 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:
Um CUG, como é conhecido no contexto do AEM, consiste nas seguintes etapas:
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 estão listados na seção Combinando políticas CUG e o requisito de autenticação.
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 padrão do controle de acesso imediatamente, a nova implementação adota uma abordagem diferente definindo um tipo dedicado de política de controles de acesso que representa um CUG.
Este novo tipo de política tem as seguintes características:
A implementação de PrincipalSetPolicy usada para representar CUGs além disso define que:
Essas políticas de CUG são implantadas em uma instância AEM por meio de um módulo de autorização separado, chamado de marcação de autorização de carvalho. Este módulo vem com seu próprio gerenciamento de controles de acesso e avaliação de permissões. Em outras palavras, a configuração de AEM padrão 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 existente do controle de acesso anexado ao nó do público alvo, 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 do 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 do controle de acesso. Isso implica que eles sejam criados e editados usando a API de gerenciamento de controles de acesso JCR. Para obter mais informações, consulte a seção Gerenciando Políticas de CUG.
Além de um gerenciamento de controles de acesso dedicado para CUGs, o novo modelo de autorização permite condicionalmente habilitar a avaliação de permissões para suas políticas. Isso permite configurar políticas CUG em um ambiente de preparo e ativar somente a avaliação das permissões efetivas depois de replicadas para o 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:
O efeito de uma única política de CUG na avaliação das permissões pode resumir-se do seguinte modo:
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:
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 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.
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 impor 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 registro sling.auth.requirements
. Essas propriedades são então usadas para estender dinamicamente os requisitos de autenticação. Para obter mais detalhes, consulte a documentação Sling.
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 única propriedade opcional do tipo STRING para o caminho de logon 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 chamada javax.jcr.Session.save()
para se tornar efetiva.
O mesmo se aplica à propriedade granite:loginPath
. 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 Avaliação do caminho de logon abaixo.
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 mixin quanto a propriedade serão ignorados.
A configuração de AEM padrão agora utiliza essa configuração permitindo definir a mixin no modo de execução do autor, mas só terá efeito 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 mistura granite:AuthenticationRequired
nos caminhos suportados configurados fará com que o registro OSGi do manipulador responsável seja atualizado com uma nova entrada adicional com a propriedade sling.auth.requirements
. Se um determinado requisito de autenticação especificar a propriedade opcional granite:loginPath
, o valor será registrado adicionalmente com o Autenticador com um prefixo '-' para ser excluído 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 próprios 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.
A avaliação do caminho de login e o redirecionamento para o recurso correspondente na autenticação é atualmente um detalhe de implementação do Manipulador de autenticação do Seletor de login de Granite do Adobe ( com.day.cq.auth.impl.LoginSelectorHandler
), que é um Apache Sling AuthenticationHandler configurado com AEM por padrão.
Ao chamar AuthenticationHandler.requestCredentials
, esse manipulador tenta 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:
com.adobe.granite.auth.requirement.impl.RequirementService
,LoginSelectorHandler
,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 público alvo desta documentação é a avaliação do caminho de logon como exposto pela interface interna LoginPathProvider
. A implementação enviada desde AEM 6.3 comporta-se da seguinte forma:
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:
LoginPathProvider
conforme implementado pelo novo com.adobe.granite.auth.requirement.impl.RequirementService
,LoginSelectorHandler
,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 requisito de autenticação no Granite, expõe os caminhos de logon conforme definido pelas propriedades granite:loginPath
, que, por sua vez, são definidas 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.
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 start de uma árvore deve ser suficiente e é herdado para toda a subárvore definida pelo nó do público alvo. 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:
LoginSelectorHandler
.A documentação do Oak aborda 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.
A necessidade de um requisito de autenticação separado é refletida no conteúdo do repositório com um tipo de nó de mixin dedicado colocado no nó do público alvo. O tipo de mixin define uma propriedade opcional para especificar uma página de logon dedicada para a árvore definida pelo nó do público alvo.
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)
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 controles de acesso JCR e segue os mecanismos descritos com a especificação JCR 2.0.
Código para aplicar uma nova política CUG em um nó que não tinha um CUG definido antes. Observe que getApplicablePolicies
retornará somente 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();
As etapas a seguir são necessárias para editar uma política de CUG existente. Observe que a política modificada precisa ser regravada 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");
}
O gerenciamento de controles 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
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);
}
}
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);
}
As extensões definidas por JackrabbitAccessControlManager
que permitem editar as políticas de controle de acesso por principal não são implementadas com o gerenciamento de controles de acesso CUG, já que, por definição, uma política CUG sempre afeta todos os principais: os listados com PrincipalSetPolicy
recebem acesso de leitura, enquanto todos os outros principais serão impedidos de ler o conteúdo na árvore definida pelo nó do público alvo.
Os métodos correspondentes sempre retornam uma matriz de política vazia, mas não lançam exceções.
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ó do público alvo. A propriedade opcional de caminho de login pode ser gravada usando a API JCR comum.
As modificações em determinado nó de público alvo mencionado acima serão refletidas somente no Autenticador Sling do Apache se RequirementHandler
tiver sido configurado e o público alvo estiver contido nas árvores definidas pelos caminhos suportados (consulte as Opções de configuração da seção).
Para obter mais informações, consulte [Atribuindo tipos de nós mistos](https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.10.3 Atribuindo tipos de nós mistos) e [Adicionando nós e definindo propriedades](https://docs.adobe.com/docs/en/spec/jcr/2.0/10_Writing.html#10.4 adicionando nós e definindo propriedades)
As etapas para criar um novo requisito de autenticação estão detalhadas abaixo. Observe que o requisito só será registrado com o Apache Sling Authenticator se RequirementHandler
tiver sido configurado para a árvore que contém o nó do público alvo.
Node targetNode = [...]
targetNode.addMixin("granite:AuthenticationRequired");
session.save();
Etapas para criar um novo requisito de autenticação incluindo um caminho de logon. Observe que os requisitos e a exclusão do caminho de logon só serão registrados com o Autenticador Apache Sling se RequirementHandler
tiver sido configurado para a árvore que contém o nó do público alvo.
Node targetNode = [...]
String loginPath = [...] // STRING property
Node targetNode = session.getNode(path);
targetNode.addMixin("granite:AuthenticationRequired");
targetNode.setProperty("granite:loginPath", loginPath);
session.save();
As etapas para alterar um caminho de login existente estão detalhadas abaixo. A modificação só será registrada com o Autenticador Apache Sling se RequirementHandler
tiver sido configurado para a árvore que contém o nó do público alvo. O valor do caminho de login anterior será removido do registro. O requisito de autenticação associado ao nó do público alvo 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");
}
Etapas para remover um caminho de logon existente. A entrada do caminho de logon só será cancelada do Autenticador Apache Sling se RequirementHandler
tiver sido configurado para a árvore que contém o nó do público alvo. O requisito de autenticação associado ao nó do público alvo 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();
}
Etapas para remover um requisito de autenticação existente. O requisito só será cancelado do Apache Sling Authenticator se RequirementHandler
tiver sido configurado para a árvore que contém o nó do público alvo.
Node targetNode = [...]
targetNode.removeMixin("granite:AuthenticationRequired");
session.save();
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 em https://<serveraddress>:<serverport>/system/console/slingauth
na seção "Authentication Requirements Configuration".
A imagem a seguir mostra os requisitos de autenticação de uma instância de publicação 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 Apache Sling Authenticator.
Neste exemplo, a propriedade de caminho de login opcional não foi definida. Consequentemente, não foi registrada nenhuma segunda entrada no autenticador.
No momento, 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 levadas em consideração ao projetar o modelo de conteúdo e os requisitos de autenticação de uma determinada instalação AEM.
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 lista 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 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 Requisito de avaliação e herança de autenticação, Avaliação do caminho de logon e Práticas 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();
}
}
A tabela a seguir lista as combinações válidas de políticas CUG e o requisito de autenticação em uma instância AEM que tenha ambos os módulos habilitados por meio da configuração.
Autenticação necessária | Caminho de login | Acesso de Leitura Restrito | Efeito esperado |
---|---|---|---|
Sim | Sim | Sim | Um determinado usuário só poderá visualização 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á visualização 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 visualização 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 visualização 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á visualização 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 o 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.
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.
As novas partes relacionadas à autorização estão contidas no pacote Autorização Oak CUG ( org.apache.jackrabbit.oak-authorization-cug
), que faz parte da instalação padrão AEM. O pacote define um modelo de autorização separado que deve ser implantado como uma forma adicional de gerenciar o acesso de leitura.
A configuração da autorização CUG é descrita em detalhes na documentação relevante do Apache. Por padrã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.
Você também precisa configurar o Filtro de Quem indicou Sling com todos os nomes de host que podem ser usados para acessar AEM; por exemplo, por meio de CDN, Balanceador de Carga e qualquer outro.
Se o filtro de quem indicou 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
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.authorized.cug.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 |
Além disso, consulte Opções 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 | Apache Jackrabbit Oak CUG Excluir Lista |
Descrição | Permite excluir o(s) principal(s) com os nomes configurados da avaliação CUG. |
Propriedades de configuração |
Consulte também as Opções de configuração da seção abaixo. |
Política de configuração | ConfigurationPolicy.REQUIRE |
Referências | ND |
As principais opções de configuração são:
cugSupportedPaths
: especificar as subárvores que podem conter CUGs. Nenhum valor padrão está definidocugEnabled
: 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.
Foi adotada a isenção dos principais individuais da avaliação da CUG relativamente à 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 é configurado em AEM instâncias de publicação.
O padrão desde AEM 6.3 impede que os seguintes principais sejam afetados pelas políticas de CUG:
Para obter mais informações, consulte a tabela na seção Configuração padrão desde 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 de Apache Jackrabbit Oak CUG Excluir Lista.
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 em Plug-ability para obter detalhes e uma implementação de exemplo.
As novas peças relacionadas à autenticação estão contidas no pacote Adobe Granite Authentication Handler ( com.adobe.granite.auth.authhandler
versão 5.6.48). Este pacote faz parte da instalação padrão 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 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 de AEM padrão, 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 mistura granite:AuthenticationRequirement ) e caminhos de logon com são expostos ao LoginSelectorHandler . |
Propriedades de configuração | - |
Política de configuração | ConfigurationPolicy.OPTIONAL |
Referências |
|
com.adobe.granite.auth.requirements.impl.DefaultRequirementsHandler
Etiqueta | Requisito 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 |
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 de Granite do Adobe 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 indefinida se desejar adicionar o tipo de mistura granite:AuthenticationRequirement aos nós sem que eles sejam aplicados (por exemplo, em instâncias do autor). Se estiver ausente, o recurso será desativado. |
Por padrão, novas instalações de 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, por padrão, será desativada em todas as instalações AEM. As novas implementações serão ativadas da seguinte maneira:
"Configuração Apache Jackrabbit Oak CUG" | Explicação |
---|---|
Caminhos suportados /content |
O gerenciamento de controles 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 Adobe Granite e Manipulador de Caminho de Login está presente nas instâncias de criação padrão.
"Configuração Apache Jackrabbit Oak CUG" | Explicação |
---|---|
Caminhos suportados /content |
O gerenciamento de controles 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 em 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. |
"Requisito 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 mistura granite:AuthenticationRequired entram em vigor abaixo de /content em Session.save() . O Sling Authenticator é atualizado. A adição do tipo de mistura fora dos caminhos suportados é ignorada. |
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.
Consulte a documentação CUG pluggability para obter detalhes sobre como remover o modelo de autorização CUG da configuração de autorização composta.
Para desativar o suporte para o requisito de autenticação, conforme fornecido pelo módulo granite.auth.authhandler
, basta remover a configuração associada ao Requisito de Autenticação de Adobe Granite e Manipulador de Caminho de Login.
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.
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 módulo jackrabbit-api
define uma nova interface chamada org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy
, que se estende de javax.jcr.security.AccessControlPolicy
.
O mecanismo de importação do Apache Jackrabbit FileVault foi ajustado para lidar com políticas de controle de acesso do tipo PrincipalSetPolicy
.
Consulte a seção acima Apache Jackrabbit FileVault.
O módulo de replicação foi ligeiramente ajustado para poder replicar as políticas de CUG entre diferentes instâncias 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 instâncias org.apache.jackrabbit.api.security.authorization.PrincipalSetPolicy
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.
O manipulador de autenticação Adobe Granite HTTP Header Authentication Handler fornecido com o pacote com.adobe.granite.auth.authhandler
contém uma referência à interface CugSupport
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 a CugSupport
opcional, a fim de garantir a compatibilidade retroativa máxima se uma determinada configuração decidir reativar a implementação obsoleta. 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 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.
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 em 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.
A presente seção tem por objetivo 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.
O componente OSGi obsoleto 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.
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.
As principais diferenças do ponto de vista da autorização são resumidas na lista seguinte:
Conteúdo de Controle de acesso dedicado para CUGs
Na implementação antiga, o modelo de autorização padrão era usado para manipular as políticas de lista de controles de acesso na publicação, substituindo quaisquer ACEs existentes pela configuração exigida pelo CUG. Isto foi desencadeado pela escrita de propriedades regulares e residuais do JCR que foram interpretadas durante a publicação.
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 chamado PrincipalSetPolicy
é aplicado como conteúdo de controle de acesso adicional ao nó do público alvo. Essa política adicional será localizada como um filho do nó do público alvo e seria um irmão do nó de política padrão, se presente.
Editar Políticas CUG No Gerenciamento De Controles de acesso
Essa mudança das propriedades residuais do JCR para uma política de controles 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 no conteúdo do controle de acesso, 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 do 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 público alvo 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 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 permitido para visualização de CUGcontent
só terá acesso de leitura 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 CUGPolicy
e do controle de acesso 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 padrão de publicação AEM onde o acesso de leitura à árvore completa /content
é concedido para todos, o efeito das políticas CUG será o mesmo da implementação antiga.
Avaliação sob demanda
O modelo de autorização CUG permite ativar individualmente o gerenciamento de controles de acesso e a avaliação de permissões:
Na nova avaliação de configuração padrão AEM das políticas CUG, ela só é ativada com o modo de execução "publicar". Consulte os detalhes da configuração padrão desde 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 que resultam dessas políticas só será aplicada se Avaliação CUG ativada estiver ativada no console do sistema na configuração Apache Jackrabbit Oak CUG. Por padrão, ele é ativado somente com o modo de execução "publicar".
As diferenças em relação à autenticação são descritas abaixo.
Na implementação anterior, os aspectos de autorização e autenticação de um CUG foram acionados por uma única propriedade JCR ( cq:cugEnabled
). No que diz respeito à autenticação, isso resultou em uma lista atualizada dos 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ó do público alvo com um tipo de combinação dedicado ( granite:AuthenticationRequired
).
O tipo de mixin define uma única propriedade opcional chamada granite:loginPath
, que corresponde basicamente à propriedade cq:cugLoginPage
. 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.
A adição ou remoção de um tipo de combinação requer jcr:nodeTypeManagement
a concessão do privilégio. Na implementação anterior, o privilégio jcr:modifyProperties
é usado para editar a propriedade residual.
No que diz respeito a granite:loginPath
, o mesmo privilégio é necessário para adicionar, modificar ou remover a propriedade.
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. É provável que seja 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.
O tipo de combinação granite:AuthenticationRequired
e a propriedade granite:loginPath só serão respeitados dentro do escopo definido pelo conjunto de Caminhos Suportados opções de configuração presentes com o Requisito de Autenticação de Adobe Granite e 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.
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 CUG desde AEM 6.3
A antiga implementação de suporte do CUG foi descontinuada e será removida para versões futuras. É recomendável passar para as novas implementações ao atualizar de versões anteriores à AEM 6.3.
Para instalação AEM atualizada, é importante garantir que somente uma implementação CUG esteja ativada. A combinação do suporte novo e antigo e obsoleto ao CUG não é testada e provavelmente causa um comportamento indesejado:
O Adobe fornece uma ferramenta para migrar para a nova implementação do CUG. Para usá-lo, execute as seguintes etapas:
https://<serveraddress>:<serverport>/system/console/cug-migration
para acessar a ferramenta.Se você encontrar problemas, será possível configurar um registrador específico no nível DEBUG em com.day.cq.auth.impl.cug
para obter a saída da ferramenta de migração. Consulte Registro para obter mais informações sobre como fazer isso.