Usuários, grupos e permissões do AEM aem-users-groups-and-permissions

O Adobe Experience Manager se baseia em usuários, grupos de usuários e perfis de produtos do Adobe IMS para fornecer aos usuários acesso personalizável ao AEM. Saiba como definir grupos e permissões do AEM, que se baseiam nos grupos de usuários fornecidos pela AEM, e como eles trabalham em conjunto com abstrações do Adobe IMS para fornecer acesso fácil e personalizável ao AEM.

Permissões e controle de acesso do AEM Assets assets-permissions-and-access-control

O acesso ao Adobe Experience Manager (AEM) Assets é controlado por duas camadas independentes que devem ser configuradas corretamente:

  1. Perfis do produto Adobe Admin Console: concede o direito técnico para acessar um ambiente AEM, por exemplo, Usuário Avançado, Colaborador, Usuário Limitado e Administradores.
  2. Associação de grupo local da AEM e ACLs: controla o que você pode realmente fazer uma vez dentro desse ambiente, por exemplo, carregar, editar, excluir, aprovar e configurar.

A atribuição de um perfil de produto no Admin Console é necessária, mas não é suficiente: um usuário pode ser um Usuário avançado totalmente licenciado no Admin Console e ainda ser bloqueado de todas as operações de ativos se também não for colocado no grupo AEM local correto. Por outro lado, a associação correta de grupo local da AEM não terá efeito se o usuário nunca tiver recebido um perfil de produto do Admin Console para o ambiente.

Permissões necessárias para operações comuns permissions-required-for-common-operations

Operação
Permissão ou grupo necessário
Notas
Carregar um ativo para /content/dam
rep:write no caminho de destino /content/dam
A associação de grupo por si só não garante que isso seja herdado no nível do usuário. Se os uploads falharem para usuários específicos, enquanto outros usuários no mesmo grupo forem bem-sucedidos, verifique se rep:write está realmente presente na ACL efetiva do usuário e não apenas presumido da associação do grupo.
Pesquisar ou visualizar ativos na interface do Digital Asset Management (DAM)
Acesso de leitura a /content/dam (normalmente por meio de dam-users) e jcr:read em /conf/global/settings/dam/adminui-extension/metadataschema.
A interface do usuário do Assets resolve as definições do esquema de metadados de /conf para renderizar resultados. Se um grupo tiver acesso total de /content/dam, mas nenhum acesso de leitura ao caminho de configuração do esquema, a interface do usuário lançará silenciosamente uma NullPointerException e search/browse. Este não é um problema de permissão /content/dam mesmo que pareça um.
Criar ou editar um perfil de pasta
Associação ao grupo de administradores local.
Uma atribuição de Administrador do Admin Console não é a mesma coisa, o botão Criar para perfis de pasta é renderizado apenas para contas que também são membros do grupo de administradores locais do AEM.
Criar ou editar um esquema de metadados personalizado
Recursivo jcr:read em /conf, /conf/global/settings/dam/adminui-extension/metadataschema e jcr:write em /conf/global/settings/dam/adminui-extension e seu subnó metadataschema.
O acesso de gravação ao nó de esquema de metadados não é suficiente; o editor de esquema também precisa ler a árvore pai /conf para renderizar corretamente.
Editar campos de metadados de ativos (por exemplo, revisar status em ativos assimilados pela Content Hub)
dam-users associação de grupo.
Aplica-se até mesmo a ativos assimilados pelo Content Hub. A permissão de edição subjacente ainda é o modelo de grupo DAM padrão da AEM.
Usar a ação Compartilhar link
jcr:modifyAccessControl na pasta e o grupo não deve ser excluído de Permitir somente para grupos
Configurado em Ferramentas > Assets > Configurações do Assets > Compartilhamento de Links. Observou-se que isso difere entre ambientes (por exemplo, está presente no servidor dev, mas ausente no servidor de produção) mesmo com código idêntico, portanto, você deve verificar a ACL e essa tela de configuração por ambiente.
Licenciar e salvar um ativo do Adobe Stock
Associação no grupo de licenciamento do Stock e no grupo de criação DAM base (por exemplo, dam-users)
A associação ao grupo do Stock não é suficiente para que o fluxo de trabalho Licenciar e Salvar seja concluído.
Exibir largura de banda e armazenamento no Dynamic Media Classic
Privilégios de administrador do sistema.
Privilégios insuficientes exibidos como erro do Scene7 #2046 em vez de uma mensagem padrão de permissão negada.
Acesso à API por meio de um token de portador JSON Web Token (JWT) ou conta técnica
O usuário AEM subjacente da conta técnica deve ser adicionado explicitamente ao grupo AEM necessário (por exemplo, um grupo somente para visualização).
O provisionamento de um perfil de produto ou serviço no console do administrador cria a conta técnica do usuário. Isso não concede automaticamente a ele todos os grupos do AEM necessários para respostas completas da API, por exemplo, listas de representação completas. A associação de grupo AEM da conta ainda precisa de configuração separada.

Avaliação de herança e permissão de grupo group-inheritance-and-permission-evaluation

  • As permissões aplicadas a uma pasta principal são aplicadas em cascata às pastas e aos ativos secundários por padrão.
  • As regras de negação explícitas têm prioridade sobre as regras de permissão. Você pode ser um membro de um grupo que tem acesso permitido, mas se você (diretamente ou por meio de outro grupo) também estiver sujeito a uma regra de negação jcr:read (ou outro) nesse caminho ou em um caminho ancestral, a negação prevalecerá — mesmo quando ambos os casos parecerem ter associações de grupo idênticas no console do administrador.
  • Quando dois usuários com permissões aparentemente idênticas se comportam de maneira diferente, compare suas ACLs efetivas (Ferramentas > Segurança > Permissões ou o Navegador do Repositório), não apenas suas listas de associação de grupo. Você deve procurar especificamente por regras de negação com escopo para um dos grupos.

