Configuration de la connexion unique de navigateur Web SAML dans Liberty
Vous pouvez configurer un serveur Liberty pour qu'il fonctionne en tant que fournisseur de services Single-Sign-On (SSO) de navigateur Web SAML.
Pourquoi et quand exécuter cette tâche
Vous pouvez configurer un serveur Liberty en tant que fournisseur de services SAML Web SSO en activant la fonction samlWeb-2.0 dans Liberty, en plus d'autres informations de configuration.
Procédure
- Ajoutez la fonction Liberty samlWeb-2.0 à votre fichier
server.xml en ajoutant la déclaration d'élément suivante
à l'intérieur de l'élément featureManager.
<feature>samlWeb-2.0</feature>
- Liberty fournit un élément samlWebSso20 par défaut.
<samlWebSso20 id="defaultSP"> </samlWebSso20>
Dans cette configuration par défaut, les valeurs par défaut suivantes sont implicites :- URL AssertionConsumerService :
https://<hostname>:<sslport> /ibm/saml20/defaultSP/acs
- URL de métadonnées de fournisseur de services (SP) :
https://<hostname>:<sslport> /ibm/saml20/defaultSP/samlmetadata
Vous pouvez utiliser un navigateur pour télécharger les métadonnées de ce fournisseur de services en utilisant cette URL, et fournir l'URL au fournisseur d'identité SAML afin d'établir une fédération entre le fournisseur de services et le fournisseur d'identité (IdP).
- Le fichier de métadonnées IdP doit être copié dans le répertoire resources/security sur le serveur, et nommé idpMetadata.xml.
- Le nom d'émetteur de l'assertion SAML est utilisé comme domaine de sécurité, et l'ID nom (nameID) est utilisé comme principal pour créer un sujet authentifié à partir de l'assertion SAML.
- La demande AuthnRequest SAML est signée avec une clé privée dans le magasin de clés par défaut du serveur si l'attribut KeyStoreRef n'est pas spécifié. Si l'alias keyAlias n'est pas configuré, samlsp est l'alias clé par défaut. Si l'alias keyAlias n'est pas configuré et que le magasin de clés contient uniquement une clé privée, celle-ci est utilisée dans la signature.
Remarque : Si vous créez une instance de fournisseur de services et que l'instance defaultSP n'est plus requise, vous devez désactiver explicitement l'instance defaultSP en ajoutant le code ci-après au fichier server.xml.<samlWebSso20 id="defaultSP" enabled="false"> </samlWebSso20>
Remarque : Vous devez spécifier une chaîne sécurisée d'URL qui n'est pas nulle comme ID de samlWebSso20. Si l'ID est manquant, l'élément de configuration est omis et n'est pas géré en tant que defaultSP.Remarque : Quand le langage SAML est configuré et activé, toutes les demandes non authentifiées utilisent l'authentification SAML. Pour configurer les types des demandes qui doivent ou non utiliser l'authentification SAML, vous devez configurer un filtre d'authentification comme décrit à l'étape 15. - URL AssertionConsumerService :
- Facultatif : Vous pouvez ajouter <samlWebSso20 id="defaultSP">
au fichier server.xml et personnaliser le fournisseur de services defaultSP. Exemple :
- idpMetadata : Ajoutez ce paramètre pour changer l'emplacement et le nom de fichier des métadonnées de fournisseur d'identité en remplaçant l'emplacement et le nom de fichier par défaut (${server.config.dir}/resources/security/idpMetadata.xml).
- userIdentifier : Ajoutez ce paramètre pour sélectionner un nom d'attribut SAML dont la valeur est utilisée comme nom principal.
- groupIdentifier : Ajoutez ce paramètre pour sélectionner un nom d'attribut SAML dont les valeurs sont incluses en tant que membres de groupe dans le sujet.
- realmName : Utilisez ce paramètre pour spécifier explicitement le nom de domaine pour identifier un principal SAML dans le fournisseur de services. Le nom de domaine par défaut est le nom d'émetteur SAML.
- Facultatif : Vous pouvez créer un ou plusieurs éléments samlWebSso20
avec un ID différent. Par exemple, si vous créez un élément avec un ID mySP,
vous créez réellement une instance SP SAML doté d'une nouvelle URL AssertionConsumerService :
https://<hostname>:<sslport>/ibm/saml20/mySP/acs
Remarque : L'ID que vous choisissez pour samlWebSso20 est inclus dans l'URL du fournisseur de services, y compris l'URL AssertionConsumerService et l'URL de métadonnées. L'ID samlWebSso20 ne doit pas être vide et ne doit pas contenir de caractères d'URL non sécurisés. - Facultatif : Vous pouvez configurer un moteur de fiabilité. Le fournisseur
de services SAML Liberty prend en charge deux types de moteur de fiabilité :
- Moteur de fiabilité de métadonnées : Valide la signature en fonction des informations fournies dans les métadonnées de fournisseur d'identité configurées.
- Moteur de fiabilité PKIX : Valide la fiabilité du certificat dans la signature via la validation PKIX. Les certificats qui transmettent cette validation sont considérés comme sécurisés.
Le moteur de métadonnées est le moteur de fiabilité par défaut. Si vous souhaitez utiliser le moteur de fiabilité PKIX, vous devez ajouter l'élément PKIXTrustEngine et définir l'ancrage sécurisé trustAnchor approprié.
- Facultatif : Vous pouvez configurer le mode de création d'un sujet authentifié
depuis SAML. Par défaut, le fournisseur de services Liberty crée directement
un sujet à partir de l'assertion SAML sans avoir recours à un registre d'utilisateurs local,
ce qui équivaut à la configuration mapToUserRegistry=No. Les autres
options de configuration sont mapToUserRegistry=User ou mapToUserRegistry=Group.
- mapToUserRegistry=No : Le nom de l'émetteur SAML est le domaine et l'ID nom est utilisé pour créer un nom principal et un nom de sécurité unique dans le sujet, et aucun membre de groupe n'est inclus. Vous pouvez configurer les attributs userIdentifier, realmIdentifier, groupIdentifier et userUniqueIdentifier pour créer un sujet authentifié avec un nom d'utilisateur, un nom de domaine, des appartenances à des groupes et un identifiant de sécurité unique personnalisés.
- mapToUserRegistry=User : Sélectionnez cette option si vous souhaitez valider un utilisateur SAML en fonction de votre registre d'utilisateurs local et créer le sujet utilisateur en fonction du registre sur site.
- mapToUserRegistry=Group : Sélectionnez cette option si vous souhaitez valider un groupe SAML en fonction de votre registre d'utilisateurs local et créer un sujet contenant ces groupes validés. Cette option est similaire à l'option mapToUserRegistry=No, à l'exception des appartenances à des groupes qui sont vérifiées en fonction du registre d'utilisateurs local.
- Facultatif : Vous pouvez implémenter l'interface SPI SAML Liberty, com.ibm.wsspi.security.saml2.UserCredentialResolver, en tant que fonction utilisateur afin de mapper dynamiquement une assertion SAML à un sujet Liberty.
- Facultatif : Vous pouvez définir des règles pour indiquer au fournisseur d'identité comment authentifier un utilisateur en configurant un ou plusieurs des attributs suivants lors de l'utilisation d'un flux SSO Web initié par SP : forceAuthn, isPassive, allowCreate, authnContextClassRef et authnContextComparisonType.
- Facultatif : Vous pouvez définir un format NameID obligatoire dans la demande AuthnRequest en utilisant l'attribut nameIDFormat. Vous pouvez spécifier si un format NameID est défini dans la spécification SAML ou bien utiliser le mot clé customize pour spécifier le format NameId personnalisé.
- Facultatif : Vous pouvez configurer plusieurs partenaires de fédération SP et IdP en créant plusieurs éléments samlWebSso20, chaque samlWebSso20 faisant référence à un élément authFilter unique. Tous les authFilters doivent s'exclure les uns les autres. Avec plusieurs samlWebSso20 configurés, chacun peut effectuer une connexion unique avec son fournisseur d'identité fédérée et posséder a propre règle d'authentification et ses propres règles de consommation.
- Facultatif : Ajoutez la prise en charge pour les connexions uniques non sollicités initiées par IdP. Le fournisseur de services SAML Liberty prend en charge les connexions uniques non sollicitées initiées par IdP
avec ou sans exigence de métadonnées IdP sur site. Si vous n'avez pas de métadonnées IdP, ou si vous prévoyez
d'utiliser une connexion unique non sollicitée pour fédérer plusieurs fournisseurs d'identité à un fournisseur
de services Liberty, vous devez ajouter les configurations suivantes :
- Configurez <PKIXTrustEngine>, et importez tous les certificats de signataire IdP dans le magasin de clés de confiance par défaut du serveur Liberty, ou dans l'ancrage sécurisé trustAnchor du moteur de fiabilité PKIXTrustEngine.
- Configurez trustedIssuers afin de répertorier le nom d'émetteur du fournisseur d'identité tel qu'il apparaît dans l'assertion SAML. Le nom d'émetteur est utilisé comme EntityID dans les métadonnées.
- Si vous prévoyez de prendre en charge uniquement les connexions uniques non sollicitées, vous pouvez configurer la connexion unique non sollicitée initiée par SP comme documenté à la prochaine étape. Ce scénario est utile si le contexte de sécurité de l'utilisateur dans le fournisseur de services associé à SAML n'est plus valide : le fournisseur de services peut rediriger l'utilisateur vers le fournisseur d'identité afin de redémarrer automatiquement une connexion unique non sollicité.
- Facultatif : Ajoutez la prise en charge pour les connexions uniques non sollicités initiées par SP. Le fournisseur de services SAML Liberty utilise des métadonnées IdP configurées pour effectuer une demande AuthnRequest SAML sollicitée. Il est possible pour le fournisseur de services Liberty de rediriger les demandes non authentifiées vers une application de connexion préconfigurée sans utiliser AuthnRequest. Ce scénario est utile si une application métier effectue un traitement de préauthentification avant qu'un utilisateur puisse s'authentifier au fournisseur d'identité SAML, ou si le fournisseur de services Liberty ne doit pas voir le fournisseur d'identité SAML. Pour configurer ce scénario, vous ajoutez l'attribut loginPageURL et définissez sa valeur sur une URL pouvant inviter un utilisateur à s'authentifier auprès du fournisseur d'identité SAML.
- Facultatif : Configurez des exigences de signature avec les considérations suivantes :
- Assertion SAML. Toutes les assertions SAML doivent être signées numériquement par le fournisseur d'identité SAML. Dans les rares cas de figure où vous souhaitez accepter une assertion non signée, vous pouvez configurer explicitement wantAssertionsSigned=false.
- L'algorithme de signature par défaut est SHA256. Si vous devez modifier l'algorithme, utilisez l'attribut signatureMethodAlgorithm pour le faire.
- Si vous ne souhaitez pas signer la demande SAML AuthnRequest, vous pouvez définir authnRequestsSigned=false.
- Facultatif : Vous pouvez configurer une session d'authentification et un cookie de fournisseur de services. Une fois l'assertion SAML vérifiée et traitée, le fournisseur de services Liberty conserve une session
authentifiée entre le navigateur et le fournisseur de services sans utiliser de cookie LTPA. Le délai d'attente de session authentifiée est défini sur SessionNotOnOrAfter
dans l'instruction <saml:AuthnStatement>, le cas échéant,
ou dans sessionNotOnOrAfter comme configuré dans le fichier server.xml,
la valeur par défaut étant de 120 minutes. Le nom du cookie de session est automatiquement généré,
et vous pouvez personnaliser celui-ci à l'aide de l'attribut spCookieName afin d'indiquer
le nom de votre choix.
Si vous souhaitez que le fournisseur de services Liberty crée un cookie LTPA à partir de l'assertion SAML et utilise ce cookie pour les demandes d'authentification suivantes, vous pouvez ajouter la configuration disableLtpaCookie=false. Si vous souhaitez partager le cookie LTPA avec d'autres serveurs, ajoutez l'attribut de configuration allowCustomCacheKey="false".
Remarque : Si vous configurez disableLtpaCookie="false" et allowCustomCacheKey="false", assurez-vous qu'un nom d'utilisateur SAML ne s'authentifie pas directement dans un registre d'utilisateurs local, ce qui empêcherait un utilisateur d'avoir deux comptes. - Facultatif : configurez le filtre d'authentification.
Quand la fonction samlWeb-2.0 est activée, toute demande non authentifiée est authentifiée via un fournisseur de services SP. Si vous définissez un élément samlWebSso20 personnalisés, toutes les demandes d'authentification sont gérées par cette instance SP samlWebSso20. Sinon, toute authentification est gérée par l'instance par défaut defaultSP. Vous pouvez utiliser authnFilter pour définir quelle instance de fournisseur de services doit gérer la demande d'authentification.
Pour plus d'informations sur la configuration du filtre d'authentification, voir Filtres d'authentification.
- Facultatif : Configurez le fournisseur de services SAML dans un cluster.
Si des serveurs d'applications sont des membres de cluster et que vous utilisez un routeur ou un serveur proxy inverse pour router vos demandes, vous devez exécuter les tâches suivantes :
- Le routeur et le serveur proxy doivent être configurés pour rendre en charge l'affinité de session.
- ajoutez l'attribut de configuration spHostAndPort à chaque serveur d'applications, définissez-en la valeur sur le nom d'hôte et le port du routeur ou du serveur proxy. Par exemple, spHostAndPort="https://monRouteur.com:443".
- Générez un certificat X509 pour la signature de la demande SAML AuthnRequest, et utilisez ce certificat sur tous les serveurs d'applications. Vous pouvez, par exemple, créer un magasin de clés contenant uniquement ce certificat et ajouter la référence KeyStoreRef pour référencer ce magasin de clés sur tous les serveurs d'applications.
- Si createSession="true" n'est pas défini dans un environnement de cluster,
l'erreur suivante survient lors de l'exécution de charge.
E CWWKS5029E: L'état du relais [sp_initial_KGe22fCWKG1lD9VkOMuDz0Ji8pBxFPnU] dans la réponse du fournisseur d'identité n'a pas été reconnu.
Exemple de configuration de cluster :<keyStore id="samlKeyStore" password="<password>" location="${server.config.dir}/resources/security/<samlKey.jks>" /> <samlWebSso20 id="defaultSP" spHostAndPort="https://<IHS host>:<port>" keyStoreRef="samlKeyStore" createSession="true" allowCustomCacheKey="false" disableLtpaCookie="false" mapToUserRegistry="User"> </samlWebSso20>
Résultats

Nom du fichier : twlp_config_saml_web_sso.html