IBM Verify Bridge

O IBM® Verify Bridge componente oferece IBM acesso na nuvem aos atributos do usuário e à autenticação, controlados pelo LDAP local do cliente, pelo Active Directory ou por um banco de dados personalizado.

Introdução

O Verify Bridge permite o acesso a autenticação local via LDAP, Active Directory ou banco de dados personalizado, bem como a atributos de usuário a partir de IBM Verify componentes.

A principal conexão entre o Verify Bridge e o IBM Verify inquilino utiliza uma conexão do tipo " HTTP " ou uma conexão do tipo " HTTPS " (Long-Poll). Essa conexão é iniciada pelo Verify Bridge e requer um token de acesso autorizado, que o Bridge obtém durante a inicialização e atualiza periodicamente. Após o estabelecimento da conexão de long-poll, o tráfego flui de Verify para o Verify Bridge.

Visão geral do componente

O diagrama a seguir ilustra os principais componentes da Verify Bridge arquitetura.

A imagem mostra fluxos alternativos para fontes de identidade com e sem suporte a LDAP e LDAP.
Cargas de trabalho
As solicitações de carga de trabalho são despachadas para qualquer instância conectada do agente que represente a origem de identidade. Isso proporciona alta disponibilidade (HA) e desempenho escalável. Qualquer agente é selecionado.
LDAP Agent identity Source1
Várias instâncias do Bridge Agent podem ser implementadas pela origem de identidade. Isso possibilita que um cluster do Bridge Agents atenda solicitações e cargas de trabalho para uma origem de identidade fornecida.
Origem LDAP 1 (Replica2)
Cada instância do Bridge Agent deve ser capaz de se conectar ao mesmo repositório ou ao repositório de réplica de dados externos reais. Cada URL primária e réplica é configurada como parte das informações de conexão do agente. Tentativas de conexão são feitas na ordem fornecida na configuração.
Neste diagrama:
  1. Os fluxos e caixas que são ilustrados dentro da caixa Verify são apenas conceituais.
  2. Várias instâncias do Agente de Ponte podem ser implementadas para uma Origem de Identidade. Essa capacidade ativa um cluster de Agentes de Ponte para solicitações de servidores e cargas de trabalho de uma Origem de Identidade. Cada instância do Agente de Ponte deve ser capaz de conectar-se ao mesmo repositório de dados externo real ou a uma réplica dele.
Nota:
  • A validação do certificado do servidor LDAP TLS agora é imposta quando o host é especificado usando um endereço IP. Após o upgrade, o uso existente do TLS e endereço IP podem falhar ao operar. Duas opções estão disponíveis para os afetados por essa mudança:
    • "LdapCertHostName" "{your cert host name}"Especifique o nome do host do certificado do servidor LDAP usando o item de configuração opcional.
    • Mudar o URI do LDAP para usar o nome do host do certificado do servidor LDAP. Se uma solução temporária imediata for necessária até que uma solução seja escolhida, configure a configuração opcional "InsecureSkipVerify" para "true".
  • A versão 1.0.9 e mais recente não aceita mais certificados que dependem do campo legado Nome Comum. Os certificados devem usar SAN (nome alternativo do assunto) em vez disso. Se a identificação do nome do host do campo Nome Comum legada tiver que ser usada, configure a variável de ambiente GODEBUG='x509ignoreCN=0' para o processo do Windows onprem.exe ou passe-a para a imagem do Docker.

Software suportado

Sistemas Operacionais
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2012 R2
  • Windows Server 2022
  • Windows Server 2025
  • Linux sistemas compatíveis com o motor Docker 19.03.0 ou superior