Configurando o Single Sign-On do OpenID na aplicação personalizada

Editar online

Use o OpenID Connect para o logon único, a fim de permitir que os aplicativos verifiquem a identidade de seus usuários com base na autenticação realizada pelo Verify. Os usuários não precisam se inscrever para obter uma conta no aplicativo. Os usuários são redirecionados para Verify para fazer o login. Verify verifica a identidade dos usuários, envia as informações por meio de um token de identificação e confirma com a parte confiável que os usuários estão autorizados a acessar e utilizar o recurso. https://<tenant-host>/oidc/endpoint/default/.well-known/openid-configurationEste aplicativo utiliza o provedor Connect do OpenID com o endpoint de descoberta.

Antes de começar

Observação: há uma alternativa para esta tarefa disponível em Registro dinâmico de clientes.

Deve-se ter permissão administrativa para concluir esta tarefa.
Abra pelo menos duas janelas do navegador para concluir a configuração. Um para o Verify console de administração e outro para o console de administração do aplicativo de destino.
- Faça login no console IBM® Verify de administração como administrador.
- Efetue login no console de administração do aplicativo de destino com sua conta do Administrador.
É necessário definir as informações básicas da instância da aplicação na guia Geral. Consulte a seção “Configurando os detalhes básicos do aplicativo ”.

Sobre esta tarefa

Verify Os modelos de aplicativos predefinidos não possuem a opção de login do OpenID Connect. Use o modelo de aplicativo personalizado para configurar um aplicativo que atue como uma parte confiável ou um aplicativo cliente do OpenID Connect, delegando a autenticação dos usuários ao Verify.

Configure Verify o sistema e a parte confiável para que possam se comunicar entre si. Para habilitar o logon único do OpenID Connect, é necessário fornecer:

Verify com determinados dados da parte confiável.
A parte confiável com determinados dados de Verify.

Você pode configurar IBM Verify Access aplicativos móveis como partes confiáveis do OpenID.

Procedimento

Vá até a guia "Login".
No método de login, selecione “ OpenID ” (Conectar-se) e “ 1.0 ”.

Forneça Verify informações básicas sobre a parte confiável.


