Création d'une connexion unique pour les requêtes HTTP à l'aide de l'intercepteur TAI SPNEGO (déprécié)

La création de connexions uniques pour les demandes HTTP utilisant l'intercepteur TAI (trust association interceptor) SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) pour WebSphere Application Server requiert l'exécution de fonctions distinctes mais liées. Lorsque ces fonctions sont exécutées, les utilisateurs HTTP peuvent se connecter et s'authentifier une seule fois depuis leur bureau et recevoir une authentification automatique de WebSphere Application Server.

Avant de commencer

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 obsolète. Elle a été remplacée par l'authentification Web SPNEGO, qui fournit un rechargement dynamique des filtres SPNEGO et autorise un repli sur la méthode d'ouverture de session de l'application.

depfeat

Avant de démarrer cette tâche, vérifiez les points suivants :

  • [Windows]Un serveur Microsoft Windows Server exécutant le contrôleur de domaine Active Directory et le centre KDC (Kerberos Key Distribution Center) associé.
  • [Windows]Un membre du domaine Microsoft Windows (client), par exemple, un navigateur ou un client Microsoft .NET, qui prend en charge le mécanisme d'authentification SPNEGO, tel qu'il est défini dans IETF RFC 2478. Microsoft Internet Explorer Version 5.5 ou suivante et Mozilla Firefox Version 1.0 sont de tels clients.
    Important : Un contrôleur de domaine en cours d'exécution et au moins une machine client dans ce domaine sont requis. La tentative d'utilisation de SPNEGO directement à partir du contrôleur de domaine n'est pas prise en charge
  • Le membre de domaine comporte des utilisateurs qui peuvent se connecter au domaine. Vous avez spécifiquement besoin du domaine Active Directory de Microsoft Windows qui inclut :
    • un contrôleur de domaine,
    • un poste de travail client,
    • des utilisateurs qui peuvent se connecter au poste de travail client.
  • Une plateforme de serveur avec WebSphere Application Server en cours d'exécution avec la sécurité d'application activée.
  • Les utilisateurs figurant dans Active Directory doivent pouvoir accéder aux ressources protégées de WebSphere Application Server en utilisant le mécanisme d'authentification natif de WebSphere Application Server.
  • L'heure locale pour le contrôleur de domaine et l'hôte de WebSphere Application Server doivent concorder.
  • Vérifiez que l'écart horaire sur les clients, Microsoft Active Directory et WebSphere Application Server ne dépasse pas 5 minutes.
  • N'oubliez pas les navigateurs clients doivent être activés SPNEGO, action effectuée sur la machine d'application client (détails à l'étape 2 de cette tâche).

Pourquoi et quand exécuter cette tâche

Cette configuration de la machine a pour objectif de permettre aux utilisateurs d'accéder aux ressources de WebSphere Application Server sans avoir à effectuer une nouvelle authentification et d'être par conséquent en mesure de profiter des capacités de connexion unique du bureau Microsoft Windows.

La configuration des membres de cet environnement en vue d'établir une connexion unique Microsoft Windows implique des activités spécifiques qui sont effectuées sur trois machines distinctes :
  • Un serveur Microsoft Windows Server exécutant le contrôleur de domaine Active Directory et le centre KDC (Kerberos Key Distribution Center) associé
  • Un membre du domaine (application client) Microsoft Windows, tel qu'un navigateur ou un client .NET Microsoft.
  • Une plateforme de serveur avec WebSphere Application Server en cours d'exécution.

Suivez la procédure ci-après pour les machines indiquées afin de créer une connexion unique pour les demandes HTTP à l'aide de SPNEGO

Procédure

  1. Machine de contrôleur de domaine - Configurez le serveur Microsoft Windows Server exécutant le contrôleur de domaine Active Directory et le centre de Distribution de clé Kerberos (KDC) associé Cette activité de configuration inclut les étapes suivantes :
    Important : Vos opérations de contrôleur de domaine doivent générer le résultat suivant :
    • Un compte utilisateur est créé dans Microsoft Active Directory et mappé sur un nom de principal de service Kerberos.
    • Un fichier de clés Kerberos (krb5.keytab) est créé et rendu disponible pour WebSphere Application Server. Le fichier de clés Kerberos contient les clés du principal de service Kerberos utilisées par WebSphere Application Server pour authentifier l'utilisateur dans Microsoft Active Directory et le compte Kerberos.
  2. Machine d'application client - Configurez l'application cliente. Les applications côté client sont chargées de générer le jeton SPNEGO devant être utilisé par l'intercepteur TAI SPNEGO. Vous commencez le processus de configuration en configurant votre navigateur Web afin qu'il utilise l'authentification SPNEGO. Voir Configuration du navigateur client pour utiliser l'intercepteur TAI SPNEGO (déprécié) pour les détails concernant les étapes nécessaires pour votre navigateur
  3. WebSphere Application Server Machine - Configurez et activez le serveur d'applications et l'intercepteur TAI SPNEGO associé en suivant la procédure ci-après.
  4. Facultatif : Utilisation d'un serveur HTTP éloigné - Pour utiliser un serveur éloigné, vous devez suivre la procédure ci-après, qui suppose que vous avez déjà configuré les propriétés JVM et activé l'intercepteur TAI SPNEGO dans le serveur d'applications où il est défini (comme cela est décrit dans les étapes précédentes).
    1. Effectuez les étapes dans Création d'un principal de service et d'un fichier de clés Kerberos utilisé par l'intercepteur TAI SPNEGO WebSphere Application Server (obsolète) pour le serveur proxy distant.
    2. Fusionnez le fichier de clés précédent créé à l'étape 1 avec le fichier de clés créé à l'étape 4a. Pour plus d'informations, voir Utilisation de la commande ktab pour gérer le fichier de clés Kerberos.
    3. Créez le SPN pour le serveur proxy éloigné à l'aide de la tâche de commande addSpnegoTAIProperties wsadmin. Pour plus d'informations, voir Groupe de commandes SpnegoTAICommands de l'objet AdminTask (déprécié).
    4. Redémarrez WebSphere Application Server.

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



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=tsec_SPNEGO_tai
Nom du fichier : tsec_SPNEGO_tai.html