Intégration de l'application (entité de confiance)

casso126figsbrfr
HID_application-integration
La boîte de dialogue Intégration de l'application permet de configurer la gestion par le système de fédération des tâches suivantes :
  • Direction des utilisateurs à l'application cible au niveau de l'entité de confiance
  • Mappage des attributs d'assertion vers des attributs utilisés par l'application cible
  • Création de comptes d'utilisateurs par une application de provisionnement tierce
  • Redirection des utilisateurs lors d'un échec d'authentification
Configuration d'application cible (SAML, WSFED)
La section Application cible permet de spécifier l'application cible et la méthode de redirection des utilisateurs vers l'application cible.
  • Mode de redirection
    Indique la méthode utilisée par l'entité de confiance pour rediriger l'utilisateur vers la ressource cible.
    Valeur par défaut :
    Aucune donnée
    Les options disponibles pour ce champ sont les suivantes :
    • Aucune donnée (valeur par défaut)
      L'utilisateur est redirigé vers l'application cible à l'aide d'une redirection HTTP 302 avec un cookie de session, mais pas d'autres données.
    • Données de cookie
      L'utilisateur est redirigé vers l'application cible par la méthode de redirection HTTP 302. Cette redirection inclut un cookie de session et des données de cookie supplémentaires qui sont configurées sur l'entité générant des assertions.
      Pour SAML 1.1 et 2.0, l'activation de cette option affiche le champ supplémentaire suivant :
      Coder les données d'attribut du cookie dans une URL
      Indique que l'attribut envoyé dans le cookie est codé dans une URL. L'attribut est codé dans une URL, car les caractères dans l'URL ont un rôle unique différent du rôle standard d'une URL. Ce paramètre est uniquement valide avec des données de cookie en mode de redirection.
      Si vous spécifiez un caractère spécial dans la table d'attributs d'application, sélectionnez cette option. Par exemple, sélectionnez ce paramètre pour tout attribut contenant des caractères japonais. Vous pouvez ajouter des caractères spéciaux à partir de la liste déroulante ou manuellement. En outre, l'application cible doit décoder le nom et la valeur de l'attribut d'application reçu.
       
    • Cookie au format source libre
      L'utilisateur est redirigé vers l'application cible à l'aide d'une redirection HTTP 302 avec un cookie au format source libre, sans autre donnée. L'application consommateur déchiffre le cookie chiffré pour obtenir les informations de l'utilisateur.
      Si l'entité de confiance reçoit une assertion avec plusieurs valeurs d'attribut, elle transfère toutes ces valeurs à l'application cible.
    • Publication de cookie au format libre
      L'utilisateur est redirigé vers l'application cible à l'aide d'une redirection HTTP 302 avec un cookie au format libre, mais les données sont envoyées dans une demande HTTP-POST. Si vous redoutez que les données se perdent en raison de la limite de longueur des données de cookie, sélectionnez cette option.
      Si vous sélectionnez l'option Cookie au format libre ou Publication de cookie au format libre, l'interface utilisateur affiche les champs supplémentaires suivants :
      • Nom de cookie au format source libre
        Spécifie le nom du cookie au format source libre.
      • Transformation du chiffrement
        Indique l'algorithme de chiffrement permettant de chiffrer le cookie au format source libre.
        Si vous sélectionnez l'un des algorithmes compatibles avec FIPS (algorithmes AES), le système cible doit utiliser un kit de développement logiciel
        CA SiteMinder® Federation
        pour consommer le cookie. Les kits de développement logiciel doivent être placés sur le même serveur que l'application cible.
        Si vous utilisez le kit de développement logiciel .NET pour consommer le cookie, utilisez l'algorithme de chiffrement AES128/CBC/PKCS5Padding.
      • Mot de passe de chiffrement
        Indique le mot de passe utilisé pour chiffrer le cookie. Les champs Mot de passe de chiffrement et Confirmer le mot de passe sont requis pour le cookie au format source libre, mais le mot de passe est facultatif pour le cookie hérité.
        Important :
        Si vous spécifiez un mot de passe pour le cookie hérité, définissez la même valeur pour le kit de développement logiciel Java de
        CA SiteMinder® Federation
        . Le mot de passe permet au kit de développement logiciel de déchiffrer le cookie. Les valeurs sont partagées dans une communication hors bande.
      • Confirmer le mot de passe
        Confirme le mot de passe de chiffrement saisi.
      • Activer le code HMAC
        Indique qu'un code d'authentification de message avec hachage (HMAC) est généré à l'aide du mot de passe de chiffrement fourni dans cette boîte de dialogue.
        Les codes d'authentification de message (MAC) peuvent vérifier l'intégrité des informations envoyées entre deux parties. Les deux parties partagent une clé secrète pour le calcul et la vérification des valeurs d'authentification de message. Un code d'authentification de message avec hachage (HMAC) est un mécanisme MAC basé sur des fonctions d'hachage cryptographiques. Les codes HMAC ont une entrée de message et une clé secrète connue uniquement de l'auteur du message et du destinataire spécifique.
        Si vous sélectionnez la case à cocher Activer le code HMAC, le système générera une valeur HMAC pour son cookie au format source libre. La valeur HMAC est ajoutée au début de la valeur du cookie au format source libre, puis chiffre la chaîne entière. Le système place la chaîne chiffrée dans le cookie au format source libre, alors transmis à l'application cible.
      • Activer les cookies entre guillemets
        Indique que la valeur du cookie au format source libre est entourée de guillemets doubles. Cette spécification permet le traitement du cookie lorsque les caractères non pris en charge sont inclus dans la valeur de ce cookie.
    • En-têtes HTTP (SAML 1.1 et 2.0 uniquement)
      L'utilisateur est redirigé vers l'application cible avec des en-têtes HTTP, sans autre donnée. Le serveur de stratégies peut livrer plusieurs valeurs d'attribut dans un en-tête unique en les séparant par une virgule.
    • Conserver les attributs
      Permet de rediriger l'utilisateur à l'aide d'une redirection 302 HTTP contenant un cookie de session, sans autre donnée. Ce mode charge également le serveur de stratégies de stocker des attributs extraits d'une assertion dans le référentiel de sessions.
      CA Single Sign-on
      peut ainsi fournir les attributs comme variables d'en-tête HTTP.
      Pour afficher cette option, activez le référentiel de sessions à l'aide de la console de gestion de serveur de stratégies.
       Si vous sélectionnez l'option Conserver les attributs, mais que l'assertion contient des attributs vides, une valeur NULL apparaît dans le référentiel de sessions. Cette valeur agit comme un espace réservé pour l'attribut vide et est transmise à toute application utilisant l'attribut.
    • casso126figsbrfr
      Redirection à partir du serveur
      Permet de charger le système de fédération de transférer des attributs d'en-tête et de cookie reçus dans l'assertion vers l'application cible. Le service qui consomme des assertions collecte les informations d'identification de l'utilisateur, puis transfère l'utilisateur vers l'URL de l'application cible à l'aide de la redirection à partir du serveur Java.
      Pour utiliser ce mode, suivez les indications suivantes :
      • Tous les fichiers de l'application cible doivent être placés dans le répertoire racine de l'application. Il peut s'agir de l'un des répertoires suivants :
        • Agent Web :
          accueil_agent_Web
          \webagent\affwebservices
        • Passerelle de fédération de serveur proxy sécurisé :
          accueil_serveur_proxy_sécurisé
          \secure-proxy\Tomcat\webapps\affwebservices
           
      • L'URL cible que vous spécifiez doit être
        relative
        au contexte du servlet qui consomme l'assertion. Le contexte est
        /affwebservices/public/
        et la racine du contexte
        /affwebservices/
        , qui correspond à la racine de l'application Services Web de fédérations. L'adresse URL ne doit pas inclure le contexte. Par exemple, l'URL cible peut être
        /applications/doc1.html
        .
      • Pour protéger des ressources cibles, définissez des domaines, des règles et des stratégies. Dans le filtre de ressources, les domaines d'authentification doivent contenir au moins la valeur /affwebservices/.
      • Sur le serveur exécutant l'application Services Web de fédérations, installez une application Java ou JSP personnalisée. Le pack d'options d'agent Web ou la passerelle de fédération de serveur proxy sécurisé installent des services Web de fédérations.
        La technologie de servlet Java autorise les applications à transférer des informations entre deux demandes de ressource à l'aide de la méthode setAttribute de l'interface ServletRequest.
        Le service qui consomme des assertions envoie les attributs d'utilisateur à l'application cible avant de rediriger l'utilisateur vers la cible. Il envoie les attributs en créant un objet java.util.HashMap. Netegrity.AttributeInfo est l'attribut contenant la table d'hachage d'attributs SAML.
        Le service qui consomme des assertions transfère deux autres attributs Java.lang.String à l'application personnalisée :
        • L'attribut Netegrity.smSessionID représente l'ID de session.
        • L'attribut Netegrity.userDN représente le nom unique de l'utilisateur.
      L'application cible lit ces objets à partir de la demande HTTP et utilise les données présentes dans les objets de la table d'hachage.
  • Cible
    Spécifie l'URL de l'application cible au niveau de l'entité de confiance. La valeur saisie ici devient la ressource cible par défaut. Cette adresse URL doit contenir un nom de domaine complet, sauf si vous sélectionnez le mode Redirection à partir du serveur. Si vous activez le mode de redirection à partir du serveur, l'adresse URL cible doit être
    relative
    au contexte du servlet consommant l'assertion. Le contexte est
    /affwebservices/public/
    . L'adresse URL ne doit pas inclure le contexte. Par exemple, l'URL cible peut être
    /applications/doc1.html
    .
    Si un proxy se trouve en face du serveur contenant la ressource cible, saisissez l'URL de l'hôte proxy. Le proxy gère toutes les demandes de fédération localement. L'hôte proxy peut être un système placé en face du serveur cible. Vous pouvez également utiliser le logiciel
    Single Sign-On
    comme hôte de proxy, si vous y accédez de manière directe à partir d'Internet. Enfin, si vous utilisez un proxy, l'URL spécifiée comme cible doit passer par
    Single Sign-On
    . Par exemple, si l'URL de base est fed.demo.com et que la ressource de serveur principal est mytarget/target.jsp, la valeur de ce champ sera http://fed.demo.com:5555/mytarget/target.jsp.
    Pour SAML 2.0, vous pouvez laisser ce champ vide si vous le remplacez par le paramètre de requête RelayState. Ce paramètre de requête RelayState peut remplacer une partie de l'URL qui déclenche l'authentification unique. Pour activer ce remplacement, sélectionnez la case à cocher Remplacement de la cible par l'état du relais.
  • Délai d'inactivité
    Permet de déterminer la durée d'inactivité d'une session d'utilisateur autorisée avant que l'agent ne termine la session. Si vous voulez limiter les problèmes que peut supposer l'abandon de la station de travail d'un utilisateur après son accès à une ressource protégée, définissez le délai d'inactivité sur une période courte. Si la session expire, les utilisateurs devront se réauthentifier avant d'accéder à nouveau aux ressources.
    Ce paramètre est activé par défaut. Pour ne spécifier aucune durée d'inactivité, décochez la case. Le délai d'inactivité de session par défaut est une heure.
    Remarque :
    Une fois que le délai d'inactivité spécifié s'est écoulé, la session expire après un certain délai de maintenance. Le nombre de secondes spécifiées dans la clé de registre suivante détermine la période :
    HKEY_LOCAL_MACHINE\SOFTWARE\Netegrity\
    CA Single Sign-on
    \CurrentVersion\SessionServer\MaintenancePeriod
    Par exemple, vous avez défini le délai d'inactivité sur 10 minutes. Vous avez défini également le registre pour la période de maintenance sur la valeur par défaut. La période la plus longue avant l'expiration d'une session due à l'inactivité est de 11 minutes (période de maintenance + délai d'expiration).
    Pour utiliser cette fonctionnalité avec le schéma d'authentification de base, l'agent Web est configuré de sorte à requérir des cookies.
    Tenez compte des problématiques suivantes :
    • Lors des sessions persistantes, activez le délai d'inactivité et définissez-le sur une valeur plus supérieure à la période de validation.
    • Vous pouvez remplacer ce paramètre global à l'aide de l'attribut de réponse WebAgent-OnAuthAccept-Session-Idle-Timeout. Une valeur zéro indique que l'inactivité de l'utilisateur n'entraînera pas l'expiration de la session.
    Valeur par défaut :
    60 secondes
    Heures
    Spécifie le nombre d'heures pour le délai d'inactivité.
    Minutes
    Spécifie le nombre de minutes pour le délai d'inactivité.
    Délai d'expiration maximum
    Détermine la durée d'activité maximum d'une session d'utilisateur avant que l'agent ne requiert sa réauthentification.
    Ce paramètre est activé par défaut. Pour ne spécifier aucune durée maximum de session, décochez la case. La durée maximum de session par défaut est de deux heures.
    • Heures
      Spécifie le nombre d'heures pour la durée maximum de session.
    • Minutes
      Spécifie le nombre de minutes pour la durée maximum de session.
    Pour utiliser cette fonctionnalité avec le schéma d'authentification de base, l'agent Web doit requérir des cookies.
    Remarque :
    Vous pouvez remplacer ce paramètre à l'aide de l'attribut de réponse WebAgent-OnAuthAccept-Session-Max-Timeout.
  • Remplacement de la cible par l'état du relais (uniquement SAML 2.0)
    (Facultatif) Remplace la valeur du champ cible par la valeur de paramètre de requête d'état du relais dans la demande qui initialise l'authentification unique. En sélectionnant cette option, vous contrôlez davantage la cible, car l'utilisation du paramètre de requête d'état du relais permet de définir de façon dynamique la cible.
  • Valider le domaine de l'URL cible
    (SAML 2.0 uniquement) Indique au serveur de stratégies qu'il doit comparer la valeur du champ Cible ou la cible spécifiée dans le paramètre de requête RelayState au paramètre ValidFedTargetDomain de l'objet Configuration d'agent. Ce paramètre permet de garantir que l'entité de confiance autorise l'accès au domaine cible demandé.
  • Conserver les variables de session d'authentification
    Permet de stocker les informations d'une assertion dans le référentiel de sessions et de les écrire dans le contexte de session. Le stockage d'informations d'assertion dans le référentiel de sessions permet d'utiliser les informations pour des fonctions, telles que des réponses actives et des expressions de stratégie. Si vous sélectionnez cette case à cocher, les informations d'assertion stockées incluent les valeurs de NameID, NameIDFormat, ProviderID et AuthnContext.
    Ce paramètre est différent de l'option Conserver les attributs pour le mode de redirection vers l'application cible. Lorsque vous conservez des variables de session d'authentification, les informations sont disponibles pour l'utilisation de manière plus simple que des en-têtes HTTP.
    Important :
    Pour afficher cette case à cocher, activez le référentiel de sessions à l'aide de la console de gestion de serveur de stratégies . De même, sélectionnez la case à cocher Utiliser une session persistante dans les paramètres d'authentification unique de la configuration du partenariat.
  • Remplacement de la cible par défaut par le paramètre de requête (SAML 1.1 uniquement)
    (Facultatif) Remplace la valeur du champ Cible par la valeur de paramètre de requête cible dans la demande qui initialise l'authentification unique. En sélectionnant cette option, vous contrôlez davantage la cible, car l'utilisation du paramètre de requête permet de définir de façon dynamique la cible.
  • Période de validité du cookie
    Indique la durée de validité du cookie au format source libre. La période de validité est placée dans le cookie de sorte que l'application cible puisse vérifier la validité du cookie avant qu'il ne consomme les données. Vous pouvez définir cette valeur pour les modes de redirection du cookie au format source libre et les en-têtes HTTP ; les en-têtes HTTP utilisent le cookie au format source libre. Pour le cookie au format source libre, l'application détermine l'action à entreprendre lors de l'expiration du cookie. Pour les en-têtes HTTP,
    CA Single Sign-on
    arrête l'envoi du cookie expiré.
    Saisissez une période en heures, minutes et secondes. La valeur 00:00:00 indique que le cookie n'expire jamais.
Configuration d'application cible (OAuth)
La section Application cible permet de spécifier l'application cible et la méthode de redirection des utilisateurs vers l'application cible.
  • Mode de redirection
    Indique la méthode utilisée par l'entité de confiance pour rediriger l'utilisateur vers la ressource cible. Valeurs possibles :
    • Aucune donnée
      Spécifie que l'utilisateur est redirigé vers l'application cible à l'aide d'une redirection HTTP 302 avec un cookie de session, mais pas d'autres données.
    • Données de cookie
      Spécifie que l'utilisateur est redirigé vers l'application cible à l'aide d'une redirection HTTP 302 avec un cookie de session et des données de cookie supplémentaires configurées au niveau de l'entité générant des assertions. Si vous sélectionnez cette option, l'option suivante est disponible :
      • Coder les données d'attribut du cookie dans une URL
        Indique que l'attribut envoyé dans le cookie est codé dans une URL. La désignation codée dans une URL est nécessaire, car les caractères dans l'URL ont un rôle unique différent du rôle standard d'une URL. Ce paramètre est uniquement valide avec des données de cookie en mode de redirection. Si les données de cookie contiennent des revendications à valeurs multiples, vous devez sélectionner cette option.
        Si vous spécifiez un caractère spécial dans la table d'attributs d'application, sélectionnez cette option. Par exemple, sélectionnez ce paramètre pour tout attribut contenant des caractères japonais. Vous pouvez ajouter des caractères spéciaux à partir de la liste déroulante ou manuellement. En outre, l'application cible doit décoder à l'aide de l'URL le nom et la valeur de l'attribut d'application reçu.
    • Cookie au format source libre
      Spécifie que l'utilisateur est redirigé vers l'application cible à l'aide d'une redirection HTTP 302 avec un cookie au format source libre, sans autre donnée. L'application consommateur déchiffre le cookie chiffré pour obtenir les informations de l'utilisateur.
      Si l'entité de confiance reçoit une revendication avec plusieurs valeurs d'attribut, elle transfère toutes ces valeurs à l'application cible.
    • Publication de cookie au format libre
      L'utilisateur est redirigé vers l'application cible à l'aide d'une redirection HTTP 302 avec un cookie au format libre, mais les données sont envoyées dans une demande HTTP-POST. Si vous redoutez que les données se perdent en raison de la limite de longueur des données de cookie, sélectionnez cette option.
    Si vous sélectionnez l'option de cookie au format source libre pour l'authentification déléguée, l'interface utilisateur affiche les champs supplémentaires suivants :
  • Nom de cookie au format source libre
    Spécifie le nom du cookie au format source libre.
  • Transformation du chiffrement
    Indique l'algorithme de chiffrement à utiliser pour chiffrer le cookie au format source libre.
    Si vous sélectionnez l'un des algorithmes compatibles avec FIPS (algorithmes AES), le système cible doit utiliser un kit de développement logiciel pour consommer le cookie. Les kits de développement logiciel doivent être placés sur le même serveur que l'application cible.
    Si vous utilisez le kit de développement logiciel .NET pour consommer le cookie, utilisez l'algorithme de chiffrement AES128/CBC/PKCS5Padding.
  • Mot de passe de chiffrement
    Indique le mot de passe utilisé pour chiffrer le cookie.
  • Confirmer le mot de passe
    Confirme le mot de passe de chiffrement saisi.
  • Activer le code HMAC
    Indique qu'un code d'authentification de message avec hachage (HMAC) est généré à l'aide du mot de passe de chiffrement fourni dans cette boîte de dialogue.
    Les codes d'authentification de message (MAC) peuvent vérifier l'intégrité des informations envoyées entre deux parties. Les deux parties partagent une clé secrète pour le calcul et la vérification des valeurs d'authentification de message. Un code d'authentification de message avec hachage (HMAC) est un mécanisme MAC basé sur des fonctions d'hachage cryptographiques. Les codes HMAC ont une entrée de message et une clé secrète connue uniquement de l'auteur du message et du destinataire spécifique.
    Si vous sélectionnez la case à cocher Activer le code HMAC, le système générera une valeur HMAC pour son cookie au format source libre. La valeur HMAC est ajoutée au début de la valeur du cookie au format source libre, puis chiffre la chaîne entière. Le système place la chaîne chiffrée dans le cookie au format source libre, alors transmis à l'application cible.
  • Activer les cookies entre guillemets
    Indique que la valeur du cookie au format source libre est entourée de guillemets doubles. Cette spécification permet le traitement du cookie lorsque les caractères non pris en charge sont inclus dans la valeur de ce cookie.
  • Période de validité du cookie
    Indique la durée de validité du cookie au format source libre. La période de validité est placée dans le cookie de sorte que l'application cible puisse vérifier la validité du cookie avant qu'il ne consomme les données. L'application détermine l'opération à effectuer après l'expiration du cookie.
    Saisissez une période en heures, minutes et secondes.
  • En-têtes HTTP (mode Proxy uniquement)
    L'utilisateur est redirigé vers l'application cible avec des en-têtes HTTP, sans autre donnée.
  • Conserver les demandes dans le référentiel de sessions
    Permet de rediriger l'utilisateur à l'aide d'une redirection 302 HTTP contenant un cookie de session, sans autre donnée. Ce mode charge également le serveur de stratégies de stocker des attributs extraits d'une assertion dans le référentiel de sessions. Le système peut alors fournir les attributs comme variables d'en-tête HTTP.
    Remarque :
    Vous pouvez sélectionner PersistClaims (Conserver les demandes) alors que l'assertion contient des attributs vides. Dans ce cas, la valeur Nul sera écrite dans le référentiel de sessions. Cette valeur agit comme un espace réservé pour l'attribut vide et est transmise à toute application utilisant l'attribut.
  • Cible
    Spécifie l'URL de l'application cible au niveau de l'entité de confiance. La valeur saisie ici devient la ressource cible par défaut. L'adresse URL doit contenir un nom de domaine complet.
    Si un proxy se trouve en face du serveur contenant la ressource cible, saisissez l'URL de l'hôte proxy. Le proxy gère toutes les demandes de fédération localement. L'hôte proxy peut être un système placé en face du serveur cible. Il peut également s'agir du système, car il est accessible directement à partir d'Internet. Enfin, si vous utilisez un proxy, l'URL spécifiée comme cible doit passer par le système de fédération. Par exemple, si l'URL de base est fed.demo.com et que la ressource de serveur principal est mytarget/target.jsp, la valeur de ce champ sera http://fed.demo.com:5555/mytarget/target.jsp.
    Laissez ce champ vide si vous le remplacez par le paramètre de requête RelayState. Ce paramètre de requête RelayState peut remplacer une partie de l'URL qui déclenche l'authentification unique. Pour activer ce remplacement, sélectionnez la case à cocher Remplacement de la cible par l'état du relais.
  • Délai d'inactivité
    Permet de déterminer la durée d'inactivité d'une session d'utilisateur autorisée avant que le système de fédération ne termine la session. Si vous voulez limiter les problèmes que peut supposer l'abandon de la station de travail d'un utilisateur après son accès à une ressource protégée, définissez le délai d'inactivité sur une période courte. Si la session expire, les utilisateurs devront se réauthentifier avant d'accéder à nouveau aux ressources.
    Ce paramètre est activé par défaut. Pour ne spécifier aucune durée d'inactivité, décochez la case. Le délai d'inactivité de session par défaut est une heure.
    Remarque :
    Lors des sessions persistantes, activez le délai d'inactivité et définissez-le sur une valeur supérieure à la période de validation.
    Valeur par défaut :
    1 heure
    Heures
    Spécifie le nombre d'heures pour le délai d'inactivité.
    Minutes
    Spécifie le nombre de minutes pour le délai d'inactivité.
    Délai d'expiration maximum
    Détermine la durée d'activité maximum d'une session d'utilisateur avant que le système de fédération ne requiert sa réauthentification.
    Ce paramètre est activé par défaut. Pour ne spécifier aucune durée maximum de session, décochez la case.
    Valeur par défaut :
    2 heures
    • Heures
      Spécifie le nombre d'heures pour la durée maximum de session.
    • Minutes
      Spécifie le nombre de minutes pour la durée maximum de session.
  • Remplacement de la cible par l'état du relais
    (Facultatif) Remplace la valeur du champ cible par la valeur de paramètre de requête d'état du relais dans la demande qui initialise l'authentification unique. En sélectionnant cette option, vous contrôlez davantage la cible, car l'utilisation du paramètre de requête d'état du relais permet de définir de façon dynamique la cible.
  • Valider le domaine de l'URL cible
    Indique au système de fédération de comparer la valeur du champ Cible ou la cible spécifiée dans le paramètre de requête RelayState au paramètre ValidFedTargetDomain dans l'objet de configuration d'agent. Ce paramètre permet de garantir que l'entité de confiance autorise l'accès au domaine cible demandé.
Mappage vers des attributs d'application (SAML, WSFED)
La section Mapper vers les attributs d'application indique comment mapper des attributs d'assertion vers des attributs utilisés par l'application cible.
  • Activer le mappage d'attributs
    Indique que le mappage d'attributs est activé. Si vous sélectionnez la case à cocher Enable Application Attributes (activer les attributs d'application), la table Définitions d'attribut d'application s'affiche. Cette table permet de spécifier la méthode de mappage d'attributs d'application vers des attributs d'assertion.
    Les colonnes de la table suivantes doivent être renseignées :
    Attribut d'application
    Indique l'attribut utilisé par l'application cible. Par défaut, le nom d'attribut d'application est identique au nom d'attribut d'assertion. Vous pouvez remplacer le nom d'attribut d'application par celui requis par l'application.
    Attributs d'assertion
    Spécifie les attributs de l'assertion que vous voulez utiliser comme base pour le mappage d'un attribut d'application.
    Si vous sélectionnez le bouton <<, le champ Ajouter affiche. Dans la liste déroulante Ajouter, vous pouvez sélectionner les attributs d'assertion disponibles et les caractères spéciaux à inclure dans la règle de mappage.