Campo	Descrição
URL do aplicativo	Trata-se do endereço de inicialização do logon único URL, utilizado para fazer login na parte confiável OpenID Connect. O aplicativo utiliza este endereço URL para solicitar Verify o token de identificação que contém os dados do usuário. Quando os usuários acessam o aplicativo através deste link URL, eles são redirecionados para Verify para autenticação. É possível obter essas informações da parte confiável ao configurar um provedor de autorização ou um provedor de conexão OpenID em seu site.
Tipos de Concessão	Isso indica o mecanismo que a parte confiável pode usar para recuperar o token de identificação de Verify. Verify aceita os seguintes tipos de subsídio: Código de autorização Observação: o código de autorização é pré-selecionado como o tipo de concessão padrão, com o PKCE também selecionado por padrão. Implícito Fluxo de dispositivo Observação: Se você selecionar “Fluxo do dispositivo”, também poderá gerar um código QR. Autorização baseada em contexto Portador de JWT Observação: Se você selecionar JWT bearer, terá a opção de configurar `JWKS URI`, `JWT bearer user identification` e `JWT bearer default identity source`. Para obter mais informações sobre como usar o tipo de concessão JWT Bearer, consulte Tipos de concessão. Qualquer combinação de código de autorização, implícito, fluxo de dispositivo e ROPC. Deve-se selecionar pelo menos um tipo de concessão. Se o ROPC for o único tipo de concessão selecionado, a seção Políticas de Acesso não será exibida. Consulte Tipos de subsídio para uma comparação rápida dos tipos de subsídio disponíveis e para determinar qual tipo de subsídio definir para a solicitação.
ID do Cliente	É o identificador público exclusivo atribuído ao aplicativo cliente, que é a parte confiável do OpenID Connect. O servidor de autorização usa essas informações para identificar a parte confiável e a solicitação de autorização. Essas informações são geradas automaticamente após você salvar o aplicativo personalizado do OpenID Connect. Você deve fornecer essas informações à parte confiável ao configurar Verify o OpenID Connect como provedor na consola de administração do aplicativo. A parte confiável usa o ID do cliente sempre que solicita um token de acesso.
Segredo do Kubernetes	O arquivo YAML secreto do Kubernetes é usado para se conectar ao Red Hat OpenShift. Deve-se fazer o download do arquivo YAML secreto do Kubernetes para obter os metadados.
Cliente público (nenhum segredo do cliente)	Indica que o cliente não tem nenhum segredo que precisa ser fornecido pelo aplicativo. Observação: quando selecionado, o campo “Segredo do cliente” fica oculto e os seguintes algoritmos são removidos das opções de “Algoritmo de assinatura ”: HS256 HS384 HS512 Gerar um segredo de cliente somente se o tipo de cliente for confidencial. Clientes confidenciais podem manter o ID do cliente e o segredo de uma maneira segura e não mostram essas credenciais para partes não autorizadas. Um segredo de cliente deve ser conhecido somente pelo aplicativo cliente e pelo servidor de autorização.
Segredo do cliente	Esses dados são usados juntamente com o ID do cliente para autenticar a parte confiável e para trocar um código de autorização por um token de ID. Essas informações são geradas automaticamente após você salvar o aplicativo personalizado do OpenID Connect. Você deve fornecer essas informações à parte confiável ao configurar Verify o OpenID Connect como provedor na consola de administração do aplicativo.
Método de autenticação de cliente	Indica o método de autenticação para terminais como o terminal de token que requerem autenticação de cliente. Verificar suporta os métodos de autenticação de cliente a seguir: Padrão Configuração básica de segredo do cliente POST de segredo do cliente JWT de segredo do cliente JWT de chave privada Se deixados como padrão, tanto a configuração básica quanto o POST de segredo do cliente são permitidos. Se a parte confiável suportar isso, use o JWT de chave privada como a configuração. Para obter mais informações sobre o JWT com segredo de cliente e o JWT com chave privada, consulte Criar o JWT com segredo de cliente e o JWT com chave privada.
Validar o JTI de asserção de cliente	Indica se o JTI no JWT de asserção de cliente é validado para uso único. Esta opção é exibida apenas quando o JWT de segredo do cliente ou o método de autenticação de cliente de JWT de chave privada é selecionado.
Chaves permitidas de verificação de assinatura	Os IDs de chave de verificação de assinatura que podem ser usados para verificar o JWT de asserção de cliente. Esta opção é exibida apenas quando o método de autenticação de cliente de JWT de chave privada é selecionado.
Requer uma verificação de chave de prova para troca de código (PKCE)	O PKCE é usado para minimizar os ataques de intercepção de código de autorização. Ele requer um desafio de código antes que o fluxo de código de autorização possa continuar. Essa opção é exibida somente quando o fluxo de concessão do código de autorização é selecionado.
URIs de Redirecionamento	É o endereço de retorno URL; o endereço para Verify o qual a parte confiável envia sua resposta de autenticação. Os usuários são redirecionados para URL após serem autenticados e autorizados pelo Verify. Deve-se especificar ao menos um URI. Se o URI de retorno de chamada é o domínio de aplicativo, ele pode ser o domínio do locatário. Observação: o domínio pode conter um caractere curinga. Embora os caracteres curinga não sejam suportados no caminho da URI, o caractere "*" é um caractere válido no caminho da URI e é tratado como uma sequência de caracteres literal. É possível incluir um máximo de 400 URIs. É possível obter essas informações da parte confiável ao configurar um provedor de autorização ou um provedor de conexão OpenID em seu site.
URI do JWKS	O URI no qual a parte dependente publica suas chaves públicas no formato JSON Web Keys (JWKs). Esse URI é usado para verificação de assinatura do JWT. O sistema pode rejeitar um URI do JWKS inacessível ou não responsivo. O sistema também pode rejeitar a URL do JWKS caso o tamanho do JWKS seja muito grande. Se a parte dependente não publicar um URI do JWKS, uma chave pública poderá ser incluída no sistema na forma de um certificado X509. Consulte "Gerenciamento de certificados". O `Nome Fácil` associado ao certificado público é o valor do cabeçalho do ID da chave (kid) do JWT.
Identificação do usuário do portador de JWT Disponível somente para o tipo de concessão de portador de JWT.	Esta configuração informa ao sistema como o sujeito (sub) do portador de JWT é interpretado para identificar o Usuário que está associado a este token de acesso do JWT. O sub pode ser o `User ID`, o `Username` ou o `External ID`.
Fonte de identidade padrão do portador de JWT Disponível somente para o tipo de concessão de portador de JWT.	Se o JWT não especificar a região, ele será a região de origem de identidade padrão à qual o usuário que é identificado pelo sub pertence. Quando a opção `JWT bearer user identification` é configurada como `User ID`, essa configuração não é aplicável.

