Configuração do cliente SAML
O SAML 2.0 é uma especificação semelhante ao OIDC, mas muito mais antiga e madura. Sendo principalmente um protocolo de autenticação que funciona trocando documentos XML entre o servidor de autenticação e a aplicação, o protocolo SAML utiliza as assinaturas XML e criptografia para verificar solicitações e respostas.
No Keycloak você pode utilizar SAML 2.0 para aplicações registradas com ambos POST e Redirect bindings suportados. Podendo também optar por exigir a validação da assinatura do cliente e fazer com que o servidor assine e criptografe as respostas.
Há dois tipos de casos de uso no Keycloak que o SAML atende: aplicações de navegadores WEB e invocações REST.
O primeiro é uma aplicação que pede ao servidor Keycloak para autenticar um usuário. Após um login bem-sucedido, a aplicação receberá um documento XML que contém algo chamado de asserção SAML que especifica vários atributos sobre o usuário. Este XML é assinado digitalmente pelo domínio e contém informações de acesso (como mapeamentos de funções do usuário) que a aplicação pode usar para determinar quais recursos o usuário tem permissão para acessar no aplicação.
O segundo é o de um cliente que deseja obter acesso a serviços remotos. Nesse caso, o cliente pede ao Keycloak para obter uma asserção SAML que possa usar para invocar em outros serviços remotos em nome do usuário.
Configuração no Keycloak
Para criar um cliente SAML, vá ao menu à esquerda em Clientes. Nesta página, você verá um botão Criar (Create) à direita.
Digite o Client ID do cliente. Geralmente, é um URL e será o valor do emissor esperado nas solicitações SAML enviadas pela aplicação.
Em seguida, selecione saml na caixa suspensa Protocolo do cliente.
Por fim, insira o URL do terminal SAML do cliente. Insira a URL para a qual deseja que o servidor Keycloak envie solicitações e respostas SAML. Normalmente, os aplicativos têm apenas um URL para processar solicitações SAML. Se seu aplicativo tiver URLs diferentes para seus vínculos, não se preocupe, você pode corrigir isso na guia Configurações do cliente. Clique em Salvar.
Isso criará o cliente e o levará à guia Configurações do cliente.
Client ID
Mais conhecido como Entity ID, é um identificador exclusivo para uma entidade SAML. Este valor deve corresponder ao valor do emissor enviado com AuthNRequests*. O Keycloak irá puxar o emissor da solicitação Authn SAML e combiná-lo com um cliente por este valor.
O Entity ID é usado como o valor do elemento <Issuer> na mensagem do protocolo SAML. Em uma solicitação de autenticação, o elemento <Issuer> contém o ID da entidade do provedor de serviços; na resposta SAML, ele contém o ID da entidade do provedor de identidade.
Da perspectiva do provedor de serviços, o ID da entidade é análogo ao client_id no OAuth.
*Um AuthnRequest é enviado pelo provedor de serviços ao provedor de identidade no fluxo iniciado pelo SP-SSO.
Nome e Descrição
Este são respectivamente o nome de exibição e a descrição do cliente exibidos dentro do Keycloak. Ex: Aplicação XZYW
Habilitado ou “Enabled”
Deve estar habilitado. Caso desative, o cliente não terá permissão para solicitar autenticação.
Requerimento de Consentimento
Se estiver ativado, os usuários receberão uma página de consentimento que pergunta ao usuário se ele concede acesso a esse aplicativo. Ele também exibirá os metadados nos quais o cliente está interessado, para que o usuário saiba exatamente a quais informações o cliente está tendo acesso. Se você já fez um login social para o Google, frequentemente verá uma página semelhante. Keycloak fornece a mesma funcionalidade.
Incluir AuthnStatement
As respostas de login SAML podem especificar o método de autenticação usado (senha, etc.), bem como um carimbo de data/hora do login. Definir como ativado incluirá essa declaração no documento de resposta.
O elemento AuthnStatement descreve uma declaração da autoridade SAML afirmando que o assunto da asserção foi autenticado por um meio específico em um determinado momento.
Assinar Documentos (Sign Documents)
Quando ativado, o Keycloak assinará o documento usando a chave privada do Realm.
Para aumentar a segurança de suas transações, você pode assinar ou criptografar suas solicitações e respostas no protocolo SAML
Otimize a Busca da Chave de Assinatura REDIRECT
Quando ativado, as mensagens do protocolo SAML incluirão a extensão nativa Keycloak que contém uma dica com o ID da chave de assinatura. Quando o SP entende essa extensão, ele pode usá-la para validação de assinatura em vez de tentar validar a assinatura com todas as chaves conhecidas. Esta opção se aplica apenas a ligações REDIRECT onde a assinatura é transferida em parâmetros de consulta onde não há lugar com esta informação nas informações de assinatura (ao contrário de mensagens de ligação POST em que o ID da chave é sempre incluído na assinatura do documento). Atualmente, isso é relevante para situações em que o IDP e o SP são fornecidos pelo servidor e adaptador Keycloak. Esta opção só é relevante quando Assinar Documentos está ativado.
Assinar Asserção (Sign Assertions)
Enquanto a assinatura de documentos assina todo o documento. Com essa configuração, a asserção também é assinada e incorporada na resposta SAML XML Auth.
Algoritmo de Assinatura
Escolha entre uma variedade de algoritmos para assinar documentos SAML.
Nome da Chave de Assinatura SAML
Os documentos SAML assinados enviados por ligação POST contêm a identificação da chave de assinatura no elemento KeyName. Por padrão, contém o ID da chave Keycloak. No entanto, vários fornecedores podem esperar um nome de chave diferente ou nenhum nome de chave. Esta opção controla se KeyName contém a ID da chave (opção KEY_ID), o assunto do certificado correspondente à chave do realm (opção CERT_SUBJECT – esperado, por exemplo, pelos Serviços de Federação do Microsoft Active Directory) ou se a dica do nome da chave é completamente omitida da mensagem SAML ( opção NENHUMA).
Método de Canonização
Método de canonização para assinaturas XML. Como as asserções, respostas e solicitações SAML são por natureza projetadas para serem incorporadas em outras mensagens XML, o uso de canonização exclusiva é altamente vantajoso para muitos aplicativos SAML, portanto, esse algoritmo é fortemente sugerido para uso ao assinar conteúdo SAML. Quando possível, use o algoritmo de canonização exclusiva (Exclusive) ao assinar asserções, solicitações ou respostas SAML, especialmente se o objeto SAML puder ser assinado antes da inserção em um contexto XML maior.
Mais informações sobre Canonização
Mais informações sobre assinaturas de XML
Criptografar Afirmações (Encrypt Assertions)
Criptografe as declarações em documentos SAML com a chave privada do Realm. O algoritmo AES é usado com um tamanho de chave de 128 bits.
Criptografar as declarações SAML entre o Servidor de identidade e aplicação fornece garantia adicional de que o conteúdo do token não pode ser interceptado e os dados pessoais ou corporativos comprometidos.
Assinatura do Cliente Necessária
Espere que os documentos vindos de um cliente sejam assinados. O Keycloak validará esta assinatura usando a chave pública do cliente ou certificado configurado na guia Chaves SAML.
Forçar POST Binding
Por padrão, o Keycloak responderá usando a vinculação SAML inicial da solicitação original. Ao ativar essa opção, você forçará o Keycloak a sempre responder usando a vinculação SAML POST, mesmo se a solicitação original for a vinculação de redirecionamento.
Os solicitantes e respondentes SAML se comunicam trocando mensagens. O mecanismo para transportar essas mensagens é chamado de “Binding”.
O HTTP POST permite que as mensagens do protocolo SAML sejam transmitidas em um formulário HTML usando conteúdo codificado em base64. Ele permite que os solicitantes e respondentes SAML se comuniquem usando um agente de usuário HTTP como intermediário.
O agente pode ser necessário se as entidades em comunicação não tiverem um caminho direto de comunicação. O intermediário também pode ser necessário se o respondente exigir interação com um agente do usuário, como um agente de autenticação.
O HTTP POST às vezes é chamado de POST do navegador, principalmente quando usado em operações de logon único. Ele usa um formulário de postagem automática durante o estabelecimento e uso de uma sessão confiável entre um provedor de identidade, um provedor de serviços e um cliente (navegador).
Já o HTTP artifact é uma ligação na qual uma solicitação ou resposta SAML (ou ambas) é transmitida por referência usando um identificador exclusivo que é chamado de artefato.Uma ligação separada, como uma ligação SOAP, é usada para trocar o artefato pela mensagem de protocolo real. Ele permite que os solicitantes e respondentes SAML se comuniquem usando um agente de usuário HTTP como intermediário.
Essa configuração é usada quando não é preferível expor o conteúdo da mensagem ao intermediário.
O artefato HTTP às vezes é chamado de artefato do navegador, principalmente quando usado em operações de conexão única. O artefato HTTP usa um canal de apoio SOAP. O canal de apoio SOAP é usado para trocar um artefato durante o estabelecimento e uso de uma sessão confiável entre um provedor de identidade, um provedor de serviços e um cliente (navegador).
Logout do Canal Frontal
Se verdadeiro, esta aplicação requer um redirecionamento do navegador para realizar um logout. Por exemplo, o aplicativo pode exigir que um cookie seja redefinido, o que só pode ser feito através de um redirecionamento. Se essa opção for falsa, o Keycloak invocará uma solicitação SAML em segundo plano para fazer logout do aplicativo.
Forçar Formato de Name ID Format
Se a solicitação tiver uma política de ID de nome, ignore-a e use o valor configurado no console de administração em Formato de ID de nome
Formato de Name ID Format
Formato de ID de nome para o assunto. Se nenhuma política de ID de nome for especificada na solicitação ou se o atributo Forçar Formato de ID de Nome for verdadeiro, este valor será usado. As propriedades usadas para cada um dos respectivos formatos são definidas a seguir.
URL Raiz (Root URL)
Se Keycloak usa qualquer URL relativo configurado, este valor é anexado a eles.
URIs de Redirecionamento Válidos
Este é um campo opcional. Insira um padrão de URL e clique no sinal + para adicionar. Clique no sinal – próximo aos URLs que deseja remover. Lembre-se de que você ainda precisa clicar no botão Salvar! Curingas (\ *) são permitidos apenas no final de um URI, ou seja, http://host.com/*. Este campo é usado quando os terminais SAML exatos não estão registrados e o Keycloak está puxando o URL do Assertion Consumer da solicitação.
URL Base
Se o Keycloak precisar se vincular ao cliente, este URL será usado.
URL de Processamento SAML Mestre
Este URL será usado para todas as solicitações SAML e a resposta será direcionada ao SP. Ele será usado como o URL do Assertion Consumer Service e o URL do Single Logout Service. Se uma solicitação de login contiver o URL do Assertion Consumer Service, isso terá precedência, mas esse URL deve ser validado por um padrão de URI de redirecionamento válido registrado
Assertion Consumer Service URL (ACS)
Um URL do Assertion Consumer Service (ACS) deve ser configurado. O URL ACS é um ponto de extremidade no provedor de serviços para onde o provedor de identidade redirecionará com sua resposta de autenticação.
Assertion Consumer Service POST Binding URL
URL de vinculação POST para o Assertion Consumer Service.
Assertion Consumer Service Redirect Binding URL
URL de vinculação de redirecionamento para o Assertion Consumer Service.
Logout Service POST Binding URL
URL de vinculação POST para o serviço de logout.
Logout Service Redirect Binding URL
URL de vinculação de redirecionamento para o serviço de logout.
IDP Initiated Login
O login iniciado por IDP é um recurso que permite que você configure um endpoint no servidor Keycloak que irá conectá-lo a um aplicativo / cliente específico. Na guia Configurações de seu cliente, você precisa especificar o nome do URL do SSO iniciado por IDP. Esta é uma string simples sem nenhum espaço em branco. Depois disso, você pode consultar seu cliente no seguinte URL: root / auth / realms / {realm} / protocol / saml / clients / {url-name}
A implementação de login iniciada pelo IDP prefere POST em vez de ligação REDIRECT (verifique as ligações saml para obter mais informações). Portanto, a ligação final e o URL do SP são selecionados da seguinte maneira:
- Se a URL de ligação POST do Assertion Consumer Service específica for definida (na seção Fine Grain SAML Endpoint Configuration das configurações do cliente), a ligação POST será usada por meio dessa URL.
- Se o URL de processamento SAML mestre geral for especificado, a ligação POST será usada novamente por meio desse URL geral.
- Como último recurso, se a URL de associação de redirecionamento de serviço ao consumidor de asserção estiver configurada (na configuração do ponto de extremidade SAML de granulação fina), a associação REDIRECT será usada com essa URL.
Se o seu cliente requer um estado de relé especial, você também pode configurar isso na guia Configurações no campo Estado de relé de SSO iniciado por IDP. Como alternativa, os navegadores podem especificar o estado de retransmissão em um parâmetro de consulta RelayState, ou seja, root / auth / realms / {realm} / protocol / saml / clients / {url-name}? RelayState = thestate.
Ao usar a corretagem de identidade, é possível configurar um Login iniciado por IDP para um cliente de um IDP externo. O cliente real é configurado para login iniciado por IDP no corretor IDP, conforme descrito acima. O IDP externo deve configurar o cliente para o Login iniciado por IDP do aplicativo que apontará para um URL especial apontando para o corretor e representando o ponto de extremidade de Login iniciado por IDP para um cliente selecionado no IDP de corretagem. Isso significa que nas configurações do cliente no IDP externo:
O IDP Initiated SSO URL Name é definido como um nome que será publicado como ponto inicial de login iniciado por IDP,
O Assertion Consumer Service POST Binding URL na seção Fine Grain SAML Endpoint Configuration deve ser definido com o seguinte URL: broker-root / auth / realms / {broker-realm} / broker / {idp-name} / endpoint / clients / { client-id}, onde:
- broker-root é o URL do corretor de base
- broker-realm é o nome do realm no broker onde o IDP externo é declarado
- idp-name é o nome do IDP externo no corretor
- client-id é o valor do atributo Nome do URL de SSO iniciado por IDP do cliente SAML definido no broker. É este cliente, que será disponibilizado para login iniciado por IDP a partir do IDP externo.
Observe que você pode importar configurações básicas do cliente do IDP de corretagem para as configurações do cliente do IDP externo – basta usar o SP Descriptor disponível nas configurações do provedor de identidade no IDP de corretagem e adicionar clientes / id do cliente ao URL do terminal.
Fontes:
love4tek 