Diferenciando tipos de grupo distinguishing-group-types

A AEM não separa visualmente tipos de grupos em Ferramentas > Segurança > Grupos, o que dificulta grandes auditorias de permissões. Use estas regras para classificar um grupo:

  • Os grupos prontos para uso (OOTB) têm IDs de grupo fixas e conhecidas, por exemplo, administradores, usuários DAM e autores de conteúdo.
  • Os grupos sincronizados com IMS criados automaticamente a partir dos grupos de usuários do console do administrador carregam uma propriedade rep:externalId terminando em ;ims.
  • Os grupos personalizados criados diretamente no AEM não têm nenhuma propriedade rep:externalId.

A orientação da Adobe é tratar a OOTB e os grupos locais personalizados como os blocos fundamentais para permissões e tratar os grupos sincronizados com o IMS exclusivamente como pontos de entrada que mapeiam atribuições do console do administrador no AEM, não como um local para criar camadas de ACLs ad hoc adicionais.

Comportamento específico do Content Hub e do Brand Portal content-hub-brand-portal-specific-behavior

  • O acesso ao Content Hub não é controlado por grupos dedicados do Content Hub. Ele é controlado por perfis de produto do console do administrador específicos do ambiente, normalmente chamados de Usuários limitados da AEM Assets - entrega - Programa - Ambiente .
  • O acesso ao ContentHub é concedido somente por meio do perfil de produto Usuário limitado. O perfil Usuário Avançado não concede acesso ao ContentHub sozinho. Atribuir o Usuário Avançado e o Usuário Limitado à mesma conta não duplica o consumo de licenças.
  • Os direitos de administrador do Content Hub exigem a associação a perfis de produtos específicos (Usuários Limitados do AEM Assets - Administradores de entrega e do AEM - autor de produção). A visibilidade da guia Administrador na interface do usuário não é ela mesma prova de direitos de administrador.
  • As regras de controle de acesso baseado em atributos (ABAC), quando ativadas, são configuradas para autoatendimento por meio do assistente de IA ou agente de governança dentro do Content Hub; não há tela separada dedicada a permissões ABAC. Se grupos específicos não conseguirem visualizar quaisquer ativos no Content Hub apesar das atribuições de grupo ou perfil com aparência correta, verifique se as políticas ABAC estão ativadas e se os atributos de usuário ou metadados de ativos atendem a essas políticas antes de assumir uma configuração incorreta do grupo.
  • As alterações feitas em usuários ou grupos no console do administrador não se refletem no Brand Portal em tempo real. Um trabalho de sincronização em segundo plano é executado aproximadamente a cada 8 horas, portanto, aguarde de de 5 a 10 horas antes de solucionar problemas de um relatório de alterações que não aparecem como um erro.
  • Uma coleção marcada como pública no Brand Portal ainda estará inacessível aos usuários convidados se a pasta subjacente do Digital Asset Management (DAM) não for pública e se os ativos não forem publicados do AEM Assets. A visibilidade no nível da coleção não substitui a visibilidade no nível da pasta.
  • Um Grupo de usuários fechado (CUG) aplicado a um caminho DAM pode bloquear a visibilidade do editor por ambiente mesmo após uma replicação bem-sucedida. Uma propriedade cq:lastReplicated ausente é um sinal de diagnóstico útil de que o ativo nunca foi realmente publicado (diferente de ser bloqueado pelo CUG após a publicação).

Solução de problemas de erros de permissão negada troubleshooting-permission-denied-errors

  1. Confirme a atribuição do perfil de produto do console do administrador para o ambiente correto (autor versus entrega ou instância do Content Hub são configurados separadamente; o perfil de Usuários limitados em particular reside em uma instância de entrega separada, não na instância do autor principal).
  2. Confirme a associação de grupo local da AEM correspondente, não apenas o perfil do console do administrador, pois ambos são necessários.
  3. Verifique se você está fazendo logon com sua organização ou conta da Adobe da empresa em vez de uma Adobe ID pessoal. O acesso atribuído à conta da organização não será exibido se você estiver conectado pessoalmente. Incluir na lista de permissões também pode ser necessário.
  4. Inspecione a ACL efetiva no caminho específico no navegador do repositório ou na interface de usuário de Segurança ou Permissões para verificar se há regras de negação que substituem a regra de permissão de um grupo que esteja correto de outra forma.
  5. Para as falhas de pesquisa ou navegação do DAM com o que parece ser o acesso correto de /content/dam, verifique o acesso de leitura para /conf/global/settings/dam/adminui-extension/metadataschema especificamente. Esse é um bloqueador comum, não óbvio.
  6. Para falhas de edição do perfil de pasta ou do esquema de metadados, confirme a associação de grupo de administradores locais (perfis de pasta) ou a combinação completa de leitura e gravação recursiva /conf. Concessões mais restritas que pareça corretas frequentemente estão incompletas.
  7. A atribuição do console do administrador sozinha nunca concede recursos no aplicativo, sempre verifique se o grupo AEM-local ou ACL correspondente existe.

Recursos adicionais

​+ Suporte IMS do Adobe Experience Manager as a Cloud Service
​+ Grupos de usuários fornecidos pelo AEM e suas permissões

recommendation-more-help
experience-manager-learn-help-cloud-service