Se você estiver editando um aplicativo existente, será possível usar as opções de segredo do cliente a seguir:

Selecione para visualizar o segredo do cliente.
Selecione para ocultar o segredo do cliente.
Selecione para copiar o ID do cliente ou o segredo para a área de transferência.
Selecione para visualizar os segredos de cliente atualizados.
- Selecione um ou mais segredos de cliente renovados na lista e clique em Excluir para excluí-los.
Selecione para gerar um novo segredo de cliente. Use essa opção se você achar que o segredo do cliente está comprometido. Se você gerar novamente o segredo do cliente, deverá atualizar o segredo do cliente em todos os clientes do OAuth para o aplicativo.
- Marque a caixa de seleção “Manter o segredo atual ” para adicionar o segredo do cliente atual à lista de segredos de cliente alternados.
- Se a caixa de seleção “Manter o segredo atual” estiver marcada, selecione a descrição do segredo do cliente e a data de validade (na hora local do navegador). Se não for selecionado nenhum prazo de validade, será aplicada a duração do segredo rotativo do locatário definida nas configurações do aplicativo.
- Os segredos de cliente atualizados são submetidos a um processo de hash e não podem mais ser recuperados em texto simples, mas ainda podem ser usados até a data de validade selecionada.
- Após a confirmação, o segredo do cliente é imediatamente atualizado. O novo segredo do cliente é exibido na tela.

Configure o token de acesso e a validação do token de atualização para limitar o tempo de acesso não autorizado quando esses tokens forem roubados.

O token de acesso é usado para autorizar o acesso ao recurso protegido. Após o token de acesso expirar, a autorização será revogada.

