Ao configurar a autenticação personalizada, você gerencia o processo de autenticação e personaliza a experiência de logon no aplicativo do AEM Mobile. A experiência de logon da autenticação personalizada aparece no aplicativo como uma exibição da Web de tela inteira que você projeta.

Experiências personalizadas de logon

Os seguintes formatos são aceitos:

  • SAML 2.0, incluindo suporte para MFA/OKTA e Gigya.
  • OAuth 2.0, incluindo logons de compartilhamento em redes sociais como Facebook ou Gmail.
  • Genérico, que permite que você crie seu próprio comportamento de logon e interaja com seu serviço de direito.

Por exemplo, você pode permitir que seus representantes de vendas façam logon no aplicativo usando seu email e senha juntamente com a verificação de OKTA (SAML 2.0). Ou, você pode permitir que os clientes façam logon no aplicativo usando suas contas do Gmail ou Facebook (OAuth 2.0). O aplicativo obtém tokens de autorização desses provedores de identidade, os quais você pode usar em seu serviço de direito para autorizar o conteúdo para os usuários. Ao aproveitar a setAuthToken API, você pode expandir seus métodos de autenticação de várias maneiras, inclusive usar mais de um método de autenticação no mesmo aplicativo.

Os provedores de identidade genéricos permitem dois casos de uso alternativos de autenticação, incluindo:

  • Fornecer uma interface personalizada como um formulário em HTML em vez de usar o prompt padrão de nome do usuário e senha.
  • Criar uma experiência de logon em um artigo em vez de seguir o processo de autenticação padrão.

 

Observe que um serviço de direito que usa Direct Entitlement APIs v2 ainda assim será necessário para autorizar o conteúdo para os usuários.

As APIs são fornecidas para o cliente determinar se o usuário é autenticado, obter o token de autenticação e iniciar a exibição da Web da interface de logon. Consulte Usar plug-ins do Cordova específicos para o AEM Mobile.

 

Vídeo sobre autenticação personalizada

Vídeo sobre autenticação personalizada
Vídeo de introdução à autenticação personalizada.

Configurar a autenticação personalizada

Os provedores de identidade são configurados nas Configurações principais e aplicados a um projeto nas Configurações de projeto. Você pode criar vários provedores de identidade no nível da Conta mestre para uso em projetos.

  1. Configure um serviço de direito para trabalhar com o AEM Mobile.

    Mesmo se você ativar um serviço de autenticação personalizada, um serviço de direito que usa as Direct Entitlement APIs v2 é necessário para autorizar o conteúdo para os usuários. Consulte Configurar direitos em aplicativos do AEM Mobile.

  2. Configure um provedor de identidade SAML 2.0, OAuth 2.0 ou genérico para uso com o AEM Mobile e seu serviço de direito.

    Provedor de identidade do Google

    Para ver um exemplo de como configurar um provedor de identidade do Google, consulte este arquivo PDF (apenas em inglês):  

    Download

    Provedor de identidade do Facebook

    Para ver um exemplo de como configurar um provedor de identidade do Facebook, consulte este arquivo PDF (apenas em inglês):

    Download

    Provedor de identidade genérico

    Para ver um exemplo de como configurar um provedor de identidade genérico, consulte este exemplo (apenas em inglês):

    Download

    Para assistir a um vídeo sobre provedores de identidade genéricos, acesse Vídeo sobre IdP genérico (apenas em inglês).

    Gigya

    Você pode usar o Gerenciamento de identidade de clientes do Gigya como um provedor de identidade que permite que os clientes façam logon usando métodos tradicionais e por meio de várias redes sociais, como Facebook, Google e LinkedIn. Para ver um exemplo de como configurar um provedor de identidade do Gigya, consulte este exemplo (apenas em inglês):

    Download

    Veja este artigo AEM Mobile na documentação Gigya.

     

    Observação:

    O fluxo de trabalho de autenticação do Gigya é baseado em cookies definidos nos navegadores dos usuários. A autenticação do Gigya pode falhar nos aplicativos do AEM Mobile quando esses cookies forem bloqueados pelo aplicativo após serem detectados como cookies de terceiros. Se cookies bloqueados de terceiros estiverem impedindo a autenticação correta do fluxo de trabalho do Gigya, você poderá implementar uma solução alternativa conforme descrito na documentação do Gigya: Cookies de terceiros bloqueados (apenas em inglês).

     

    O código exemplo do serviço de autorização inclui suporte para autenticação personalizada. Para obter detalhes, consulte Configurar um serviço de direito.

  3. Faça logon no portal sob demanda usando uma conta de Administrador mestre. Clique nas Configurações principais, e clique na guia Provedores de identidade.

  4. Clique no ícone Criar provedor de identidade (+) e especifique o nome do provedor de identidade e o tipo (OAuth 2.0, SAML 2.0 ou Genérico).

  5. Especifique as informações do seu provedor de identidade. Consulte as descrições das opções, posteriormente neste documento.

  6. Para configurar a confiança entre seu provedor de identidade e o aplicativo do AEM Mobile, copie o valor do Endpoint de resposta do Experience Manager Mobile (SAML 2.0) ou do Endpoint de redirecionamento do Experience Manager Mobile (OAuth 2.0) e adicione-o à configuração do seu provedor de identidade.

    Essas informações dizem ao serviço como informar os resultados do processo de autenticação ao AEM Mobile. Por exemplo, o token de autenticação retornado do Facebook é diferente do token do seu serviço de direito para aquele usuário. Em seu serviço de direito, é necessário mapear o token de autenticação do Facebook para o usuário. Deste modo, quando o AEM Mobile chamar os direitos, o serviço de direito retornará a resposta correta. O usuário será autorizado a exibir o conteúdo ao fazer logon.

  7. No portal sob demanda, vá para Configurações de projeto, edite o projeto e clique na guia Acesso. Selecione “Ativar autenticação personalizada” e escolha o provedor de identidade apropriado criado nas Configurações principais.

  8. Crie um aplicativo de não comprovação e teste a configuração de autenticação personalizada.

