A principal maneira de obter uma sessão administrativa ou um resolvedor de recursos no AEM era usar o SlingRepository.loginAdministrative()
e ResourceResolverFactory.getAdministrativeResourceResolver()
métodos fornecidos pelo Sling.
No entanto, nenhum destes métodos foi concebido em torno da princípio do menor privilégio e facilitar demais para um desenvolvedor não planejar uma estrutura adequada e os Níveis de Controle de Acesso (ACLs) correspondentes para seu conteúdo desde o início. Se uma vulnerabilidade estiver presente em um serviço desse tipo, isso geralmente leva a escalonamentos de privilégios para a variável admin
usuário, mesmo que o código em si não precisasse de privilégios administrativos para funcionar.
Pode haver casos em que a sessão de administrador não seja usada ou o recurso esteja desabilitado totalmente. Se esse for o caso da implementação, remova o recurso completamente ou ajuste-o com Código NOP.
Sempre que possível, refatere seu recurso para que a sessão de solicitação especificada e autenticada possa ser usada para ler ou gravar conteúdo. Se tal não for possível, poderá ser conseguido aplicando frequentemente as prioridades que se seguem às que se seguem.
Muitos problemas podem ser resolvidos por meio da reestruturação do conteúdo. Lembre-se dessas regras simples ao fazer a reestruturação:
Alterar controle de acesso
Refinar estrutura de conteúdo
Refazer o código para ser um serviço adequado
Além disso, certifique-se de que todos os novos recursos desenvolvidos seguem estes princípios:
Os requisitos de segurança devem direcionar a estrutura do conteúdo
Usar tipos de nó
Respeitar configurações de privacidade
/profile
nó .Se você aplicar o controle de acesso durante a reestruturação do conteúdo ou quando fizer isso para um novo usuário de serviço, deverá aplicar as ACLs mais rigorosas possíveis. Utilizar todas as possibilidades de controlo de acesso:
Por exemplo, em vez de aplicar jcr:read
on /apps
, aplicar somente a /apps/*/components/*/analytics
Use restrições
Aplicar ACLs para tipos de nó
Limitar permissões
jcr:write
Permissão; use jcr:modifyProperties
insteadSe o acima falhar, o Sling 7 oferece um serviço de Mapeamento de usuário de serviço, que permite configurar um mapeamento de pacote para usuário e dois métodos de API correspondentes: [SlingRepository.loginService()](https://sling.apache.org/apidocs/sling7/org/apache/sling/jcr/api/SlingRepository.html#loginService-java.lang.String-java.lang.String-)
e [ResourceResolverFactory.getServiceResourceResolver()](https://sling.apache.org/apidocs/sling7/org/apache/sling/api/resource/ResourceResolverFactory.html#getServiceResourceResolver-java.util.Map-)
que retornam uma sessão/resolvedor de recursos com os privilégios de um usuário configurado somente. Esses métodos têm as seguintes características:
Eles permitem serviços de mapeamento para usuários
Eles possibilitam definir usuários de subserviço
O ponto central de configuração é: org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl
service-id
= service-name
[ ":" nome do subserviço ]
service-id
está mapeado para um resolvedor de recursos e/ou ID de usuário do repositório JCR para autenticação
service-name
é o nome simbólico do pacote que fornece o serviço
Um usuário de serviço é um usuário JCR sem senha definida e um conjunto mínimo de privilégios necessários para executar uma tarefa específica. Não ter senha definida significa que não será possível fazer logon com um usuário de serviço.
Uma maneira de descontinuar uma sessão administrativa é substituí-la por sessões de usuário de serviço. Ela também pode ser substituída por vários usuários de sub-serviço, se necessário.
Para substituir a sessão de administrador por um usuário de serviço, você deve executar as seguintes etapas:
Identifique as permissões necessárias para seu serviço, tendo em mente o princípio da menor permissão.
Verifique se já há um usuário disponível exatamente com a configuração de permissão necessária. Crie um novo usuário do serviço do sistema se nenhum usuário existente corresponder às suas necessidades. O RTC é necessário para criar um novo usuário de serviço. Às vezes, faz sentido criar vários usuários de sub-serviço (por exemplo, um para escrita e outro para leitura) para compartimentalizar ainda mais o acesso.
Configure e teste ACEs para seu usuário.
Adicione um service-user
mapeamento para seu serviço e para user/sub-users
Disponibilize o recurso de sling do usuário de serviço ao seu pacote: atualizar para a versão mais recente de org.apache.sling.api
.
Substitua o admin-session
no seu código com o loginService
ou getServiceResourceResolver
APIs.
Após verificar que nenhum usuário da lista de AEM usuários do serviço é aplicável ao seu caso de uso e que os problemas de RTC correspondentes foram aprovados, é possível adicionar o novo usuário ao conteúdo padrão.
A abordagem recomendada é criar um usuário de serviço para usar o explorador de repositório em https://<server>:<port>/crx/explorer/index.jsp
O objetivo é obter um valor válido jcr:uuid
propriedade que é obrigatória para criar o usuário por meio de uma instalação do pacote de conteúdo.
Você pode criar usuários do serviço ao:
Ir para o explorador de repositório em https://<server>:<port>/crx/explorer/index.jsp
Efetuar logon como administrador pressionando o Fazer logon no canto superior esquerdo da tela.
Em seguida, crie e nomeie o usuário do sistema. Para criar o usuário como um sistema, defina o caminho intermediário como system
e adicionar subpastas opcionais dependendo de suas necessidades:
Verifique se o nó do usuário do sistema tem a seguinte aparência:
Observe que não há tipos de mixin associados a usuários de serviços. Isso significa que não haverá políticas de controle de acesso para usuários do sistema.
Ao adicionar o .content.xml correspondente ao conteúdo do seu pacote, verifique se você definiu a variável rep:authorizableId
e que o tipo principal é rep:SystemUser
. Deve ser assim:
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:jcr="https://www.jcp.org/jcr/1.0" xmlns:rep="internal"
jcr:primaryType="rep:SystemUser"
jcr:uuid="4917dd68-a0c1-3021-b5b7-435d0044b0dd"
rep:principalName="authentication-service"
rep:authorizableId="authentication-service"/>
Para adicionar um mapeamento do seu serviço aos Usuários do sistema correspondentes, é necessário criar uma configuração de fábrica para o [ServiceUserMapper](https://sling.apache.org/apidocs/sling7/org/apache/sling/serviceusermapping/ServiceUserMapper.html)
serviço. Para manter esse modular, essas configurações podem ser fornecidas usando o Mecanismo de alteração do Sling. A maneira recomendada de instalar essas configurações com seu pacote é usando Carregamento inicial de conteúdo do Sling:
Crie uma subpasta SLING-INF/content abaixo da pasta src/main/resources do seu pacote
Nesta pasta, crie um arquivo chamado org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.changed-<some unique="" name="" for="" your="" factory="" configuration="">.xml com o conteúdo de sua configuração de fábrica (incluindo todos os mapeamentos de usuário de sub-serviço). Exemplo:
Crie um SLING-INF/content
abaixo da pasta src/main/resources
pasta do seu pacote;
Nesta pasta, crie um arquivo named org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-<a unique name for your factory configuration>.xml
com o conteúdo de sua configuração de fábrica, incluindo todos os mapeamentos de usuário de sub-serviço.
Para fins de ilustração, use um arquivo chamado org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-com.adobe.granite.auth.saml.xml
:
<?xml version="1.0" encoding="UTF-8"?>
<node>
<primaryNodeType>sling:OsgiConfig</primaryNodeType>
<property>
<name>user.default</name>
<value></value>
</property>
<property>
<name>user.mapping</name>
<values>
<value>com.adobe.granite.auth.saml=authentication-service</value>
</values>
</property>
</node>
Faça referência ao conteúdo inicial do Sling na configuração do maven-bundle-plugin
no pom.xml
do seu pacote. Exemplo:
<Sling-Initial-Content>
SLING-INF/content;path:=/libs/system/config;overwrite:=true;
</Sling-Initial-Content>
Instale o pacote e verifique se a configuração de fábrica foi instalada. Você pode fazer isso ao:
Chamadas para loginAdministrative()
aparecem junto com sessões compartilhadas. Essas sessões são adquiridas na ativação do serviço e são desconectadas somente após a interrupção do serviço. Embora esta seja uma prática comum, leva a dois problemas:
A solução mais óbvia para o risco de segurança é simplesmente substituir a variável loginAdministrative()
com uma loginService()
um para um usuário com privilégios restritos. No entanto, isso não terá impacto em nenhuma degradação potencial do desempenho. Uma possibilidade de mitigar isso é envolver todas as informações solicitadas em um objeto que não tenha associação com a sessão. Em seguida, crie (ou destrua) a sessão sob demanda.
A abordagem recomendada é refatorar a API do serviço para dar ao chamador controle sobre a criação/destruição da sessão.
JSPs não podem usar loginService()
, pois não há serviço associado. No entanto, as sessões administrativas em JSPs geralmente são um sinal de violação do paradigma do MVC.
Isso pode ser corrigido de duas maneiras:
O primeiro método é o preferido.
Ao processar eventos ou tarefas e, em alguns casos, workflows, a sessão correspondente que acionou o evento normalmente é perdida. Isso leva a manipuladores de eventos e processadores de trabalho que geralmente usam sessões administrativas para fazer o seu trabalho. Existem diferentes abordagens concebíveis para resolver este problema, cada uma com as suas vantagens e desvantagens:
Passe o user-id
no payload do evento e use representação.
Vantagens: Fácil de usar.
Desvantagens: Ainda usa loginAdministrative()
. Autentica novamente uma solicitação que já foi autenticada.
Crie ou reutilize um usuário de serviço que tenha acesso aos dados.
Vantagens: Consistente com o design atual. Precisa de uma mudança mínima.
Desvantagens: Precisa de usuários de serviços muito poderosos para serem flexíveis, o que pode facilmente levar a escalonamentos de privilégios. Evita o modelo de segurança.
Passe uma serialização da variável Subject
no payload do evento e crie um ResourceResolver
baseado nesse assunto. Um exemplo seria usar o JAAS doAsPrivileged
no ResourceResolverFactory
.
Vantagens: Limpar a implementação do ponto de vista de segurança. Evita a reautenticação e opera com os privilégios originais. O código de segurança relevante é transparente para o consumidor do evento.
Desvantagens: Precisa de refatoração. O fato de o código relevante para a segurança ser transparente para o consumidor do evento também pode causar problemas.
A terceira abordagem é atualmente a técnica de processamento preferida.
Nas implementações do processo de fluxo de trabalho, a sessão do usuário correspondente que acionou o fluxo de trabalho geralmente é perdida. Isso leva a processos de fluxo de trabalho que geralmente usam sessões administrativas para executar seu trabalho.
Para corrigir esses problemas, é recomendável que as mesmas abordagens mencionadas em Eventos de processamento, pré-processadores de replicação e tarefas ser usada.
Há algumas sessões administrativas usadas em implementações do POST sling. Geralmente, as sessões administrativas são usadas para acessar nós que estão pendentes de exclusão no POST que está sendo processado. Consequentemente, eles não estão mais disponíveis por meio da sessão de solicitação. Um nó pendente de exclusão pode ser acessado para revelar o metada que, de outra forma, não deveria estar acessível.