Tabela 1. Configurações do token
Campo	Descrição
Validade do token de acesso (s)	Configura o tempo em segundos após o qual o token de acesso expira. Configure uma validação do token de acesso para limitar o tempo de acesso de um invasor ao recurso com o token roubado quando o aplicativo cliente estiver comprometido. Somente números inteiros positivos são permitidos. O valor padrão é de `7200` segundos. O valor mínimo permitido é de `1` segundo e o valor máximo é de `2147483647` segundos.
Acessar Formato de Token	Indica se o token de acesso é gerado como uma sequência de caracteres opaca, que é a`Default`configuração ou no formato JWT.
Público	Especifica os destinos que são os destinatários do token. Esses valores estão listados na solicitação aud para tokens formatados por JWT e na carga útil de introspecção como uma única sequência ou uma matriz de sequências.
Mapeamento de atributo de introspecção	Essa lista de mapeamento de atributos é usada para incluir solicitações na carga útil de introspecção e o token de acesso no formato JWT.
Nome do Atributo	Nome do atributo que a parte confiável utiliza e exige da Verify. Os seguintes nomes de atributos não podem ser usados: aud, exp, groupIds, groupUids at_hash, c_hash, rt_hash, s_hash, iat,, iss, nonce, sub, client_id, grant_id, grant_type e scope.
Atributos	Lista todas as fontes de atributos que você definiu para cada tipo em Diretório > Atributos. O valor de sua origem de atributo selecionada é designado como o valor de atributo para o nome de atributo definido da parte confiável no token de ID.
Gerar um token de atualização	Indica se o aplicativo cliente pode solicitar e usar um token de atualização para obter um novo token de acesso do servidor de autorização do provedor de identidade OpenID Connect. Use esta opção apenas se o aplicativo pretender usar o token de acesso para realizar operações por meio de Verify APIs. Só é necessário obter um novo token de acesso se o anterior expirou. Esta opção não é relevante se você selecionou "Implícito" como o Tipo de concessão.
Validade do token de atualização (s)	Configura o tempo em segundos após o qual o token de acesso expira. Essa configuração determina a frequência com que o usuário pode autenticado novamente. Defina o prazo de validade do token de atualização para garantir que o usuário repita a operação completa de Verify logon único após um certo tempo. Essa opção é exibida somente se você ativou Gerar Token de Atualização. Um token de atualização é usado para obter um novo token de acesso e continuar o acesso ao recurso protegido. Somente números inteiros positivos são permitidos. O valor padrão é de `604800` segundos. O valor mínimo permitido é de `1` segundo e o valor máximo é de `2147483647` segundos.
Renovar tempo de vida do token de atualização	Essa opção indica se o tempo de vida do token de atualização é renovado quando um token de atualização é usado para obter um novo conjunto de tokens. Quando essa caixa de seleção é marcada, o tempo de vida configurado por Validade do token de atualização é renovado cada vez que os tokens de atualização são atualizados. Se ela não estiver selecionada, o token de atualização renovado expirará quando a Validade do token de atualização original for atingida.

Especifique as opções de assinatura e criptografia do token de identificação. A parte confiável utiliza a assinatura para verificar a integridade e a autenticidade das informações do usuário contidas no token, bem como do provedor de identidade do OpenID Connect que assinou o token. O token pode ser criptografado para que somente o terceiro confiável possa decriptografá-lo.

Tabela 2. Opções de assinatura e criptografia
Campo	Descrição
Algoritmo de assinatura	O algoritmo utilizado Verify para assinar o token de identificação. VerifyO algoritmo deve corresponder ao que a parte confiável registrou. Escolha entre os seguintes algoritmos de hash para verificar a assinatura: HS256 HS384 HS512 ES256 ES384 ES512 PS256 PS384 PS512 RS256 (valor padrão) RS384 RS512 Nota: Se o algoritmo de assinatura ES256 for selecionado, o certificado deverá ser ECDSA com P-256. Se o algoritmo de assinatura ES384 for selecionado, o certificado deverá ser ECDSA com P-384. Se o algoritmo de assinatura ES512 for selecionado, o certificado deverá ser ECDSA com P-521. Os algoritmos HS não são exibidos quando você escolhe não gerar um segredo do cliente.
Certificado de assinatura	Esta opção será exibida somente se você tiver selecionado algum dos algoritmos de assinatura a seguir: RS, ES ou PS. Use esse certificado para assinar o token de ID durante uma conexão única. A seleção padrão refere-se ao certificado pessoal padrão que você configurou em Segurança > Certificados > Certificados Pessoais.
Algoritmo de Criptografia	O algoritmo criptográfico usado para criptografar ou determinar o valor da chave de criptografia de conteúdo (CEK). São suportados os seguintes algoritmos: RSA-OAEP RSA-OAEP-256
Algoritmo de conteúdo	O algoritmo de criptografia de conteúdo que é usado para executar criptografia autenticada no texto simples para produzir o texto cifrado e a tag de autenticação. São suportados os seguintes algoritmos: A128GCM A192GCM A256GCM
Chave de Criptografia	O rótulo de certificado ou o ID de chave da chave a usar para criptografia.