Mappage vers les attributs d'application (OAuth)
La section Mapper vers les attributs d'application indique la méthode de mappage des attributs de la demande vers des attributs utilisés par l'application cible.
  • Activer le mappage d'attributs
    Indique que le mappage d'attributs est activé. Si vous sélectionnez la case à cocher Activer le mappage d'attributs, la table Définitions d'attribut d'application s'affiche. Cette table permet de spécifier la méthode de mappage d'attributs d'application vers des attributs d'assertion.
    Les colonnes de la table suivantes doivent être renseignées :
    Attribut d'application
    Indique l'attribut utilisé par l'application cible. Par défaut, le nom d'attribut d'application est identique au nom d'attribut d'assertion. Vous pouvez remplacer le nom d'attribut d'application par celui requis par l'application.
    Attributs de la demande
    Spécifie les attributs des demandes que vous voulez utiliser comme base pour le mappage d'un attribut d'application.
    Si vous sélectionnez le bouton <<, le champ Ajouter affiche. Dans la liste déroulante Ajouter, vous pouvez sélectionner les caractères spéciaux à inclure dans la règle de mappage.
Provisionnement d'utilisateur (SAML, WSFED)
La section Provisionnement d'utilisateur permet de déterminer comment une application de provisionnement tierce établit des comptes d'utilisateurs.
  • Provisionnement d'utilisateur
    Cette section permet de déterminer le fonctionnement du provisionnement d'utilisateur.
  • Type de provisionnement
    Indique si une application de provisionnement distante établit des comptes d'utilisateurs. Si le serveur de stratégies fonctionne avec une application de provisionnement, sélectionnez Distant.
    Par défaut :
    Aucune
    Options :
    Aucun, Distante
    Remarque :
    Vous pouvez sélectionner Distant comme type de provisionnement. Dans ce cas, configurez une option de livraison qui transfère les données d'assertion vers l'application de provisionnement.
  • Options de livraison
    (Provisionnement distant uniquement) Définit le mode de redirection du navigateur avec les données d'assertion vers l'application de provisionnement. Les données d'assertion peuvent être transférées dans un cookie ou des en-têtes HTTP.
    Options :
    • Cookie au format source libre
      Fournit des informations d'assertion SAML dans un cookie au format source libre. Si un cookie au format source libre est utilisé, l'application de provisionnement peut lire le cookie sans utiliser de kit de développement logiciel. Si l'application de provisionnement utilise .NET, le kit de développement logiciel .NET peut être installé sur le serveur de provisionnement et sera utilisé pour lire le cookie au format source libre.
    • Publication de cookie au format libre
      Fournit les informations d'assertion dans un cookie au format libre, mais les données sont envoyées dans une demande HTTP POST. Si vous redoutez que les données se perdent en raison de la limite de longueur des données de cookie, sélectionnez cette option.
    • En-têtes HTTP
      Le serveur de stratégies transfère les données d'assertion dans les en-têtes HTTP.
  • URL du serveur de provisionnement
    Identifie l'URL du serveur tiers hébergeant l'application de provisionnement.
    Valeur :
    une URL valide
