Conectar um provedor de identidade

O Xokepoint não guarda usuários do cliente. Ele confia no provedor de identidade que o cliente já usa e verifica, em cada token exchange e em cada chamada, que o token do sujeito veio desse provedor. Essa confiança é a identity connection, e ela é o primeiro passo de qualquer ambiente: sem ela, nenhum sujeito existe para o Xokepoint.

A listaCopiar link da seção

As conexões ficam em Access › Integrations › Identity providers:

A busca procura por nome ou issuer, e All statuses filtra por estado. O rodapé lembra o escopo: as conexões valem só para o workspace e o ambiente selecionados.

O menu de açõesCopiar link da seção

• Check configuration confere de novo os metadados, as chaves e o acesso ao diretório.
• Disable connection desliga a conexão sem apagar. Todos os sujeitos daquele provedor deixam de conseguir token no próximo token exchange, e as chamadas em andamento são recusadas na próxima conferência. As delegações dos agentes continuam guardadas para quando a conexão voltar.
• Delete connection remove a conexão.

Escolher o provedorCopiar link da seção

Connect identity provider abre a escolha:

Todo formulário tem quatro partes: Connection (nome e se a conexão está ligada), Request authentication (como validar os tokens dos sujeitos), o diretório (como ler o diretório para escolher quem pode delegar) e Harness login (como as pessoas entram a partir de um harness de código). No formulário do Microsoft Entra ID, a parte do diretório é Microsoft Entra app, o único app registration, que também autentica as pessoas. No formulário do Okta, a parte do diretório é Okta API Services app, e o harness login usa um segundo app, um OIDC Web app. O acesso ao diretório é sempre só de leitura.

Harness loginCopiar link da seção

A última seção do formulário permite que pessoas entrem a partir de um harness de código, como o Claude Code, por este provedor (Conectar um harness de código). O Xokepoint é um cliente OIDC do provedor: manda a pessoa ao provedor, lê quem ela é e os grupos dela, e depois pede o consentimento.

• Allow harness login: "Each agent then chooses which groups of this provider can log in." Os grupos são escolhidos em cada agente (Quem pode delegar).
• Redirect URI, com botão de copiar: <issuer>/callback, em que <issuer> é o authorization server do Xokepoint no ambiente. Registre no provedor. Uma conexão nova mostra a URI depois do primeiro salvamento.
• Login client ID e Login client secret: um cliente OIDC confidencial do provedor, com o fluxo authorization code. Não é o client do diretório, exceto no Microsoft Entra ID, em que um app faz os dois papéis e o formulário pede os valores uma vez. No Okta, é o OIDC Web app, não o API Services app. O segredo fica cifrado e não é exibido.

A cada login, o Xokepoint lê os grupos da pessoa no diretório, com as credenciais de diretório do formulário, nunca de um claim do token. A credencial do diretório precisa de permissão para ler grupos; Check connection avisa quando ela falta. Se o diretório não puder ser lido no login, o login para e nenhum acesso é concedido.

Desligar Allow harness login, ou desativar a conexão, para o refresh de toda máquina que entrou por ela; os access tokens dessas máquinas terminam em até 5 minutos.

O Xokepoint não recebe eventos de ciclo de vida do provedor. Quem é desabilitado lá para de conseguir tokens, e o próximo token exchange falha (Revogação).