Configuration SAML 2.0 : Métadonnées et sans métadonnées

Cet article présente les avantages de l'utilisation des métadonnées SAML 2.0 lors de l'établissement d'une approbation entre deux serveurs de fédération SAML 2.0, par opposition à la saisie et à la saisie manuelle d'informations via la saisie/copie/collage d'URL et de certificats.

Etablir la confiance

L'établissement sécurisé dans le contexte de SAML 2.0 WebSSO consiste à configurer un fournisseur d'identités SAML 2.0 et un fournisseur de services SAML 2.0 afin qu'ils puissent effectuer des opérations SSO de fédération.

L'établissement de la confiance implique les étapes suivantes :

Création d'une entrée de partenaire au niveau du fournisseur d'identités SAML 2.0 qui représente le fournisseur de services distant avec les informations suivantes
EntityID ou ProviderID du SP, qui est l'identificateur unique référençant le SP
URL du service consommateur d'assertion où IdP redirige l'utilisateur avec l'assertion SAML
Chacune peut avoir une URL et une liaison différentes (par exemple, 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).
URL du service de déconnexion où IdP redirige l'utilisateur lors de l'échange de déconnexion SAML 2.0
Chaque liaison peut être différente (par exemple, urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST).
Chaque service peut avoir différentes URL pour recevoir un message LogoutRequest et un message LogoutResponse
Certificats X.509 correspondant à la clé privée utilisée par le fournisseur de services pour signer les messages SAML 2.0 sortants, tels que AuthnRequest,
Messages LogoutRequest/LogoutResponse ou ArtifactResolve
Certificats X.509 correspondant à la clé privée utilisée par le fournisseur de services pour décrypter les messages SAML 2.0 entrants cryptés par IdPs distant avec les certificats, tels que les éléments Assertion/NameID/Attribute dans une réponse SSO
Création d'une entrée de partenaire au niveau du fournisseur de services SAML 2.0 qui représente le fournisseur d'identités distant avec les informations suivantes
EntityID ou ProviderID du fournisseur d'identités, qui est l'identificateur unique référençant IdP
URL du service de connexion unique vers lesquelles le fournisseur de services redirige l'utilisateur avec le SAML AuthnRequest
Chacune peut avoir une URL et une liaison différentes (par exemple, 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).
URL du service de déconnexion où le fournisseur de services redirige l'utilisateur lors de l'échange de déconnexion SAML 2.0
Chaque liaison peut être différente (par exemple, urn:oasis:names:tc:SAML:2.0:bindings:HTTPRedirect, urn:oasis:names:tc:SAML:2.0:bindings:HTTP- POST).
Chaque service peut avoir différentes URL pour recevoir un message LogoutRequest et un message LogoutResponse
Certificats X.509 correspondant à la clé privée utilisée par IdP pour signer les messages SAML 2.0 sortants, tels que les messages d'assertion, LogoutRequest/LogoutResponse ou ArtifactResponse
Certificats X.509 correspondant à la clé privée utilisée par IdP pour décrypter les messages SAML 2.0 entrants cryptés par les fournisseurs de services distants avec les éléments (s), tels que l'élément NameID dans une demande de déconnexion

La section ci-dessus couvre uniquement la configuration SSO de fédération. Si les partenaires Federation prennent en charge d'autres services, tels que l'autorité d'attribut et le demandeur d'attribut, davantage d'URL de service et d'informations de certificat doivent être échangées.

Processus manuel

Comme vous pouvez le constater, de nombreuses informations peuvent être échangées entre les administrateurs chargés de la gestion des serveurs Federation et toute erreur mineure peut empêcher la configuration correcte de l'accord de fédération et entraîner des erreurs d'exécution.

Les erreurs pouvant survenir en raison d'un établissement de confiance manuel peuvent être :

Certificat utilisé incorrect
Combinaison URL/liaison de service incorrecte, où par exemple, une URL de service consommateur d'assertion utilisée uniquement pour la liaison d'artefact est utilisée pour la liaison HTTP-POST
Typo dans les URL
Spécification incorrecte du nom d'hôte dans les URL de service : les cookies étant utilisés lors des opérations SSO de fédération. Il est primordial d'utiliser le même nom d'hôte qualifié complet, qui est l'adresse publique que les utilisateurs utilisent pour accéder aux serveurs Federation. (Les adresses IP ou les noms d'hôte non qualifiés complets génèrent des erreurs)
Typo dans le ProviderIDs
URL manquantes

Ces erreurs entraînent :

Echecs de vérification de signature ou de déchiffrement lors de l'utilisation de certificats incorrects. Le serveur génère une erreur car
- Le certificat n'est pas valide
- URL manquantes pour la fonctionnalité utilisée (par exemple, URL de déconnexion manquante)
- Des noms d'hôte incohérents ont été utilisés (complet vs adresse IP vs non qualifié complet) ProviderID est inconnu, causé par une faute de frappe
- Boucles infinies, en raison de l'utilisation de noms d'hôte incohérents

Les erreurs répertoriées ci-dessus se produisent plus que ce que les gens supposent, ce qui entraîne le temps passé à rechercher pourquoi Federation SSO ne fonctionne pas correctement, ce qui indique presque une erreur d'établissement Federation Trust.

Utilisation des métadonnées SAML 2.0

Les spécifications SAML 2.0 définissent le document de métadonnées qui contient toutes les informations dont un serveur a besoin sur son homologue pour effectuer des opérations de fédération avec le partenaire distant.

Ces informations comprennent, notamment :

URL de service
Liaisons SAML pour les services
Certificats pour les opérations de signature et de cryptage
Les messages qui seront signés (AuthnRequest, Assertion)
Rôles pris en charge par le serveur Federation (IdP, SP, Attribute Authority...)

Les métadonnées SAML 2.0 sont généralement générées par le serveur de fédération lui-même et sont utilisées par le serveur de fédération du partenaire. Aucune intervention manuelle n'est donc effectuée pour créer et utiliser ce document et réduire ainsi le nombre d'erreurs potentielles.

L'utilisation des métadonnées SAML 2.0 offre les avantages suivants :

Toutes les informations sont contenues dans un seul document
Le document est généré et utilisé par les serveurs Federation (les signatures peuvent être utilisées pour se protéger contre les altérations)
Aucune information n'est omise
Les données sont cohérentes (mêmes noms d'hôte utilisés dans toutes les URL)

Plus important encore, cela permet de gagner du temps en réduisant les risques d'erreurs lors de l'établissement de confiance de fédération, de sorte qu'il y aura moins de risques d'erreurs d'exécution par la suite.

Ressources de formation supplémentaires

Parcourez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuite sur le canal Oracle Learning YouTube. En outre, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour consulter la documentation du produit, visitez le site Oracle Help Center.

Informations relatives au titre et au copyright

SAML 2.0 Setup Metadata vs No Metadata

F61884-01

September 2022