Si vous sélectionnez l'option Cookie au format libre, remplissez les champs facultatifs suivants :
Nom de cookie au format source libre
Spécifie le nom du cookie au format source libre.
  • Transformation du chiffrement
    Indique l'algorithme de chiffrement permettant de chiffrer le cookie au format source libre.
  • Mot de passe de chiffrement
    Indique le mot de passe utilisé pour chiffrer le cookie. Les champs Mot de passe de chiffrement et Confirmer le mot de Passe sont requis pour le cookie au format source libre, mais les paramètres sont facultatifs pour le cookie hérité.
    Si vous fournissez un mot de passe au cookie hérité, définissez la même valeur pour le kit de développement logiciel Java de
    CA SiteMinder® Federation
    . Ce kit de développement logiciel requiert le mot de passe pour déchiffrer le cookie. Les valeurs sont partagées dans une communication hors bande.
  • Confirmer le mot de passe
    Confirme le mot de passe de chiffrement saisi.
  • Activer le code HMAC
    Indique que le système génère un code d'authentification de message avec hachage (HMAC) à l'aide du mot de passe de chiffrement fourni dans cette boîte de dialogue.
    Les codes d'authentification de message (MAC) peuvent vérifier l'intégrité des informations envoyées entre deux parties. Les deux parties partagent une clé secrète pour le calcul et la vérification des valeurs d'authentification de message. Un code d'authentification de message avec hachage (HMAC) est un mécanisme MAC basé sur des fonctions d'hachage cryptographiques. Les codes HMAC ont une entrée de message et une clé secrète connue uniquement de l'auteur du message et du destinataire spécifique.
    Si vous sélectionnez la case à cocher Activer le code HMAC, le système générera une valeur HMAC pour son cookie au format source libre. La valeur HMAC est ajoutée au début de la valeur du cookie au format source libre, puis chiffre la chaîne entière.
    CA Single Sign-on
    place la chaîne chiffrée dans le cookie au format libre, alors transmis à l'application cible.
  • Activer les cookies entre guillemets
    Indique que la valeur du cookie au format source libre est entourée de guillemets doubles. Cette spécification permet le traitement du cookie lorsque les caractères non pris en charge sont inclus dans la valeur de ce cookie.
