Gerenciar provedores de identidade
Configure provedores de identidade (IdPs) personalizados para o login único SAML ou OIDC, para que os usuários da sua organização possam se autenticar com suas credenciais corporativas existentes.
O gerenciamento de provedores de identidade está disponível apenas para administradores do plano Enterprise.
Configure um provedor de identidade (IdP) personalizado para habilitar o login único (SSO) na sua organização. Quando você configura um IdP, o Bob redireciona você para ele para autenticação ao fazer login no IBM Bob pela IDE, Bob Shell e Bob Web.
Você pode configurar provedores de identidade SAML e OpenID Connect (OIDC) com o Bob. Use o protocolo que corresponde à plataforma de identidade da sua organização.
Compatibilidade de protocolo SSO
O IBM Bob é compatível com os seguintes protocolos de SSO:
- SAML (Security Assertion Markup Language)
- OIDC (OpenID Connect)
Provedores OIDC verificados
Embora você possa usar outros provedores OIDC que atendam aos requisitos de configuração e token, as seguintes plataformas são verificadas:
- Auth0
- Keycloak
- Okta
- PingOne
Adicionar um provedor de identidade
Adicionar um IdP é um processo em duas etapas. Primeiro, você configura o IdP e o salva. Em seguida, adiciona os domínios de e-mail que o utilizam.
Etapa 1: Configurar o provedor de identidade
Acesse a página de administração do IBM Bob.
Selecione a aba Authentication.
Clique em Add IdP. Insira um nome para o IdP. Selecione o tipo de IdP: SAML ou OIDC. Gere suas credenciais de service provider (SP).
O Bob requer uma chave privada SP e um certificado SP para assinar solicitações de autenticação SAML. Você deve gerá-los usando a ferramenta de linha de comando openssl.
Se você já tem um par de chaves SP e um certificado, pule para a próxima etapa.
Execute o seguinte comando para gerar a chave privada SP:
openssl genrsa -out sp_private_key.pem 2048Em seguida, execute este comando para gerar o certificado SP a partir da chave privada. Substitua os valores /CN, /O e /C por um nome descritivo do certificado, o nome da sua organização e o código de país de duas letras:
openssl req -new -x509 -key sp_private_key.pem -out sp_certificate.pem -days 365 -subj "/CN=Bob SAML SP/O=IBM/C=US"O arquivo sp_certificate.pem também deve ser enviado para o seu IdP para que ele possa verificar as assinaturas das solicitações do Bob.
Insira os detalhes de configuração do IdP. Revise os requisitos específicos do protocolo nas seções a seguir. Clique em Save.
O IdP é criado e aparece na tabela da aba Authentication.
Configuração SAML
O SAML requer os seguintes detalhes de configuração:
Campos do identity provider — obtenha-os do seu IdP:
idp_entity_id— o identificador único do IdP (por exemplo,https://idp.example.com)idp_sso_url— a URL de SSO para onde o Bob envia solicitações de autenticaçãoidp_certificate— o certificado X.509 codificado em PEM usado para verificar respostas SAML do IdP
Campos do service provider — use os arquivos gerados na etapa anterior:
sp_private_key— o conteúdo desp_private_key.pemsp_certificate— o conteúdo desp_certificate.pem
Campos opcionais:
idp_slo_url— a URL de Single Logout do IdP. Single Logout ainda não está totalmente implementado no Bob.
Na seção Attribute mapping, mapeie os atributos de usuário do IdP para os campos de usuário do IBM Bob. O formato de mapeamento é nome do atributo Bob → nome do atributo ou URI do IdP. Verifique a configuração do seu IdP para os nomes de atributo corretos.
email(obrigatório) — o endereço de e-mail do usuárioname(opcional) — o nome completo de exibição do usuáriogiven_name(opcional) — o primeiro nome do usuáriofamily_name(opcional) — o sobrenome do usuáriogroups(opcional) — os grupos do usuário
Administrador do IdP: registrando um novo cliente OIDC
Antes que um admin da instância Bob possa configurar um registro de IdP OIDC no Bob, o administrador do IdP precisa primeiro criar um aplicativo OIDC (cliente) no provedor de identidade. Os valores produzidos nesta etapa são os que o admin da instância Bob insere ao adicionar o IdP no Bob.
Tipo de aplicativo e tipo de concessão
Crie um aplicativo web (lado do servidor / cliente confidencial) no seu provedor de identidade e ative o tipo de concessão Authorization Code. O Bob usa exclusivamente o fluxo Authorization Code — não selecione Implicit, Device Code ou Client Credentials.
URI de redirecionamento
Registre o seguinte URL de callback no aplicativo OIDC. A maioria dos provedores realiza uma correspondência exata da string, então copie-o exatamente:
https://api.us-east.bob.ibm.com/authn/v1/auth/callbackEscopos a ativar no cliente
| Escopo | Finalidade | Obrigatório |
|---|---|---|
openid | Ativa o modo OIDC e retorna um id_token | Sim |
email | Expõe o endereço de e-mail do usuário no id_token ou via endpoint userinfo | Sim |
offline_access | Concede um refresh_token junto com o access token | Sim para a maioria dos provedores |
O Bob exige que um refresh_token esteja presente em cada resposta de troca de código de autorização. Se seu provedor emite refresh tokens por um mecanismo diferente (por exemplo, um escopo específico do provedor, ou incondicionalmente em cada troca de código), configure adequadamente — mas certifique-se de que o cliente está autorizado a receber refresh tokens. Se nenhum refresh_token for retornado, o login é interrompido.
Método de autenticação no token endpoint
Configure o método de autenticação no token endpoint do aplicativo OIDC como client_secret_post. O Bob envia client_id e client_secret como parâmetros no corpo do formulário em cada solicitação de token. client_secret_basic, private_key_jwt e none não são aceitos.
Configurações de token
| Configuração | Valor necessário |
|---|---|
| Formato do access token | Qualquer (JWT ou opaco — o Bob não analisa diretamente o access token do IdP) |
| ID token | Deve ser emitido em cada troca de código de autorização e em cada renovação de token |
| Algoritmo de assinatura do ID token | RS256, ES256 ou PS256 |
| Rotação do refresh token | Você pode usar a rotação de refresh token. O Bob armazena o novo token em cada renovação. Se seu provedor rotaciona refresh tokens, certifique-se de que o provedor invalide o token anterior somente depois que o Bob receber o substituto (comportamento de rotação padrão, não de uso único sem janela de tolerância). |
Valores a entregar ao admin da instância Bob
Após a criação do aplicativo cliente, forneça os seguintes valores ao admin da instância Bob:
| Valor | Onde encontrar | Campo de configuração do Bob |
|---|---|---|
| Client ID | Página de credenciais do aplicativo | client_id |
| Client Secret | Página de credenciais do aplicativo | client_secret |
| URL do authorization endpoint | Página de endpoints OIDC do provedor ou .well-known/openid-configuration | authorization_endpoint |
| URL do token endpoint | Página de endpoints OIDC do provedor ou .well-known/openid-configuration | token_endpoint |
| JWKS URI | Página de endpoints OIDC do provedor ou .well-known/openid-configuration | jwks_uri |
| URL do issuer | Página de endpoints OIDC do provedor ou .well-known/openid-configuration | issuer |
| URL do userinfo endpoint (opcional) | Página de endpoints OIDC do provedor ou .well-known/openid-configuration | userinfo_endpoint |
A maioria dos provedores publica todos os URLs de endpoint em https://<seu-domínio-de-provedor>/.well-known/openid-configuration.
Configuração OIDC
Você pode usar a descoberta de provedor OIDC. Clique no botão Retrieve configuration para preencher automaticamente os campos de endpoint do documento .well-known/openid-configuration do seu provedor, ou pode inserir cada URL de endpoint manualmente.
O OIDC requer os seguintes detalhes de configuração:
| Campo | Obrigatório | Descrição |
|---|---|---|
client_id | Sim | O identificador de cliente registrado com seu provedor de identidade. |
client_secret | Sim | O segredo do cliente para o aplicativo registrado. O Bob o armazena com segurança e nunca o retorna em respostas de API. |
scopes | Sim | Os escopos solicitados durante o fluxo de autorização. Esta lista deve incluir openid. Geralmente também inclui email e o escopo específico do provedor usado para emitir um token de atualização, como offline_access. |
authorization_endpoint | Sim | A URL de autorização HTTPS para a qual o Bob redireciona os usuários para fazer login. |
token_endpoint | Sim | A URL de token HTTPS usada para trocar o código de autorização por tokens. |
jwks_uri | Sim | A URL HTTPS do JSON Web Key Set (JWKS) usado para verificar a assinatura das respostas id_token. |
issuer | Não | O identificador do emissor HTTPS para o provedor de identidade. |
prompt | Não | O valor prompt OIDC encaminhado para a solicitação de autorização. |
O OIDC não usa Attribute mapping. O Bob lê o e-mail do usuário diretamente da reivindicação email no id_token.
Exemplo de configuração OIDC
{
"authorization_endpoint": "https://corp.okta.com/oauth2/default/v1/authorize",
"token_endpoint": "https://corp.okta.com/oauth2/default/v1/token",
"issuer": "https://corp.okta.com/oauth2/default",
"client_id": "0oa1b2c3d4e5f6g7h8i9",
"client_secret": "super-secret-value",
"scopes": ["openid", "email", "offline_access"]
}Requisitos e limitações do OIDC
- O Bob requer um
refresh_tokenna resposta de troca do código de autorização. Se o seu provedor não retornar um, o login falhará. - Para a maioria dos provedores, adicionar
offline_accessascopesé o que aciona a emissão do token de atualização. Alguns provedores usam um comportamento diferente, portanto, consulte a documentação do seu provedor. - O logout de back-channel OIDC não está disponível.
- Se o seu provedor alterar suas URLs de endpoint, atualize a configuração do IdP no Bob.
Etapa 2: Adicionar filtros de domínio
Após salvar o IdP, adicione os domínios de e-mail que devem usá-lo para autenticação.
Na aba Authentication, localize o IdP que você acabou de criar e abra suas configurações. Na seção Domain filters, adicione os domínios de e-mail que devem usar este IdP. Os usuários cujos endereços de e-mail correspondem a um domínio configurado são redirecionados para este IdP no login. Salve suas alterações.
Cada domínio de e-mail só pode ser associado a um IdP. Se um domínio já estiver em uso por outro IdP, a configuração não poderá ser salva até que o conflito seja resolvido. Cada domínio também deve ser verificado antes que o SSO seja aplicado. Consulte Verificar a propriedade do domínio.
Verificar a propriedade do domínio
O IBM Bob exige que você verifique que sua organização é proprietária de cada domínio antes que o SSO seja aplicado. A verificação é feita adicionando um registro TXT de DNS ao seu domínio.
Acesse a página de administração do IBM Bob. Selecione a aba Authentication. Selecione o IdP que contém o domínio que deseja verificar. Na seção Domain filters, localize o domínio e copie o código de verificação exibido. No seu provedor de DNS, adicione um registro TXT ao domínio com o seguinte formato:
bob-verify=<verification-code>Substitua verification-code pelo código copiado da seção Domain filters. Volte para a aba Authentication e clique em Check verification para o domínio.
O status de verificação do domínio é atualizado para Verified quando o IBM Bob detecta com sucesso o registro TXT. As alterações de DNS podem levar algum tempo para se propagar.
Remover um provedor de identidade
Acesse a página de administração do IBM Bob. Selecione a aba Authentication. Localize o IdP que deseja remover e clique em Delete. Na caixa de diálogo de confirmação, clique em Confirm.
Excluir um IdP remove a configuração de SSO para todos os domínios associados. Os usuários que dependiam desse IdP para autenticação precisarão fazer login por outro método. Um aviso é exibido se o IdP tiver domínios verificados.
Criando e configurando equipes
Configure equipes para organizar usuários e controlar gastos em diferentes grupos em sua organização IBM Bob Enterprise.
Revisão do registro de atividade
Baixe e revise os arquivos de registro de auditoria da sua organização IBM Bob Enterprise para monitorar eventos de autenticação e atividade administrativa.