Configurações do SAML 2.0

ID do provedor de serviços – o valor que o AEM Mobile usará para identificar-se ao enviar uma solicitação de autenticação para o provedor de identidade. A ID do provedor de serviços deve ser registrada com o provedor de identidade.

Vínculo de protocolo – define o vínculo de protocolo do SAML a ser usado para enviar solicitações de autenticação ao provedor de identidade. Há suporte para os vínculos de protocolo POST e REDIRECT.

Formato da ID do nome – se especificado, o serviço de direito do AEM Mobile solicitará o identificador do assunto da resposta para usar o formato especificado: Nenhum, Persistente, Transitório ou Não especificado. Use “Não especificado” para provedores de identidade do Gigya.

Origem do token de autenticação – especifica qual parte da resposta de autenticação contém o token de autenticação. Se você usar o Atributo, especifique o nome de um atributo na resposta de autenticação que contém o token de autenticação. Se o Formato da ID do nome estiver definido como Transitório, você pode selecionar ID do nome.

URL de autenticação – o URL do provedor de identidade para o qual o AEM Mobile deve encaminhar a solicitação de autenticação.

Certificado de chave de assinatura pública – o certificado X509 da chave de assinatura pública do provedor de identidade utilizada pelo AEM Mobile para validar a assinatura de asserção.

Expiração da sessão padrão – o número de segundos em que uma resposta de logon concluída com êxito é válida se uma duração não for especificada explicitamente na resposta. Uma vez expirada, a sessão será atualizada, se suportado pelo provedor de identidade; caso contrário, o usuário será desconectado. O padrão é uma hora (3600 s).

Endpoint de resposta do Experience Manager Mobile – URL para o qual o provedor de identidade precisa enviar a resposta de asserção. Você deve configurar seu provedor de identidade para usar esse valor fornecido pelo AEM Mobile.

Certificado da chave de criptografia pública do Experience Manager Mobile – o certificado X509 da chave de criptografia pública que pode ser usada pelo provedor de identidade para criptografar a chave na resposta de autenticação, se necessário.

Configurações do OAuth 2.0

Tipo de concessão de autorização – determina o tipo de concessão de autorização: Código de autorização ou Implícita.

Endpoint do token – usado pelo AEM Mobile para trocar um código de autorização ou atualizar o token para um token de acesso. HTTPS é altamente recomendado.

Segredo do cliente – o AEM Mobile usa este valor para autenticar-se ao contatar o endpoint do token. O segredo do cliente que você especificar precisa ser registrado com o provedor de identidade.

Expiração da sessão padrão – o número de segundos em que uma resposta de logon concluído com êxito é válida se uma duração não for especificada explicitamente na resposta. Uma vez expirada, a sessão será atualizada, se suportado pelo provedor de identidade; caso contrário, o usuário será desconectado. O padrão é uma hora (3600 s).

Endpoint de autorização – usado pelo AEM Mobile para obter a autorização do provedor de identidade. HTTPS é altamente recomendado.

Identificador do cliente – o AEM Mobile usa este valor para identificar-se ao contatar o provedor de identidade. O identificador do cliente precisa ser registrado com o provedor de identidade.

Escopo do token de acesso – descreve o escopo da solicitação de acesso. Use espaços para especificar vários valores. Exemplos do Facebook: public_profile, email, user_likes, user_friends.

Endpoint de redirecionamento do Experience Manager Mobile – especifica o URL do AEM Mobile para o qual o provedor de identidade deve redirecionar após concluir o processo de autorização. Esse valor fornecido pelo AEM Mobile precisa ser registrado com o provedor de identidade.

Configurações genéricas

URL de autenticação – especifique o URL do site que inclui a interface do comportamento de logon. Esse site deve incluir informações que transmitem o token de autenticação ao serviço de direito quando o usuário faz logon.

Expiração da sessão padrão – o número de segundos em que uma resposta de logon concluído com êxito é válida se uma duração não for especificada explicitamente na resposta. Uma vez expirada, a sessão será atualizada, se suportado pelo provedor de identidade; caso contrário, o usuário será desconectado. O padrão é uma hora (3600 s).

Notas e práticas recomendadas da Autenticação personalizada

  • Depois de criar o provedor de identidade nas configurações principais, não é possível alterar o tipo do provedor de identidade (SAML 2.0 ou OAuth 2.0). Para alterar o tipo, será necessário criar um novo provedor de identidade.
  • A alteração do provedor de identidade em um projeto ativo desconectará todos os usuários.
  • O SAML não oferece suporte à atualização. No fim de uma sessão, o usuário precisa fazer logon novamente. Isso também acontece no OAuth, se o provedor do OAuth não oferece suporte à atualização de tokens.
  • A desconexão em um dispositivo não desconectará o usuário do provedor de identidade. O provedor de identidade determina quanto tempo a sessão permanecerá válida.

Esta obra está licenciada sob uma licença não adaptada da Creative Commons Attribution-Noncommercial-Share Alike 3.0  As publicações do Twitter™ e do Facebook não são cobertas pelos termos do Creative Commons.

Avisos legais   |   Política de privacidade online