Période de validité du cookie
Indique la durée de validité du cookie au format source libre. La période de validité est placée dans le cookie de sorte que l'application cible puisse vérifier la validité du cookie avant qu'il ne consomme les données. Vous pouvez définir cette valeur pour les modes de redirection du cookie au format source libre et les en-têtes HTTP ; les en-têtes HTTP utilisent le cookie au format source libre. Pour le cookie au format source libre, l'application détermine l'action à entreprendre lors de l'expiration du cookie. Pour les en-têtes HTTP, l'agent arrête d'envoyer le cookie expiré.
Saisissez une période en heures, minutes et secondes.
Provisionnement d'utilisateur (OAuth)
La section Provisionnement d'utilisateur permet de déterminer comment une application de provisionnement tierce établit des comptes d'utilisateurs.
    • Type de provisionnement
      Indique si une application de provisionnement distante établit des comptes d'utilisateurs.
    • Options de livraison
      Définit le mode de redirection d'un navigateur contenant des données d'utilisateur vers l'application de provisionnement. Le système de fédération peut transférer les données d'utilisateur à l'aide d'un cookie ou d'en-têtes HTTP. Options possibles :
      • Cookie au format source libre
        Fournit des informations d'utilisateur OAuth dans un cookie au format libre. Si un cookie au format source libre est utilisé, l'application de provisionnement peut lire le cookie sans utiliser de kit de développement logiciel. Si l'application de provisionnement utilise .NET, installez le kit de développement logiciel .NET sur le serveur de provisionnement. Il sera utilisé pour lire le cookie au format source libre.
      • Publication de cookie au format libre
        Fournit les informations d'utilisateur OAuth dans un cookie au format libre, mais les données sont envoyées dans une demande HTTP POST. Si vous redoutez que les données se perdent en raison de la limite de longueur des données de cookie, sélectionnez cette option.
      Si vous sélectionnez l'option Cookie au format libre, remplissez les champs facultatifs suivants :
    • Nom de cookie au format source libre
      Spécifie le nom du cookie au format source libre.
    • Transformation du chiffrement
      Indique l'algorithme de chiffrement à utiliser pour chiffrer le cookie au format source libre.
    • Mot de passe de chiffrement et Confirmer le mot de passe
      Indique le mot de passe utilisé pour chiffrer le cookie. Les champs Mot de passe de chiffrement et Confirmer le mot de passe sont requis pour le cookie au format source libre.
    • Activer le code HMAC
      Indique qu'un code d'authentification de message avec hachage (HMAC) est généré à l'aide du mot de passe de chiffrement fourni dans cette boîte de dialogue.
      Les codes d'authentification de message (MAC) peuvent vérifier l'intégrité des informations envoyées entre deux parties. Les deux parties partagent une clé secrète pour le calcul et la vérification des valeurs d'authentification de message. Un code d'authentification de message avec hachage (HMAC) est un mécanisme MAC basé sur des fonctions d'hachage cryptographiques. Les codes HMAC ont une entrée de message et une clé secrète connue uniquement de l'auteur du message et du destinataire spécifique.
      Si vous sélectionnez la case à cocher Activer le code HMAC, le système générera une valeur HMAC pour son cookie au format source libre. La valeur HMAC est ajoutée au début de la valeur du cookie au format source libre, puis chiffre la chaîne entière. Le système de fédération place la chaîne chiffrée dans le cookie au format source libre, alors transmis à l'application cible.
    • Activer les cookies entre guillemets
      Indique que la valeur du cookie au format source libre est entourée de guillemets doubles. Cette spécification permet le traitement du cookie lorsque les caractères non pris en charge sont inclus dans la valeur de ce cookie.
