A habilitação do acesso a um repositório CRX envolve vários tópicos:
Os elementos básicos são:
Contas de usuário - O CRX autentica o acesso identificando e verificando um usuário (por essa pessoa ou outro aplicativo) de acordo com os detalhes mantidos na conta do usuário.
No CRX, cada conta de usuário é um nó no espaço de trabalho. Uma conta de usuário do CRX tem as seguintes propriedades:
Ele representa um usuário do CRX.
Ele contém um nome de usuário e uma senha.
Aplicável para esse espaço de trabalho.
Ele não pode ter subusuários. Para direitos de acesso hierárquicos, você deve usar grupos.
Você pode especificar direitos de acesso para a conta de usuário.
No entanto, para simplificar o gerenciamento, a Adobe recomenda que (na maioria dos casos) você atribua direitos de acesso a contas de grupo. A atribuição de direitos de acesso para cada usuário individual torna-se rapidamente difícil de gerenciar (as exceções são determinados usuários do sistema quando apenas uma ou duas instâncias existem).
Contas de grupo - Contas de grupo são coleções de usuários e/ou outros grupos. Eles são usados para simplificar o gerenciamento, uma vez que os direitos de acesso atribuídos a um grupo são aplicados automaticamente a todos os usuários desse grupo. Um usuário não precisa pertencer a nenhum grupo, mas geralmente pertence a vários.
No CRX, um grupo tem as seguintes propriedades:
Direitos de acesso - O CRX usa direitos de acesso para controlar o acesso a áreas específicas do repositório.
Isso é feito atribuindo privilégios para permitir ou negar acesso a um recurso (nó ou caminho) no repositório. Como vários privilégios podem ser atribuídos, eles devem ser avaliados para determinar qual combinação é aplicável para a solicitação atual.
O CRX permite configurar os direitos de acesso para contas de usuário e de grupo. Os mesmos princípios básicos de avaliação são então aplicados a ambos.
Implementações do CRX controle de acesso conforme definido pela JSR-283.
Uma instalação padrão de um repositório CRX é configurada para usar listas de controle de acesso baseadas em recursos. Esta é uma possível implementação do controle de acesso JSR-283 e uma das implementações presentes com Jackrabbit.
O CRX usa dois conceitos principais ao avaliar direitos de acesso:
A principal é uma entidade que possui direitos de acesso. Os principais incluem:
Uma conta de usuário
Uma conta de grupo
Se uma conta de usuário pertencer a um ou mais grupos, ela também será associada a cada uma dessas entidades de grupo.
A assunto é usado para representar a origem de uma solicitação.
É usado para consolidar os direitos de acesso aplicáveis a essa solicitação. Elas são obtidas de:
O usuário principal
Os direitos que você atribui diretamente à conta de usuário.
Todos os grupos principais associados a esse usuário
Todos os direitos são atribuídos a qualquer um dos grupos aos quais o usuário pertence.
O resultado é usado para permitir ou negar acesso ao recurso solicitado.
No CRX, o assunto depende de:
A lista de direitos de acesso aplicáveis à entidade é construída a partir de:
Quando o CRX lida com a solicitação, ele compara a solicitação de acesso do sujeito com a lista de controle de acesso no nó do repositório:
Então, se Linda pedir para atualizar o /features
na seguinte estrutura do repositório:
Os direitos de acesso no CRX são avaliados da seguinte maneira:
As entidades do usuário sempre têm prioridade sobre as entidades do grupo, independentemente:
Para um determinado principal, existe (no máximo) uma negação e uma entrada de permissão em um determinado nó. A implementação sempre limpa as entradas redundantes e garante que o mesmo privilégio não seja listado nas entradas de permissão e negação.
Esse processo de avaliação é apropriado para o controle de acesso baseado em recursos de uma instalação CRX padrão.
Tomando dois exemplos em que o usuário aUser
é membro do grupo aGroup
:
+ parentNode
+ acl
+ ace: aUser - deny - write
+ childNode
+ acl
+ ace: aGroup - allow - write
+ grandChildNode
No caso acima:
aUser
não recebe permissão de gravação em grandChildNode
. + parentNode
+ acl
+ ace: aUser - deny - write
+ childNode
+ acl
+ ace: aGroup - allow - write
+ ace: aUser - deny - write
+ grandChildNode
Neste caso:
aUser
não recebe permissão de gravação em grandChildNode
.aUser
é redundante.Os direitos de acesso de vários principais de grupo são avaliados com base em sua ordem, tanto na hierarquia quanto em uma única lista de controle de acesso.
A tabela a seguir lista algumas recomendações e práticas recomendadas:
Recomendação... | Motivo... |
Usar grupos | Evite atribuir direitos de acesso a cada usuário. Há vários motivos para isso:
|
Ser positivo | Sempre use as instruções Allow para especificar os direitos de acesso da entidade do grupo (sempre que possível). Evite usar uma instrução Deny. As entidades de grupo são avaliadas em ordem, tanto na hierarquia quanto na ordem em uma única lista de controle de acesso. |
Mantenha a simplicidade | Investir algum tempo e pensamento ao configurar uma nova instalação é bem pago. A aplicação de uma estrutura clara simplifica a manutenção e a administração contínuas, garantindo que seus colegas atuais e/ou futuros sucessores possam entender facilmente o que está sendo implementado. |
Testar | Use uma instalação de teste para praticar e garantir que você entenda os relacionamentos entre os vários usuários e grupos. |
Usuários/grupos padrão | Sempre atualize os Usuários e grupos padrão imediatamente após a instalação para ajudar a evitar problemas de segurança. |
Uma caixa de diálogo padrão é usada para Administração de usuários.
Você deve estar conectado ao espaço de trabalho apropriado e, em seguida, acessar a caixa de diálogo de:
Propriedades
UserID
O nome curto da conta é usado ao acessar o CRX.
Nome principal
Um nome de texto completo para a conta.
Senha
Necessário ao acessar o CRX com esta conta.
ntlmhash
Atribuído automaticamente para cada nova conta e atualizado quando a senha é alterada.
Você pode adicionar novas propriedades definindo um nome, tipo e valor. Clique em Salvar (símbolo de marca de verificação verde) para cada nova propriedade.
Associação de Grupo
Isso exibe todos os grupos aos quais a conta pertence. A coluna Herdado indica associação que foi herdada como resultado da associação de outro grupo.
Clicar em uma GroupID (quando disponível) abre a variável Administração de grupo para esse grupo.
Personificadores
Com a funcionalidade Representar, um usuário pode trabalhar em nome de outro usuário.
Isso significa que uma conta de usuário pode especificar outras contas (usuário ou grupo) que podem operar com sua conta. Em outras palavras, se o usuário-B tiver permissão para representar o usuário-A, ele poderá agir usando os detalhes completos da conta do usuário-A (incluindo ID, nome e direitos de acesso).
Isso permite que as contas de personificação concluam tarefas como se estivessem usando a conta que estão representando; por exemplo, durante uma ausência ou para compartilhar uma carga excessiva a curto prazo.
Se uma conta representar outra, é difícil visualizar. Os arquivos de log não contêm informações sobre o fato de que a representação ocorreu nos eventos. Portanto, se o usuário-B estiver representando o usuário-A, todos os eventos poderão parecer como se fossem executados pelo usuário-A pessoalmente.
Abra o Administração de usuários diálogo.
Clique em Criar usuário.
Em seguida, você pode inserir as Propriedades:
Clique em Salvar (símbolo de marca de verificação verde).
A caixa de diálogo é expandida para que você possa fazer o seguinte:
Às vezes, pode ocorrer uma perda de desempenho ao registrar novos usuários em instalações que têm um alto número de ambos:
Isso remove o nó dessa entidade do repositório.
As entradas de direito de acesso não são removidas. Isso garante a integridade histórica.
Você pode definir Propriedades para contas novas ou existentes:
As propriedades existentes podem ser excluídas com o símbolo de lixeira.
Exceto pela Senha, as propriedades não podem ser editadas, elas devem ser excluídas e recriadas.
A variável Senha é uma propriedade especial que pode ser alterada clicando no ícone Alterar senha link.
Você também pode alterar a senha para sua própria conta de usuário no Segurança no CRX Explorer.
É possível definir Representantes para contas novas ou existentes:
Abra o Administração de usuários para a conta apropriada.
Especifique a conta que poderá representar essa conta.
Você pode usar Procurar… para selecionar uma conta existente.
Clique em Salvar (símbolo de marca de verificação verde) para a nova propriedade.
Uma caixa de diálogo padrão é usada para Administração de grupo.
Você deve estar conectado ao espaço de trabalho apropriado e, em seguida, acessar a caixa de diálogo de:
Propriedades
GroupID
Nome abreviado da conta de grupo.
Nome principal
Um nome de texto completo para a conta de grupo.
Você pode adicionar novas propriedades definindo um nome, tipo e valor. Clique em Salvar (símbolo de marca de verificação verde) para cada nova propriedade.
Membros
Você pode adicionar usuários ou outros grupos como membros deste grupo.
Associação de Grupo
Isso exibe todos os grupos aos quais a conta de grupo atual pertence. A coluna Herdado indica associação que foi herdada como resultado da associação de outro grupo.
Clicar em uma ID de grupo abre a caixa de diálogo desse grupo.
Membros
Lista todas as contas (usuários e/ou grupos) que são membros do grupo atual.
A variável Herdado indica a associação que foi herdada como resultado da associação de outro grupo.
Quando a função Proprietário, Editor ou Visualizador é atribuída a um usuário em qualquer pasta de Ativos, um novo grupo é criado. O nome do grupo está no formato mac-default-<foldername>
para cada pasta na qual as funções são definidas.
Abra o Administração de grupo caixa de diálogo.
Clique em Criar grupo.
Em seguida, você pode inserir as Propriedades:
Clique em Salvar (símbolo de marca de verificação verde).
A caixa de diálogo é expandida para que você possa:
Isso remove o nó dessa entidade do repositório.
As entradas de direito de acesso não são removidas. Isso garante a integridade histórica.
Você pode definir Propriedades para contas novas ou existentes:
As propriedades existentes podem ser excluídas com o símbolo de lixeira.
É possível adicionar membros ao grupo atual:
Abra o Administração de grupo para a conta apropriada.
Ou:
Clique em Salvar (símbolo de marca de verificação verde) para a nova propriedade.
Ou exclua um membro existente com o símbolo de lixeira.
Com o Controle de acesso do CRXDE Lite, você poderá definir as políticas de controle de acesso e atribuir os privilégios relacionados.
Por exemplo, para Caminho atual selecione o recurso desejado no painel esquerdo, a guia Controle de acesso no painel inferior direito:
As políticas são categorizadas de acordo com:
Políticas do controle de acesso aplicáveis
Essas políticas podem ser aplicadas.
Estas são as políticas disponíveis para criar uma política local. Quando você seleciona e adiciona uma política aplicável, ela se torna uma política local.
Políticas do controle de acesso local
Estas são as políticas de controle de acesso que você aplicou. Em seguida, você pode atualizá-los, solicitá-los ou removê-los.
Uma política local substitui todas as políticas herdadas do pai.
Políticas do controle de acesso efetivo
Estas são as políticas de controle de acesso que agora estão em vigor para qualquer solicitação de acesso. Eles mostram as políticas agregadas derivadas das políticas locais e de qualquer herdada do pai.
As políticas podem ser selecionadas para:
Caminho atual
Como no exemplo acima, selecione um recurso no repositório. As políticas para esse "caminho atual" são mostradas.
Repositório
Seleciona o controle de acesso no nível do repositório. Por exemplo, ao definir a variável jcr:namespaceManagement
que só é relevante para o repositório, não para um nó.
Principal
Uma entidade registrada no repositório.
Você pode digitar a variável Principal ou clique no ícone à direita do campo para abrir a variável Selecionar principal caixa de diálogo.
Isso permite Pesquisar para um Usuário ou Grupo. Selecione o principal necessário na lista resultante e clique em OK para trazer o valor de volta para a caixa de diálogo anterior.
Para simplificar o gerenciamento, o Adobe recomenda que você atribua direitos de acesso a contas de grupo, não a contas de usuário individuais.
É mais fácil gerenciar alguns grupos do que muitas contas de usuário.
Os seguintes privilégios estão disponíveis para seleção ao adicionar uma entrada de controle de acesso (consulte API de segurança para obter detalhes completos):
Nome do privilégio | Que controla o privilégio de... |
---|---|
jcr:read |
Recupere um nó e leia suas propriedades e seus valores. |
rep:write |
Este é um privilégio agregado específico do Jackrabbit para jcr:write e jcr:nodeTypeManagement. |
jcr:all |
É um privilégio agregado que contém todos os outros privilégios predefinidos. |
Avançado | |
crx:replicate |
Executar replicação de um nó. |
jcr:addChildNodes |
Crie nós filhos de um nó. |
jcr:lifecycleManagement |
Executar operações de ciclo de vida em um nó. |
jcr:lockManagement |
Bloquear e desbloquear um nó; atualizar um bloqueio. |
jcr:modifyAccessControl |
Modifique as políticas de controle de acesso de um nó. |
jcr:modifyProperties |
Criar, modificar e remover as propriedades de um nó. |
jcr:namespaceManagement |
Registrar, cancelar registro e modificar definições de namespace. |
jcr:nodeTypeDefinitionManagement |
Importe definições de tipo de nó para o repositório. |
jcr:nodeTypeManagement |
Adicione e remova tipos de nó de mixin e altere o tipo de nó primário de um nó. Também inclui chamadas para Node.addNode e métodos de importação XML em que o mixin ou o tipo primário do novo nó é explicitamente especificado. |
jcr:readAccessControl |
Leia a política de controle de acesso de um nó. |
jcr:removeChildNodes |
Remova os nós filhos de um nó. |
jcr:removeNode |
Remover um nó. |
jcr:retentionManagement |
Executar operações de gerenciamento de retenção em um nó. |
jcr:versionManagement |
Executar operações de controle de versão em um nó. |
jcr:workspaceManagement |
A criação e a exclusão de espaços de trabalho por meio da API JCR. |
jcr:write |
Este é um privilégio agregado que contém: - jcr:modifyProperties - jcr:addChildNodes - jcr:removeNode - jcr:removeChildNodes |
rep:privilegeManagement |
Registre um novo privilégio. |
Você também pode registrar novos privilégios:
Na barra de ferramentas, selecione Ferramentas, depois Privilégios para exibir os privilégios registrados no momento.
Use o Registrar privilégio ícone (+) para que você possa definir um privilégio:
Clique em OK para salvar. O privilégio agora está disponível para seleção.
Selecione o recurso e abra a guia Controle de acesso guia.
Para adicionar um novo Políticas do controle de acesso local, clique no link + ícone à direita do Política do controle de acesso aplicável lista:
Uma nova entrada aparece em Políticas do controle de acesso local:
Clique em + para que você possa adicionar uma entrada:
No momento, é necessária uma solução alternativa para especificar uma cadeia de caracteres vazia.
Para isso, você deve usar ""
.
Defina sua política de controle de acesso e clique em OK para salvar. Sua nova política é:
O CRX valida sua seleção; para um determinado principal, existe (no máximo) uma negação e uma entrada de permissão em um determinado nó. A implementação sempre limpa as entradas redundantes e garante que o mesmo privilégio não seja listado nas entradas de permissão e negação.
A ordem na lista indica a ordem em que as políticas são aplicadas.
No quadro de Políticas do controle de acesso local, selecione a entrada necessária e arraste-a para a nova posição na tabela.
As alterações são mostradas em ambas as tabelas para o Local e a variável Políticas do controle de acesso efetivo.
Na barra de ferramentas do CRXDE Lite, selecione Ferramentas, depois Testar o controle de acesso….
Uma nova caixa de diálogo é aberta no painel superior direito. Selecione o Caminho e/ou Principal que você deseja testar.
Clique em Teste para ver os resultados da sua seleção: