Fonction de connexion unique avec TAI SPNEGO : Liste de contrôle (déprécié)

WebSphere Application Server fournit un intercepteur de relations de confiance (TAI) qui utilise le mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) pour négocier et authentifier en toute sécurité les requêtes HTTP pour les ressources sécurisées dans WebSphere Application Server. Pour déployer et utiliser l'intercepteur SPNEGO TAI, vous devez examiner votre installation et décider de la meilleure méthode à suivre pour configurer SPNEGO TAI.

Fonction obsolète Fonction obsolète:

WebSphere Application Server version 6.1 fournit un intercepteur de relations de confiance (TAI) qui utilise le mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) pour négocier et authentifier en toute sécurité les demandes HTTP portant sur des ressources sécurisées. Dans WebSphere Application Server 7.0, cette fonction est maintenant obsolète. L'authentification Web SPNEGO fournit un rechargement dynamique des filtres SPNEGO et active la rétromigration sur la méthode de connexion d'application.

depfeat
LTPA (Lightweight Third Party Authentication) est le mécanisme d'authentification par défaut pour WebSphere Application Server. Cependant, il se peut que vous deviez configurer LTPA avant de configurer les propriétés TAI SPNEGO. LTPA est le mécanisme d'authentification requis pour tous les aux intercepteurs de relations de confiance. Vous pouvez configurer LTPA en cliquant sur Sécurité > Sécurité globale > Mécanismes d'authentification et expiration.
Remarque : L'activation de la connexion unique pour la sécurité Web est facultative lorsque vous configurez les propriétés TAI SPNEGO. Pour plus d'informations, voir Implémentation d'une connexion unique pour réduire les authentifications d'utilisateur Web.
Répondez aux questions suivantes pour déterminer la façon dont l'intercepteur TAI SPNEGO est déployé.
  1. Quels sont vos critères d'interception des demandes HTTP ?

    Vous devez décider si le déploiement SPNEGO TAI utilisera la classe HTTPHeaderFilter par défaut. Si oui, vous devez spécifier les propriétés de filtre exactes pour cette classe. Par défaut, l'intercepteur SPNEGO TAI utilise la classe com.ibm.ws.spnego.HTTPHeaderFilter pour intercepter toutes les demandes.

    Si vous n'utilisez pas l'exemple de classe com.ibm.ws.spnego.HTTPHeaderFilter, vous devez définir une nouvelle classe qui implémente l'interface com.ibm.wsspi.security.spnego.SpnegoTAIFilter.

    L'interface SPI (Service Provider Programming) permet de contrôler davantage quelles demandes HTTP intercepter ; voir Filtrage des requêtes HTTP pour TAI SPNEGO (déprécié)

    Voir Configuration des propriétés personnalisées TAI SPNEGO (déprécié) pour une description de
    • com.ibm.ws.security.spnego.SPN<id>.filterClass
    • com.ibm.ws.security.spnego.SPN<id>.filter
  2. Le mappage d'ID utilisateur sera t-il utilisé ? Si ce n'est pas le cas, pourquoi ?

    WebSphere Application Server permet de définir ou de développer un module de connexion personnalisé pour mapper les ID utilisateur. Pour plus d'informations sur la réalisation de ce mappage, voir Mappage du nom de principal client Kerberos sur l'ID de registre d'utilisateurs WebSphere pour l'intercepteur TAI SPNEGO (déprécié).

    Avant de déployer l'intercepteur TAI, vous devez décider si le module de connexion personnalisé doit être utilisé pour effectuer le mappage d'identités TAI SPNEGO.

  3. Quel type de chiffrement sera utilisé pour traiter les jetons SPNEGO ?
    Microsoft Windows Active Directory prend en charge deux types de chiffrement Kerberos : RC4-HMAC et DES-CBC-MD5. La bibliothèque IBM® Java™ Generic Security Service (JGSS) (et la bibliothèque SPNEGO) prend en charge ces types de chiffrements.
    Restriction : Le chiffrement RC4-HMAC est pris en charge uniquement lorsque Windows 2003 Server est utilisé comme centre de distribution de clés.
  4. Comment les délégations d'accréditation seront-elles gérées ?

    Kerberos prend en charge la délégation d'accréditation. Un serveur recevant des justificatifs Kerberos d'un client peut simuler les droits d'accès de ce client vis à vis d'autres serveurs en utilisant les données d'identification déléguées. Les jetons SPNEGO TAI consistant en un encapsulage de justificatif Kerberos, le serveur qui reçoit des justificatifs Kerberos dans un jeton SPNEGO peut les utiliser pour simuler les droits de l'utilisateur d'origine. Ce serveur peut, à l'aide de SPNEGO sur HTTP, interagir comme client SPNEGO avec d'autres serveurs SPNEGO en composant un en-tête d'autorisation HTTP approprié.

  5. L'intercepteur SPNEGO TAI sera t-il déployé dans un environnement de domaine DNS simple ou multiple ?

    Les navigateurs Web exécutés sous Windows sont sensibles aux domaines DNS. Ils envoient un jeton SPNEGO uniquement lorsque le nom d'hôte cible identifie un nom d'hôte défini dans le domaine DNS du poste client. Vous pouvez utiliser le réacheminement HTTP pour prendre en charge cette configuration avec la création d'un pseudo SPN (nom principal de service) Kerberos dans chaque domaine DNS. Les clés de tous les SPN pris en charge par WebSphere Application Server doivent être disponibles dans les fichiers de clés Kerberos. Pour activer la connexion unique pour plusieurs domaines DNS, un fichier de clés Kerberos distinct est généré pour chaque SPN de domaine. Ces fichiers doivent être fusionnés pour pouvoir être utilisés par WebSphere Application Server.

  6. Quelle sera la fréquence de rechargement des propriétés SPNEGO TAI par les serveurs d'applications ?

    L'intercepteur TAI SPNEGO présente une fonction de rechargement de propriété facultative qui permet de recharger les propriétés TAI sans redémarrer la machine virtuelle Java (JVM). Cette fonction de rechargement est contrôlée par les propriétés système com.ibm.ws.security.spnego.propertyReloadFile et com.ibm.ws.security.spnego.propertyReloadTimeout. Ensemble, ces propriétés permettent aux propriétés internes SPNEGO TAI d'être rechargées à partir d'un fichier sur le système de fichiers au-delà d'une période donnée. Si un nombre entier correct est affecté à l'attribut com.ibm.ws.security.spnego.propertyReloadTimeout alors que l'attribut com.ibm.ws.security.spnego.propertyReloadFile pointe vers un fichier du système de fichiers, chaque machine JVM recharge les propriétés SPNEGO TAI à partir du fichier une fois le délai expiré. De plus, les propriétés SPNEGO TAI sont uniquement rechargées si la date du fichier a changé. Si ces propriétés de rechargement ne sont pas définies, les propriétés TAI SPNEGO sont chargées une seule fois (lors de l'initialisation de la machine virtuelle Java) à partir des propriétés personnalisées TAI SPNEGO définies dans les données de configuration de WebSphere Application Server. Pour plus d'informations sur ces propriétés de rechargement, voir Propriétés de configuration JVM TAI SPNEGO personnalisées (déprécié)s.

L'administrateur (Web) Windows Active Directory, l'administrateur WebSphere Application Server et l'équipe de développement d'applications étudient ces questions et y répondent pour déterminer les paramètres de déploiement et de configuration les plus adaptés pour l'interception TAI SPNEGO.


Icône indiquant le type de rubrique Rubrique de référence



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