En-têtes HTTP (mode Proxy uniquement)
  • Si le système fonctionne en mode Proxy, il transfère des données d'assertion dans des en-têtes HTTP.
  • URL du serveur de provisionnement
    Identifie l'URL du serveur tiers hébergeant l'application de provisionnement.
  • Période de validité du cookie
    Indique la durée de validité du cookie au format source libre. La période de validité est placée dans le cookie de sorte que l'application cible puisse vérifier la validité du cookie avant qu'il ne consomme les données. Vous pouvez définir cette valeur pour les modes de redirection du cookie au format source libre et des en-têtes HTTP. Les en-têtes HTTP utilisent le cookie au format source libre. Pour le cookie au format source libre, l'application détermine l'action à entreprendre lors de l'expiration du cookie. Pour les en-têtes HTTP, le système arrête d'envoyer le cookie expiré.
URL de redirection selon le statut (SAML, WSFED)
La section URL de redirection selon le statut permet de déterminer le mode de redirection par
CA Single Sign-on
d'un utilisateur en cas d'échec d'authentification.
L'authentification basée sur une assertion peut échouer à l'emplacement consommant des assertions. Si c'est le cas, le système de fédération fournit une fonctionnalité permettant de rediriger l'utilisateur vers différentes applications (URL) pour un traitement plus approfondi. Par exemple, en cas d'échec de la résolution d'ambigüité d'utilisateur, vous pouvez configurer
CA Single Sign-on
de sorte à envoyer l'utilisateur vers un système de provisionnement. Ce système de provisionnement peut créer un compte d'utilisateur basé sur les informations présentes dans l'assertion SAML.
Vous pouvez configurer une ou plusieurs de ces options. Si la condition ayant entraîné l'échec se reproduit,
CA Single Sign-on
redirige l'utilisateur vers l'URL configurée.
Remarque :
La redirection des erreurs a lieu uniquement lorsque le système peut analyser la demande et dispose des informations nécessaires pour identifier les partenaires générant des assertions et les partenaires de confiance.
Elle comprend les paramètres suivants :
  • Utilisateur introuvable
    Identifie l'URL vers laquelle le système redirige l'utilisateur sous l'une des conditions suivantes :
    • Un LoginID n'est pas présent dans le message d'authentification unique.
    • L'annuaire d'utilisateurs ne contient pas le LoginID avec la chaîne de recherche définie.
  • Message d'authentification unique non valide
    Identifie l'URL vers laquelle
    CA Single Sign-on
    redirige l'utilisateur sous l'une des conditions suivantes :
    • Selon les règles spécifiées par les schémas SAML, le message d'authentification unique n'est pas valide.
    • Le consommateur requiert une assertion chiffrée, or le message d'authentification unique n'en contient pas.
  • Informations d'identification d'utilisateur refusées (message d'authentification unique)
    Identifie l'URL vers laquelle
    CA Single Sign-on
    redirige l'utilisateur en cas de conditions d'erreur. Les conditions d'erreur qui sont des exceptions renvoyées lorsqu'un utilisateur est introuvable ou que le message d'authentification unique n'est pas valide. L'assertion est valide, mais
    CA Single Sign-on
    n'accepte pas le message par exemple dans les cas suivants :
    • Echec de la validation de signature numérique XML
    • (SAML 2.0) Echec du déchiffrement XML
    • Echec de la validation XML de conditions, par exemple expiration d'un message ou non correspondance d'audience
    • Aucune instruction d'authentification contenue dans les assertions du message d'authentification unique
  • 302 Aucune donnée (valeur par défaut)
    Permet de rediriger l'utilisateur à l'aide d'une redirection HTTP 302 contenant un cookie de session, mais aucune autre donnée.
  • HTTP POST
    Permet de rediriger l'utilisateur à l'aide d'un protocole HTTP POST.
URL de redirection SAML 2.0 supplémentaires
Dans le cas d'un fournisseur de services SAML 2.0, vous pouvez également spécifier des URL de redirection pour des erreurs HTTP 500, 400 et 405. Sélectionnez les options de redirection que vous voulez activer, puis saisissez une URL associée. Les options sont :
  • Activer la redirection d'erreur de serveur
    Activer l'URL d'erreur de serveur :
    spécifie l'URL vers laquelle l'utilisateur est redirigé en cas d'erreur du serveur HTTP 500. L'erreur 500 peut se produire lorsqu'une condition inattendue empêche le serveur Web de répondre à la demande cliente. Si c'est le cas, l'utilisateur sera envoyé vers l'URL spécifiée pour un traitement approfondi.
    Exemple : http://www.redirectmachine.com/error_pages/server_error.html
  • Activer la redirection de demande non valide
    Activer l'URL de demande non valide :
    spécifie l'URL vers laquelle l'utilisateur est redirigé lorsqu'une erreur HTTP 400 Demande incorrecte ou 405 Méthode non autorisée se produit. Un utilisateur peut obtenir une erreur 400 si une demande est mal formulée ou une erreur 405 si le serveur Web ne prend pas en charge une méthode ou une action. Si ce type d'erreur se produit, l'utilisateur est renvoyé vers l'URL spécifiée pour un traitement approfondi.
    Exemple : http://www.redirectmachine.com/error_pages/invalidreq_error.html
  • Activer la redirection d'accès non autorisé
    Activer l'URL d'accès non autorisé :
    spécifie l'URL vers laquelle l'utilisateur est redirigé en cas d'erreur HTTP 403 Demande interdite. L'erreur 403 peut se produire lorsque l'URL dans une demande pointe vers une cible incorrecte, par exemple un répertoire au lieu d'un fichier. Si c'est le cas, l'utilisateur sera envoyé vers l'URL spécifiée pour un traitement approfondi.
    Exemple : http://www.redirectmachine.com/error_pages/unauthorized_error.html
URL de redirection selon le statut (OAuth)
La section URL de redirection selon le statut permet de déterminer le mode de redirection par
CA Single Sign-on
d'un utilisateur en cas d'échec d'authentification.
L'authentification basée sur une assertion peut échouer à l'emplacement consommant des assertions. Si c'est le cas, Federation Standalone fournit une fonctionnalité permettant de diriger l'utilisateur vers différentes applications (URL) pour un traitement plus approfondi. Par exemple, en cas d'échec de la résolution d'ambigüité d'utilisateur, vous pouvez configurer
CA Single Sign-on
de sorte à envoyer l'utilisateur vers un système de provisionnement. Ce système de provisionnement peut créer un compte d'utilisateur basé sur les informations présentes dans l'assertion SAML.
Vous pouvez configurer une ou plusieurs de ces options. Si la condition ayant entraîné l'échec se reproduit,
CA Single Sign-on
redirige l'utilisateur vers l'URL configurée.
Elle comprend les paramètres suivants :
  • Panne de serveur distant
    • OAuth 2.0
      Identifie l'URL vers laquelle le système redirige l'utilisateur lorsque les erreurs suivantes se produisent au niveau d'OAuth 2.0 :
      • Une condition inattendue s'est produite au niveau du serveur d'autorisation l'empêchant d'effectuer la demande d'utilisateur.
      • Le serveur d'autorisation ne parvient pas à traiter la demande d'utilisateur à cause d'une surcharge temporaire ou d'une tâche de maintenance du serveur.
    • OAuth 1.0a
      URL vers laquelle le système redirige l'utilisateur lorsque le serveur d'autorisation envoie une erreur HTTP 500.
  • Message de demande non valide
    • OAuth 2.0
      Identifie l'URL vers laquelle le système redirige l'utilisateur lorsque les erreurs suivantes se produisent au niveau d'OAuth 2.0 :
      • La syntaxe de la demande d'utilisateur est incorrecte.
      • L'étendue demandée par l'utilisateur est non valide, inconnue ou anormale.
      • Le serveur d'autorisation ne prend pas en charge l'obtention du code d'autorisation avec la méthode spécifiée.
    • OAuth 1.0a
      URL vers laquelle le système redirige l'utilisateur lorsque le serveur d'autorisation envoie une erreur HTTP 400 ou 404.
  • Informations d'identification d'utilisateur refusées
    • OAuth 2.0
      Identifie l'URL vers laquelle CA
      CA Single Sign-on
      Federation Standalone dirige l'utilisateur lorsque les erreurs suivantes se produisent au niveau de OAuth 2.0 :
      • Le client n'est pas autorisé à demander un code d'autorisation à l'aide de la méthode spécifiée.
      • Le serveur d'autorisation a refusé la demande.
    • OAuth 1.0a
      URL vers laquelle le système redirige l'utilisateur lorsque le serveur d'autorisation envoie une erreur HTTP 401 ou 403.
  • 302 Aucune donnée (valeur par défaut)
    Permet de rediriger l'utilisateur à l'aide d'une redirection HTTP 302 contenant un cookie de session, mais aucune autre donnée.
  • HTTP POST
    Permet de rediriger l'utilisateur à l'aide d'un protocole HTTP POST.