Configure OAuth ou OpenID Connect para aplicações personalizadas

ADSelfService Plus suporta logins SSO para qualquer aplicação empresarial personalizada habilitada para OAuth ou OpenID Connect. Neste documento, veja os passos para configurar o SSO baseado em OpenID Connect para aplicações personalizadas.

Passos para criar uma aplicação personalizada no ADSelfService Plus

Pré-requisito

1. Faça login no service provider (SP) usando credenciais de administrador. O SP é a aplicação personalizada para a qual você deseja configurar o OpenID Connect.
2. Copie o(s) Authorization redirect or callback URL(s) do SP.

Etapas de configuração

1. Faça login no ADSelfService Plus usando credenciais de administrador.
2. Navegue até Configuration > Self-Service > Password Sync/Single Sign On.
3. Clique em Add Application.
4. Clique na opção Custom Application no painel esquerdo.
5. Insira um Name e uma Description adequados para a aplicação.
6. Insira o Domain Name da sua conta de aplicação. Por exemplo, se seu nome de usuário for johndoe@thinktodaytech.com, então thinktodaytech.com é seu nome de domínio.
7. Escolha as políticas que deseja atribuir no menu suspenso Assign Policies.
8. Você também pode adicionar um icon pequeno ou grande da aplicação, se desejar.
9. Na aba SSO, selecione Enable Single Sign-On.
10. No menu suspenso Select Sign-on Method, escolha OAuth/OpenID Connect.
11. No menu suspenso Supported SSO Flow, escolha SP-Initiated ou IdP-Initiated.
Nota: É recomendável contatar a equipe de suporte da sua aplicação SP e verificar o(s) fluxo(s) SSO suportado(s) antes de escolher o fluxo SSO suportado.

Se selecionar o fluxo SP-Initiated



Fig. 1: Escolhendo o fluxo SP-Initiated no menu suspenso Supported SSO Flow para definir como a solicitação SSO será iniciada pelo Service Provider.

1. Insira o URL da página de login do service provider no campo SP Login Initiate URL.
Nota: Alguns apps exigem que o login comece pela página de login deles, conhecido como login iniciado pelo SP. Os usuários são primeiro direcionados para a página de login do app, especificada no campo SP Login Initiate URL, após o que o SP os redireciona para o ADSelfService Plus, o identity provider (IdP), para autenticação.

Se selecionar o fluxo IdP-Initiated



Fig. 2: Escolhendo o fluxo IdP-Initiated no menu suspenso Supported SSO Flow para definir como a solicitação SSO será iniciada pelo identity provider.

• No campo IdP Login Initiate URL, insira o URL da aplicação para o qual o IdP envia o id_token, permitindo que o SP complete o processo de login. Uma vez configurado este URL, os usuários poderão fazer login na aplicação clicando naquela aplicação específica no portal do usuário do ADSelfService Plus.
12. No campo SSO Redirect URL(s), insira todos os Authorization redirect ou callback URLs disponíveis obtidos do seu SP no passo 2 dos pré-requisitos. O(s) URL(s) podem ser encontrados na página de configuração OAuth/OIDC SSO do SP.
13. No menu suspenso Client Authentication, escolha o método de autenticação do cliente conforme a exigência do service provider (SP). Este modo determina como o IdP autenticará a solicitação do token de acesso do SP.



Fig. 3: Escolhendo o modo de autenticação do cliente apropriado no menu suspenso para definir como o IdP autenticará a solicitação do token de acesso do SP.

• Client Secret: Um modo unificado que inclui os seguintes métodos:
• Client Secret Basic: O SP codifica o client_id e client_secret em Base64 e os inclui no cabeçalho Authorization da solicitação do token de acesso.
• Client Secret Post: O SP inclui o client_id e client_secret no corpo da solicitação ao enviar a requisição do token de acesso.
• Client Secret JWT: O SP gera um JWT (JSON Web Token) usando o client_secret para assinar digitalmente a solicitação.

O IdP valida as credenciais ou assinatura para autorizar a solicitação.



Fig. 4: Escolhendo o modo de autenticação Client Secret.

• Private Key JWT: O SP fornece uma URL JWKS (JSON Web Key Set) contendo sua chave pública. Durante as solicitações do token de acesso, o SP usa sua chave privada para assinar o JWT. O IdP verifica essa assinatura usando a chave pública obtida da URL JWKS.
• None: Nenhuma autenticação do cliente está envolvida, tornando esta opção adequada para aplicações de página única que não podem armazenar client secrets com segurança. Se esta opção for selecionada, PKCE (Proof Key for Code Exchange) é automaticamente selecionado e torna-se obrigatório para segurança adicional. Certifique-se de que sua aplicação cliente suporte PKCE para completar a autenticação do usuário com sucesso.



Fig. 5: Escolhendo o modo de autenticação None.

14. Habilite a caixa de seleção Enforce PKCE for verification para aumentar a segurança durante o processo de verificação da solicitação do token. Esta opção é aplicável para todos os modos de autenticação do cliente, exceto None.



Fig. 6: Aplicando PKCE para aumentar a segurança durante o processo de verificação nos modos Client Secret/Private Key JWT.

15. Ao escolher Private Key JWT como método de autenticação do cliente, o ADSelfService Plus precisará dos detalhes da JWKS URL do SP para obter a chave pública, que será usada para verificar a assinatura.



Fig. 7: Escolhendo o modo de autenticação Private Key JWT.

16. No menu suspenso Key Algorithm, escolha o algoritmo apropriado: HS256, RS256, RS384, ou RS512.

Nota: O Key Algorithm é o algoritmo usado para assinar tokens, como o id_token ou access_token. Usar um algoritmo para assinar tokens garante a integridade e autenticidade do token.



Fig. 8: Escolhendo o algoritmo de chave apropriado (HS256, RS256, RS384 ou RS512) no menu suspenso para definir como o access token será assinado.

HS256: Um algoritmo simétrico que usa um segredo compartilhado (ou seja, client_secret gerado durante a criação da aplicação personalizada no IdP) para assinar e validar o token, em vez de usar um par de chaves públicas.

RS256: Assinatura RSA com SHA-256. É um algoritmo assimétrico que usa um par de chaves pública ou privada, gerado e gerenciado pelo IdP (o IdP usa a chave privada para gerar a assinatura, e a aplicação usa a chave pública para validar a assinatura).

RS384: Igual ao RS256, exceto que usa o algoritmo de hash SHA-384 para criar a assinatura RSA.

RS512: Igual ao RS256, exceto que usa o algoritmo de hash SHA-512 para criar a assinatura RSA.

17. O campo Access Token Validity está definido como 3600 segundos por padrão. Você pode alterar esse valor, se necessário.

Nota: Access Token Validity indica o limite de tempo durante o qual o token enviado pelo IdP estará acessível pelo SP.

18. Marque a caixa Allow Refresh Token para permitir que o SP obtenha access tokens sem precisar que o usuário se reautentique a cada vez.
19. Clique em Advanced Configuration no canto superior direito.
20. Em OAuth/OpenID Connect Claim Attributes Configuration, mapeie os atributos conforme sua necessidade.



Fig. 9: Mapeando atributos do usuário em OAuth/OpenID Connect Claim Attributes Configuration.

21. Clique em Create Custom Application.

Os usuários que se enquadram nas políticas escolhidas em step 7 agora podem entrar na aplicação personalizada pelo portal do usuário usando SSO.