Mapeie os atributos do usuário que Verify o sistema suporta e fornece à parte confiável por meio do token de identificação.

Verify pode ampliar o esquema padrão de reivindicações JSON para incluir atributos adicionais, como função do funcionário, gerente e departamento.

Observação: Os seguintes atributos já são adicionados ao token de identificação por padrão: userType, uniqueSecurityName, displayName, realmName name, preferred_username, jti,, at_hash, ext. Alguns desses atributos podem ser removidos do token de identificação mapeando-os para uma fonte de atributos configurada para não retornar nenhum valor.

A seção “Mapeamentos de atributos ” é composta pelos seguintes elementos, descritos na Tabela 3.

Uma opção de caixa de seleção para enviar todos os atributos do usuário conhecidos.
Opção para adicionar nomes de atributos e suas respectivas fontes de atributos em Verify.

Tabela 3. Mapeamentos de atributos
Informações	Descrições
Enviar todos os atributos de usuário conhecidos no token de ID	Quando selecionada, todos os atributos de credenciais de usuário conhecidos disponíveis na fonte de identidade do provedor OpenID Connect são automaticamente incluídos no token de identificação. Os atributos de credencial do usuário conhecido consistem em: Atributos padrão Esses atributos provêm do Verify Cloud Directory, que inclui os atributos integrados exibidos em Diretório > Atributos. Atributos estendidos Esses atributos são do provedor de identidade do SAML Enterprise que você configurou em Autenticação > Provedores de identidade. Caso contrário, defina somente os atributos específicos que a parte confiável solicita no token de ID. Especifique o nome do atributo e a origem do atributo.
Nome do Atributo	VerifyNome do atributo que a parte confiável utiliza e exige. Os seguintes nomes de atributos não podem ser utilizados: aud, exp, groupIds, groupUids at_hash, c_hash, rt_hash, s_hash, iat, iss, nonce, client_id, grant_id,, grant_type e scope. Se o nome do atributo for `sub`, este mapeamento de atributos modifica o valor de `sub` na resposta de introspecção, no token de acesso JWT, na resposta de informações do usuário e no token de identificação.
Atributos	Lista todas as fontes de atributos que você definiu para cada tipo em Diretório > Atributos. O valor de sua origem de atributo selecionada é designado como o valor de atributo para o nome de atributo definido da parte confiável no token de ID. Observação: Se o atributo “Sem tag” for exibido para o valor de origem do atributo, isso significa que a finalidade do atributo foi alterada. Os aplicativos existentes que consomem o atributo podem continuar a usar o aplicativo até que o aplicativo seja remapeado para usar um atributo diferente para esse propósito. Por exemplo, se a caixa de seleção Conexão única (SSO) estiver desmarcada em um atributo existente, os aplicativos que já consumirem esse atributo para a SSO poderão continuar a usá-lo para a SSO. O mesmo comportamento se aplica aos mapeamentos de atributo de fornecimento quando o propósito Fornecimento é removido.

Selecione as origens de identidade e a política que determinam como os usuários podem acessar o aplicativo.
1. Selecione as origens de identidade que podem ser usadas para conectar-se a este aplicativo.
  
  A configuração padrão é permitir o acesso de todas as origens de identidade corporativas que estão configuradas para o locatário. Para limitar as origens de identidade que podem ser usadas para conectar-se ao aplicativo, marque Selecionar origens de identidade específicas suportadas. Selecione as caixas de seleção das origens da identidade nas quais você deseja permitir a conexão.
