Configuração do SAML 2.0: Metadados versus Sem Metadados

Este artigo aborda os benefícios do uso de metadados SAML 2.0 ao estabelecer confiança entre dois servidores SAML 2.0 Federation, em vez de fornecer e inserir informações manualmente digitando/copiando/colocando URLs, certificados.

Estabelecer Confiança

O estabelecimento confiável no contexto do SAML 2.0 WebSSO é o ato de configurar um Provedor de Identidades SAML 2.0 e um Provedor de Serviços SAML 2.0 para que eles possam executar operações de SSO de Federação.

Estabelecer confiança envolve as seguintes etapas:

Criando uma entrada de parceiro no Provedor de Identidades SAML 2.0 que representa o Provedor de Serviços remoto com as seguintes informações
O EntityID ou ProviderID do SP, que é o identificador exclusivo que faz referência ao SP
O(s) URL(s) do Serviço do Consumidor de Asserção em que IdP redireciona o usuário com a Asserção SAML
Cada um pode ter um URL diferente e um binding diferente (por exemplo, urn:oasis:names:tc:SAML:2.0:bindings:HTTPArtifact, urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST ou urn:oasis:names:tc:SAML:2.0:bindings:PAOS)
Os URLs do Serviço de Log-out nos quais o IdP redireciona o usuário durante a troca de Log-out do SAML 2.0
Cada um pode ter um binding diferente (por exemplo, urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST)
Cada Serviço pode ter diferentes URLs para receber uma mensagem LogoutRequest e uma mensagem LogoutResponse
Os certificados X.509 correspondentes à chave privada usada pelo SP para assinar mensagens SAML 2.0 de saída, como AuthnRequest,
Mensagens LogoutRequest/LogoutResponse ou ArtifactResolve
Os certificados X.509 correspondentes à chave privada usada pelo SP para decriptografar mensagens SAML 2.0 recebidas criptografadas pelo IdPs remoto com o(s) certificado(s), como os elementos Asserção/NameID/Attribute dentro de uma Resposta de SSO
Criando uma entrada de parceiro no Provedor de Serviços SAML 2.0 que representa o Provedor de Identidades remoto com as seguintes informações
O EntityID ou ProviderID do IdP, que é o identificador exclusivo que faz referência ao IdP
Os URLs de Serviço de Sign-on Único em que o SP redireciona o usuário com o SAML AuthnRequest
Cada um pode ter um URL diferente e um binding diferente (por exemplo, urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTPPOST ou urn:oasis:names:tc:SAML:2.0:bindings:SOAP)
Os URLs do Serviço de Log-out nos quais o SP redireciona o usuário durante a troca de Log-out SAML 2.0
Cada um pode ter um binding diferente (por exemplo, urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST)
Cada Serviço pode ter diferentes URLs para receber uma mensagem LogoutRequest e uma mensagem LogoutResponse
Os certificados X.509 correspondentes à chave privada usada pelo IdP para assinar mensagens SAML 2.0 de saída, como as mensagens de Asserção, LogoutRequest/LogoutResponse ou ArtifactResponse
Os certificados X.509 correspondentes à chave privada usada pelo IdP para decriptografar mensagens SAML 2.0 recebidas criptografadas por SPs remotos com os (s), como o elemento NameID dentro de uma Solicitação de Log-out

A opção acima abrange apenas a configuração de SSO de Federação. Se os parceiros da Federação suportarem outros serviços, como Autoridade de Atributo e Solicitante de Atributo, será necessário trocar mais URLs de Serviço e informações de certificado.

Processo Manual

Como você pode ver, pode haver muitas informações trocadas entre os administradores responsáveis por gerenciar os servidores da Federação, e qualquer erro menor pode fazer com que o acordo da Federação não seja configurado corretamente e causar erros de runtime.

Os erros que podem ocorrer devido a um estabelecimento de confiança manual podem ser:

Certificado incorreto usado
Combinação incorreta de URL/vinculação de Serviço, em que, por exemplo, um URL de Serviço do Consumidor de Asserção usado somente para a vinculação de Artefato é usado para a vinculação HTTP-POST
Typo nos URLs
Especificando incorretamente o nome do host nos URLs de Serviço: Como os cookies são usados durante as operações de SSO da Federação. É primordial usar o mesmo nome de host totalmente qualificado, que é o ponto final público que os usuários usam para acessar os servidores da Federação. (Endereços IP ou nomes de host não totalmente qualificados resultam em erros)
Typo no ProviderIDs
URLs ausentes

Esses erros resultam em:

Falhas de verificação ou decriptografia de assinatura ao usar certificados incorretos O servidor gerar um erro porque
- Certificado não é válido
- Estão faltando URLs para a funcionalidade que é exercida (por exemplo, URL de Log-out ausente)
- Nomes de host inconsistentes foram usados (totalmente qualificado vs Endereço IP vs não totalmente qualificado) ProviderID é desconhecido, causado por um erro de digitação
- Loops infinitos, devido ao uso de nomes de host inconsistentes

Os erros listados acima ocorrem mais do que as pessoas supõem, e isso leva ao tempo gasto perseguindo por que o SSO da Federação não está funcionando corretamente que quase aponta para um erro de estabelecimento do Federation Trust.

Usando Metadados SAML 2.0

As especificações SAML 2.0 definem o documento de Metadados que contém todas as informações que um servidor precisa saber sobre sua contraparte para executar operações de Federação com o parceiro remoto.

Essas informações incluem:

URLs de Serviço
Associações SAML para os serviços
Certificados para operações de assinatura e criptografia
Quais mensagens serão assinadas (AuthnRequest, Asserção)
Atribuições suportadas pelo Servidor de Federação (IdP, SP, Autoridade de Atributo...)

Os Metadados SAML 2.0 geralmente são gerados pelo próprio servidor de federação e são consumidos pelo servidor de Federação do parceiro: portanto, não ocorre nenhuma intervenção manual para criar e consumir esse documento e, assim, reduzir o número de possíveis erros.

O uso de Metadados SAML 2.0 oferece as seguintes vantagens:

Todas as informações estão contidas em um único documento
O documento é gerado e consumido pelos servidores da Federação (assinaturas podem ser usadas para proteção contra adulteração)
Nenhuma informação omitida
Os dados são consistentes (mesmos nomes de host usados em todos os URLs)

Mais importante ainda, economiza tempo reduzindo a possibilidade de erros durante o estabelecimento de confiança da federação, para que haja menos chances de erros de tempo de execução mais tarde.

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal YouTube do Oracle Learning. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

Título e Informações de Copyright

SAML 2.0 Setup Metadata vs No Metadata

F61884-01

September 2022