Protocolos de federação e aprovisionamento
Escolha e utilize apenas as interfaces de federação e aprovisionamento registadas para uma aplicação ou tenant.
- Identificar a interfaceDistinga início de sessão no browser, autorização de API, aprovisionamento de diretórios e comunicação com agentes.
- Confirmar o registoVerifique o tenant, o ciclo de vida, os metadados do fornecedor, o redirecionamento e o perfil de garantia ativo.
- Trocar valoresUse os metadados registados e o contrato da API de gestão gerado.
- Testar o comportamentoVerifique a identidade, o mapeamento, a adesão ao tenant, o fim de sessão ou o aprovisionamento com uma identidade de teste.
- ManterRode credenciais, acompanhe a sincronização e desative registos antigos através dos controlos de ciclo de vida.
OIDC, OAuth e PKCE
Os clientes OIDC registados usam autorização no browser, seleção da conta, consentimento e condições quando configurados. A autorização de dispositivos é uma interface separada, não substitui o registo do cliente. PKCE e opções de garantia elevada dependem da política do cliente e do tenant. PAR, private-key JWT, mTLS, DPoP e perfis FAPI são condicionais; a sua presença no código não significa que estejam ativados.
- Registe o emissor, os redirecionamentos e as definições de resposta exatos do cliente.
- Conclua o consentimento e a seleção da conta; verifique a identidade e a audiência.
- Confirme o suporte de PKCE ou de garantia na política; não enfraqueça a validação para eliminar uma recusa.
SAML e encerramento de sessão remoto
As rotas de fornecedor de serviços e fornecedor de identidade SAML expõem metadados e fluxos de asserção no browser. Configure a ligação através da gestão SAML. Valide junto do parceiro o emissor, a audiência, o destino de resposta, a assinatura e as condições temporais. O encerramento de sessão é separado: revogar localmente não prova que todos os cookies ou sessões da parte dependente tenham sido eliminados.
- Compare os metadados da ligação, a chave de assinatura e os endpoints com os do parceiro.
- Teste uma asserção assinada e verifique o tenant, o sujeito, a adesão e a validade.
- Use os controlos de encerramento suportados e distinga a revogação local da saída remota.
SCIM e sincronização de diretórios
O aprovisionamento é diferente da federação interativa. O esquema e a reconciliação SCIM coexistem com conectores de diretório que usam um agente do lado do cliente inscrito. As importações preservam a proveniência do tenant e colocam conflitos em quarentena; o e-mail, por si só, não associa contas. O servidor não inclui o binário do agente do cliente.
- Registe o destino do tenant e mapeie os atributos suportados e as chaves de identidade imutáveis.
- Execute uma sincronização controlada, inspecione os resultados e resolva quarentenas no fluxo do tenant.
- Implemente e inscreva separadamente o agente compatível antes de colocar trabalho do conector na fila.
CAS, WS-Federation e RADIUS
O CAS exige ativação explícita. WS-Federation e WS-Trust permanecem desativados salvo se um registo ou uma política permitidos os ativarem; as verificações de realm, audiência, resposta, adesão, assinatura e validade continuam obrigatórias. O RADIUS usa um agente assinado opcional, não um listener do site. A referência mantida prefere RADIUS/1.1 por TLS ou DTLS; o UDP legado serve apenas para compatibilidade em redes privadas.
- Confirme a ativação do protocolo e o registo do cliente antes de testar CAS ou WS-Federation.
- Para RADIUS, verifique o agente do cliente, o conector do tenant e o transporte permitido.
- Se estiver desativado ou não inscrito, conclua a configuração em vez de mudar de protocolo para contornar a política.
Registo e credenciais
O registo do cliente tem de permanecer no tenant e na aplicação proprietários. As referências a registo dinâmico, private-key JWT, mTLS e FAPI descrevem contratos condicionais, não ativação universal. Mantenha as chaves privadas com o respetivo proprietário e rode ou revogue credenciais através do controlo de gestão correspondente. As chaves de agente não são credenciais de cliente OAuth.
- Reúna o proprietário, o tenant, o redirecionamento ou metadados, os âmbitos e o tipo de credencial.
- Guarde em segurança qualquer segredo devolvido e rode-o ou revogue-o através da gestão.
- Para inscrever um agente, crie a chave privada no lado do cliente e submeta o respetivo CSR.
Contrato e resolução de problemas
Use /api/auth/management/openapi.json para consultar operações, campos e requisitos de segurança atuais. As notas de protocolo mantidas abrangem comportamentos mais específicos de conectores e garantias. As falhas comuns incluem tenant incorreto, redirecionamento não registado, metadados ou certificado desatualizado, perfil desativado, assinatura inválida, quarentena SCIM ou agente revogado. Corrija o limite de confiança relevante; não desative a verificação.
- Verifique o esquema OpenAPI e os requisitos de segurança da operação.
- Compare os detalhes de erro seguros e os valores registados com os metadados atuais do fornecedor.
- Volte a testar o fluxo controlado e confirme a identidade ou o estado de sincronização antes da implementação.
Perguntas frequentes
A existência de DPoP ou FAPI significa que está ativado?
Não. Os perfis de garantia elevada exigem ativação explícita e configuração completa do cliente.
O agente do cliente está incluído?
Não. Implemente um agente compatível em separado e confirme que está inscrito e atualizado.
O logout SAML termina todas as sessões?
Não. A revogação local é diferente do logout remoto e da remoção de sessões no parceiro.
O SCIM associa utilizadores pelo e-mail?
Não. Mapeie tenant, emissor e sujeito imutável; resolva conflitos através da análise de quarentena.
Posso usar RADIUS diretamente contra o site?
Não. O RADIUS é uma interface opcional de agente assinado, não um endpoint de browser.
Onde encontro os campos exatos da API?
Use /api/auth/management/openapi.json; os exemplos não constituem um contrato completo de SDK.