2. Selecione a política que determina como os usuários podem acessar o aplicativo.
  É possível continuar a usar a política de acesso padrão designada, que é Permitir acesso de todos os dispositivos. Como alternativa, você pode desmarcar a caixa de seleção e clicar no botão para escolher entre a lista de políticas de acesso predefinidas. Ao selecionar uma política de acesso, é possível aplicá-la aos tipos de concessão de API marcando a caixa de seleção correspondente a cada tipo de concessão. Para obter mais informações, consulte Políticas de acesso.
Selecione se deve ser pedido consentimento do usuário.
A solicitação para o consentimento do usuário pode ser incluída nos aplicativos do Open ID Connect. Ela está disponível para todos os tipos de concessão, exceto para Credenciais de Senha do Proprietário do Recurso (ROPC). Se ROPC for o único tipo de concessão que está selecionado para o aplicativo, a opção Consentimento do usuário será ocultada. Se o padrão, Solicitar consentimento, permanecer selecionado, o usuário será solicitado a fornecer consentimento explicitamente aos escopos e à autorizações de acesso à API. O usuário pode conceder ou negar permissão para acesso à API. Os aplicativos do Open ID Connect existentes não solicitam consentimento. Esses aplicativos devem ser editados caso se queira pedir o consentimento do usuário. Consulte “Gerenciamento de consentimentos de aplicativos ”.
Depois que o aplicativo for criado, o campo Tipo de consumo com o valor de Avançado será exibido em Pedir consentimento. O valor Avançado indica que os consentimentos do usuário são armazenados no DPCM. Os aplicativos customizados do OIDC mais antigos exibem esse campo após migrar os consentimentos para o DPCM.
Opcional: Restringir escopos personalizados.
Os escopos customizados podem ser solicitados por um cliente OIDC/OAuth nos fluxos de concessão de OIDC/OAuth suportados. Se Restringir escopos customizados estiver ativado, que é a configuração padrão, os escopos que são concedidos ao cliente no final do fluxo serão restringidos àqueles escopos especificados nessa seção. Se Restringir escopos customizados estiver desativado, quaisquer escopos customizados solicitados serão concedidos quando o fluxo for concluído.
openidObservação: os escopos padrão, profile, email, phone, e address não podem ser restringidos.
1. Certifique-se de que a caixa de seleção “Restringir escopos personalizados” esteja marcada.
2. Digite o nome do escopo customizado que você deseja conceder e uma descrição.
  O nome do escopo refere-se ao escopo OAuth2/OIDC que é solicitado por uma parte/cliente dependente. A descrição é uma explicação fácil para o escopo.
  
  Outro conjunto de campos de escopo é exibido.
3. Repita a etapa anterior para cada escopo customizado que você deseja conceder.
Opcional: Conceda permissões da API ao token de login.
Restringir o acesso da API é a configuração padrão para novos aplicativos. O aplicativo não tem autorizações de token de conexão. Para conceder autorizações de acesso à API execute as etapas a seguir.
1. Selecione o ícone de edição.
  O assistente de cliente da API de Edição é iniciado.
2. Selecione as permissões de usuário e não usuário que deseja conceder ao token de conexão.
  Se você marcar a caixa de seleção “Permissões padrão para tokens de usuário” ou desmarcar a caixa de seleção “Restringir acesso à API”, será concedido um conjunto de direitos padrão para tokens de usuário.
3. Selecione “Salvar ”.
Selecione “Salvar ”.

O quê fazer em seguida

Forneça à parte confiável as Verify informações necessárias para concluir a configuração do login do OpenID Connect entre Verify [nome] e a parte confiável. Consulte as instruções que são fornecidas na interface com o usuário.
Inclua autorizações de usuário ou do grupo para permitir acesso aos aplicativos configurados. Consulte “Gerenciamento de permissões de aplicativos” (pelo administrador ou pelo proprietário do aplicativo).
Aplique a autenticação de dois fatores para controle de segurança incluído nos usuários quando eles se conectam ao aplicativo configurado. Consulte “Configurando fatores de autenticação ”.