Os aplicativos web geralmente fornecem recursos de gerenciamento de conta para os usuários finais se registrarem em um site, o que armazena as informações dos dados do usuário, permitindo que eles façam logon no futuro e desfrutem de uma experiência consistente. Este artigo descreve os seguintes conceitos do AEM as a Cloud Service:
Para que as funcionalidades descritas neste artigo funcionem, o recurso de sincronização de dados do usuário deve ser ativado, o que, no momento, requer que uma solicitação indicando o programa e os ambientes apropriados seja feita ao suporte. Se o recurso não estiver ativado, as informações do usuário serão mantidas apenas por um curto período (de 1 a 24 horas) antes de desaparecerem.
Quando um usuário final registra uma conta em um aplicativo do AEM, uma conta de usuário é criada no serviço de publicação do AEM, conforme refletido em um recurso de usuário em /home/users
, no repositório JCR.
Há duas abordagens para a implementação do registro, conforme descrito abaixo.
Pode-se escrever um código de registro personalizado que contenha, no mínimo, o nome de usuário e senha do usuário final. Isso criará um registro de usuário no AEM, que pode ser usado para autenticação durante o logon. As etapas a seguir são normalmente usadas para criar esse mecanismo de registro:
findAuthorizables()
da API do UserManagercreateUser()
da API do UserManagersetProperty()
da interface do AuthorizableEm alguns casos, o registro ou a criação de usuários já aconteceu em uma infraestrutura fora do AEM. Nesse cenário, o registro do usuário é criado no AEM durante o logon.
Depois que um usuário final é registrado no serviço de publicação do AEM, esses usuários podem fazer logon para obter acesso autenticado (usando mecanismos de autorização do AEM) e dados persistentes e específicos do usuário, como dados de perfil.
O logon pode ser implementado com as duas abordagens a seguir:
Os clientes podem gravar seus próprios componentes personalizados. Para saber mais, familiarize-se com:
Os clientes podem se integrar a um IdP (provedor de identidade), que autentica o usuário. As tecnologias de integração incluem SAML e OAuth/SSO, conforme descrito abaixo.
BASEADA EM SAML
Os clientes podem usar a autenticação baseada em SAML por meio de seu IdP de SAML preferencial. Ao usar um IdP com o AEM, ele é responsável por autenticar as credenciais do usuário final e intermediar a autenticação do usuário com o AEM, criar o registro do usuário no AEM conforme necessário e gerenciar a associação de grupo do usuário no AEM, conforme descrito pela asserção do SAML.
Somente a autenticação inicial das credenciais do usuário é realizada pelo IdP. As solicitações subsequentes ao AEM são executadas usando um cookie de token de logon do AEM, desde que o cookie esteja disponível.
Consulte a documentação para obter mais informações sobre o Manipulador de autenticação SAML 2.0.
OAuth/SSO
Consulte a Documentação de Logon único (SSO) para obter informações sobre o uso do Manipulador de autenticação SSO do AEM.
A interface com.adobe.granite.auth.oauth.provider
pode ser implementada com o provedor OAuth de sua escolha.
O AEM as a Cloud Service tem sessões adesivas baseadas em cookies habilitadas, o que garante que um usuário final seja roteado para o mesmo nó de publicação em cada solicitação. Para aumentar o desempenho, o recurso de token encapsulado está habilitado por padrão, de modo que o registro do usuário no repositório não precise ser referenciado em cada solicitação. Se o nó de publicação com o qual um usuário final tem afinidade for substituído, o registro da ID do usuário estará disponível no novo nó de publicação, conforme descrito na seção de sincronização de dados abaixo.
Existem várias abordagens para dados persistentes, dependendo da natureza desses dados.
As informações do perfil do usuário podem ser escritas e lidas de duas maneiras:
com.adobe.granite.security.user
do UserPropertiesManager, que colocará os dados sob o nó do usuário em /home/users
. Certifique-se de que as páginas exclusivas por usuário não sejam armazenadas em cache.Os dados do usuário final podem ser enviados a fornecedores terceirizados, como CRMs, recuperados por meio de APIs após o logon do usuário no AEM, armazenados (ou atualizados) no nó de perfil do usuário e usados pelo AEM conforme necessário.
É possível obter acesso em tempo real a serviços de terceiros para recuperar atributos de perfil. No entanto, é importante garantir que isso não afete diretamente o processamento de solicitações no AEM.
As políticas de acesso do nível de publicação, também chamadas de Grupos de usuários fechados (CUGs), são definidas no autor do AEM, conforme descrito aqui. Para restringir determinadas seções ou páginas de um site para alguns usuários, aplique os CUGs conforme necessário usando o autor do AEM, conforme descrito aqui, e replique-os no nível de publicação.
Independentemente do logon, um código personalizado também pode manter e gerenciar as associações de grupo de um usuário, conforme exigido pelos requisitos exclusivos de uma organização.
Os usuários finais do site têm uma expectativa de experiência consistente em cada solicitação de página da Web ou mesmo ao fazerem logon usando um navegador diferente; mesmo sem o conhecimento deles, eles são trazidos para diferentes nós de servidor da infraestrutura do nível de publicação. O AEM as a Cloud Service realiza isso sincronizando rapidamente a hierarquia de pastas /home
(informações de perfil do usuário, associação de grupo etc.) em todos os nós do nível de publicação.
Ao contrário de outras soluções do AEM, a sincronização de usuários e associações de grupos no AEM as a Cloud Service não usa uma abordagem de mensagens ponto a ponto. Em vez disso, ela implementa uma abordagem de assinatura de publicação que não requer configuração de clientes.
Por padrão, a sincronização de perfis de usuário e associações de grupos não está habilitada e, portanto, os dados não serão sincronizados ou mantidos permanentemente no nível de publicação. Para habilitar o recurso, envie uma solicitação ao Suporte ao cliente indicando o programa e os ambientes apropriados.
As solicitações HTTP autenticadas podem ser difíceis de armazenar em cache no CDN e no Dispatcher, pois elas apresentam a possibilidade de um estado específico do usuário ser transferido como parte da resposta da solicitação. O armazenamento inadvertido de solicitações autenticadas em cache e sua veiculação em outros navegadores solicitantes pode resultar em experiências incorretas ou até mesmo no vazamento de dados do usuário ou protegidos.
As abordagens para manter uma alta capacidade de cache das solicitações e, ao mesmo tempo, permitir respostas específicas do usuário incluem: