Configuration de la propagation SAML Web entrante dans Liberty

Vous pouvez configurer un serveur Liberty pour accepter un jeton SAML dans une en-tête HTTP en tant que jeton d'authentification. Cette fonction est communément utilisée pour un client proxy ou RESTful utilisant SAML pour le compte d'un utilisateur authentifié.

Pourquoi et quand exécuter cette tâche

Vous pouvez configurer un serveur Liberty pour accepter un jeton SAML dans une en-tête HTTP en tant que jeton d'authentification en activant la fonction samlWeb-2.0 dans Liberty et en définissant inboundPropagation=required en plus des autres informations de configuration. La configuration de la propagation entrante est similaire à la Configuration du service SAML Web Browser SSO dans Liberty.

Procédure

  1. 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>
  2. Activez la propagation entrante SAML. Le serveur Liberty fournit un élément samlWebSso20 par défaut.
    <samlWebSso20 id="defaultSP">
    
    </samlWebSso20>
    Vous pouvez utiliser cet élément samlWebSso20 par défaut ou créer un nouvel élément samlWebSso20 pour activer la propagation SAML entrante en ajoutant inboundPropagation=required.
    <samlWebSso20 id="defaultSP" inboundPropagation="required" >
    </samlWebSso20>
    Remarque : Lorsque SAML est configuré et activé, toutes les demandes non authentifiées utilisent l'authentification SAML. Pour configurer les types de demandes qui peuvent et ne peuvent pas utiliser l'authentification SAML, vous devez configurer un filtre d'authentification comme décrit dans cette rubrique.
  3. Vous devez configurer le moteur de fiabilité PKIX pour valider 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.
    1. Configurez <PKIXTrustEngine> et importez tous les certificats de signataires SAML sécurisés dans le magasin de clés de confiance par défaut du serveur Liberty ou dans le trustAnchor du PKIXTrustEngine.
    2. Facultatif : Configurez le trustedIssuers pour répertorier le nom d'émetteur du jeton SAML tel qu'il apparaît dans l'assertion SAML si la fiabilité du certificat n'est pas suffisante.
    Voici un exemple de configuration :
    <samlWebSso20 id="defaultSP"          
      inboundPropagation="required"
      headerName="saml_token"
      signatureMethodAlgorithm="SHA1">
      <pkixTrustEngine trustAnchor="serverStore" />
    </samlWebSso20>  
  4. Facultatif : Vous pouvez ajouter headerName pour définir un nom d'en-tête de demande HTTP contenant un jeton SAML. Si cet attribut de configuration n'est pas défini, le serveur Liberty recherche le nom d'en-tête saml, Saml et SAML pour le jeton SAML. L'en-tête de jeton SAML dans la demande HTTP peut avoir l'un des formats suivants :
    Authorization=[<headerName>=<SAML_HERE>]                  
    Authorization=[<headerName>="<SAML_HERE>"] 
    Authorization=[<headerName> <SAML_HERE>]
    <headerName>=[<SAML_HERE>]

    Le jeton SAML doit être codé Base-64 ou UTF-8 et peut être compressé dans le format GZIP.

    Remarque : Le nom d'en-tête du jeton SAML doit être une chaîne URL sûre et ne doit contenir aucun espace de début ou de fin.
  5. Facultatif : Vous pouvez configurer le mode de création d'un sujet authentifié depuis SAML. Par défaut, le fournisseur de service Liberty crée directement un sujet à partir d'une 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 d'émetteur SAML est realm et NameID 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 auprès de votre registre d'utilisateurs local et créer le sujet utilisateur en fonction du registre d'utilisateur local.
    • 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 à mapToUserRegistry=No, à la différence que ces appartenances de groupes sont vérifiées auprès du registre d'utilisateurs local.
  6. 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.
  7. Facultatif : Vous pouvez configurer plusieurs éléments samlWebSso20 et chaque élément samlWebSso20 se réfère à un élément authFilter unique. Tous les éléments authFilter doivent s'exclure entre eux. Si plusieurs éléments samlWebSso20 sont configurés, chacun a ses propres règles d'authentification et d'utilisation.
  8. Facultatif : Configurez des exigences de signature avec les considérations suivantes :

    L'algorithme de signature par défaut est SHA256. Si vous devez modifier l'algorithme, utilisez l'attribut signatureMethodAlgorithm pour le faire.

  9. 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 client 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.
  10. Configurez le filtre d'authentification. Vous pouvez utiliser authnFilter pour définir quel élément samlWebSso20 doit traiter la demande d'authentification de la propagation entrante.

    Pour plus d'informations sur la configuration du filtre d'authentification, voir Filtres d'authentification.

Résultats

Vous avez maintenant établi la configuration requise pour configurer un serveur Liberty pour authentifier une demande HTTP avec un jeton SAML.

Icône indiquant le type de rubrique Rubrique Tâche



Icône d'horodatage Dernière mise à jour: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=twlp_saml_web_inbound_prop
Nom du fichier : twlp_saml_web_inbound_prop.html