Connexion unique SPNEGO

Vous pouvez négocier et authentifier en toute sécurité les demandes HTTP pour les ressources sécurisées dans WebSphere® Application Server en utilisant le mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) comme service d'authentification Web pour WebSphere Application Server.

Remarque: dans WebSphere Application Server version 6.1, 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 des ressources sécurisées a été ajouté. Cette fonction est obsolète dans WebSphere Application Server Version 7.0. L'authentification Web SPNEGO fournit les améliorations suivantes :
  • Vous pouvez configurer et activer l'authentification Web SPNEGO et les filtres sur WebSphere Application Server à l'aide de la console d'administration.
  • Le rechargement dynamique de SPNEGO est fourni sans qu'il soit nécessaire d'arrêter et de redémarrer WebSphere Application Server.
  • La rétromigration d'une méthode de connexion d'application est fournie si l'authentification Web SPNEGO échoue.
  • SPNEGO peut être personnalisé au niveau du domaine de sécurité WebSphere . Pour plus d'informations, voir Domaines de sécurité multiples .

Vous pouvez activer soit un de relations de confiance SPNEGO soit l'authentification Web SPNEGO, mais pas les deux.

Les sections suivantes décrivent l'authentification Web SPNEGO plus en détail :

Qu'est-ce que SPNEGO ?

SPNEGO est une spécification standard définie dans The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478).

Lorsque la sécurité globale et d'application WebSphere Application Server est activée et que l'authentification Web SPNEGO est activée, SPNEGO est initialisé lors du traitement d'une première demande HTTP entrante. Le composant authentificateur Web interagit ensuite avec SPNEGO, défini et activé dans le répertoire de configuration de la sécurité. Lorsque les critères de filtre sont remplis, SPNEGO est chargé d'authentifier l'accès à la ressource sécurisée identifiée dans la requête HTTP.

Outre les services d'exécution de sécurité de WebSphere Application Server , certains composants externes sont requis pour activer le fonctionnement de SPNEGO. Ces composants externes comprennent :
  • [Windows]Microsoft Windows avec le domaine Active Directory et le centre de distribution de clés (KDC) Kerberos associé. Pour plus d'informations sur les serveurs Microsoft Windows pris en charge, voir la configuration système requise pour WebSphere Application Server version 9.0 sous Windows.
  • Une application client, par exemple Microsoft .NET, ou un service Web et un client J2EE qui prend en charge le mécanisme d'authentification Web SPNEGO, comme défini dans la norme IETF RFC 2478. Mozilla Firefox est un exemple de navigateur. Tout navigateur doit être configuré pour utiliser le mécanisme d'authentification Web SPNEGO.

L'authentification des demandes HTTP est déclenchée par le demandeur (côté client) qui génère un jeton SPNEGO. WebSphere Application Server reçoit ce jeton. L'authentificateur Web SPNEGO décode et extrait l'identité du demandeur à partir du jeton SPNEGO. L'identité est utilisée pour établir un contexte sécurisé entre le demandeur et le serveur d'applications.

L'authentification Web SPNEGO est une solution côté serveur dans WebSphere Application Server. Les applications côté client sont responsables de la génération du jeton SPNEGO à utiliser par l'authentification Web SPNEGO. L'identité du demandeur dans le registre de sécurité WebSphere Application Server doit être identique à l'identité extraite par l'authentification Web SPNEGO. Une correspondance identique se produit lorsque le serveur Microsoft Windows Active Directory est le serveur LDAP (Lightweight Directory Access Protocol) utilisé dans WebSphere Application Server. Un module de connexion personnalisé est disponible en tant que plug-in pour prendre en charge le mappage personnalisé de l'identité depuis Active Directory vers le registre de sécurité WebSphere Application Server .

[AIX Solaris HP-UX Linux Windows][IBM i]En savoir plus sur [AIX Solaris HP-UX Linux Windows][IBM i]Mappage d'un nom de principal Kerberos client à l' WebSphere pour plus d'informations sur l'utilisation de ce module de connexion personnalisé.

WebSphere Application Server valide l'identité par rapport à son registre de sécurité. Si la validation est réussie, le ticket Kerberos client et les droits d'accès de délégation GSS client sont extraits et placés dans le sujet client, qui produit ensuite un jeton de sécurité LTPA (Lightweight Third Party Authentication). Il place et retourne ensuite un cookie au demandeur dans la réponse HTTP. Les demandes HTTP suivantes de ce même demandeur pour accéder à des ressources sécurisées supplémentaires dans WebSphere Application Server utilisent le jeton de sécurité LTPA précédemment créé pour éviter les demandes de connexion répétées.

Dans la figure ci-dessous, l'administrateur Web a accès aux composants de sécurité SPNEGO et aux données de configuration associées suivants : module d'authentification Web, intercepteur de relations de confiance SPNEGO, fournisseurs de sécurité JGSS et SPNEGO, fichiers de configuration et de clés Kerberos, propriétés de configuration de l'intercepteur de relations de confiance SPNEGO et propriétés système de la machine virtuelle Java.

Figure 1 : Authentification Web SPNEGO et éléments de configuration de sécurité
Diagramme illustrant la relation entre SPNEGO et les éléments de configuration de la sécurité

Les avantages de l'authentification Web SPNEGO

Les avantages de l'utilisation de WebSphere Application Server par SPNEGO comme service d'authentification Web pour WebSphere Application Server sont les suivants:

  • [Windows]Un environnement de connexion unique intégré avec des serveurs Microsoft Windows utilisant le domaine Active Directory est établi.
  • Réduction des coûts liés à l'administration d'un grand nombre d'ID et de mots de passe.
  • Etablissement d'une transmission sécurisée et mutuellement authentifiée des justificatifs de sécurité à partir du navigateur Web ou des clients Microsoft .NET.
  • L'interopérabilité avec les services Web et Microsoft .NET, ou les applications de service Web qui utilisent l'authentification SPNEGO au niveau du transport, est assurée.
  • Avec le support d'authentification Kerberos, l'authentification Web SPNEGO peut fournir une solution de bout en bout à Kerberos et préserver le droit d'accès Kerberos du client.

Authentification Web SPNEGO dans un domaine Kerberos unique

L'authentification Web SPNEGO est prise en charge dans un domaine Kerberos unique. Le processus d'établissement de liaison demande-réponse est illustré dans la figure suivante :

Figure 2. Authentification Web SPNEGO dans un domaine Kerberos unique
L'authentification Web SPNEGO est prise en charge dans un domaine Kerberos unique. Le processus d'établissement de liaison entre la demande d'authentification et la réponse est affiché.

Dans la figure précédente, voici les événements qui se produisent :

  1. Le client envoie une demande HTTP/Post/Get/Web-Service à WebSphere Application Server.
  2. WebSphere Application Server renvoie HTTP 401 Authentifier / Négocier.
  3. Le client obtient un ticket TGT (Ticket Granting Ticket).
  4. Le client demande un ticket de service (TGS_REQ).
  5. Le client obtient un ticket de service (TGS_REP).
  6. Le client envoie HTTP/Post/Get/Web-Service et un jeton SPNEGO d'autorisation à WebSphere Application Server.
  7. WebSphere Application Server valide le jeton SPNEGO. Si la validation réussit, l'ID utilisateur et les droits d'accès de délégation GSS client sont extraits du jeton SPNEGO. Un KRBAuthnToken avec des données d'identification Kerberos client est créé.
  8. WebSphere Application Server valide l'ID utilisateur avec le registre d'utilisateurs WebSphere et crée un jeton LTPA.
  9. WebSphere Application Server renvoie HTTP 200, le contenu et le jeton LTPA au client.
Remarque: Les autres clients (par exemple, les services Web, .NET et J2EE) qui prennent en charge SPNEGO n'ont pas besoin de suivre le processus d'établissement de liaison entre la demande d'authentification et la réponse, comme indiqué précédemment. Ces clients peuvent obtenir un ticket TGT (ticket-granting ticket) et un ticket de service Kerberos pour le serveur cible, créer un jeton SPNEGO, l'insérer dans l'en-tête HTTP, puis suivre le processus normal de création d'une requête HTTP.

Authentification Web SPNEGO dans un domaine Kerberos de confiance

L'authentification Web SPNEGO est également prise en charge dans un domaine Kerberos de confiance. Le processus d'établissement de liaison demande-réponse est illustré dans la figure suivante :

Figure 3 Authentification Web SPNEGO dans un domaine Kerberos de confiance
L'authentification Web SPNEGO est également prise en charge dans un domaine Kerberos de confiance. Le processus d'établissement de liaison entre la demande d'authentification et la réponse est affiché.

Dans la figure précédente, voici les événements qui se produisent :

  1. Le client envoie une demande HTTP/Post/Get/Web-Service à WebSphere Application Server.
  2. WebSphere Application Server renvoie HTTP 401 Authentifier / Négocier
  3. Le client obtient un ticket TGT (Ticket Granting Ticket).
  4. Le client demande un ticket interdomaine (TGS_REQ) pour REALM2 depuis le centre KDC REALM1.
  5. Le client utilise le ticket interdomaine à partir de l'étape 4 pour demander un ticket service depuis le centre KDC REALM2.
  6. Le client envoie HTTP/Post/Get/Web-Service et un jeton SPNEGO d'autorisation à WebSphere Application Server.
  7. WebSphere Application Server valide le jeton SPNEGO. Si la validation réussit, l'ID utilisateur et les droits d'accès de délégation GSS client sont extraits du jeton SPNEGO. Un KRBAuthnToken avec des données d'identification Kerberos client est créé.
  8. WebSphere Application Server valide l'ID utilisateur avec le registre d'utilisateurs WebSphere et crée un jeton LTPA.
  9. WebSphere Application Server renvoie HTTP 200, le contenu et le jeton LTPA au client.

Dans l'environnement de domaines Kerberos sécurisé, prenez en considération les éléments suivants :

  • L'installation du domaine sécurisé Kerberos doit être effectuée sur chacun des centres KDC Kerberos. Consultez votre administrateur Kerberos et le guide de l'utilisateur pour plus d'informations sur l'installation de domaines sécurisés Kerberos.
  • Le nom de principal du client Kerberos provenant du jeton SPNEGO peut ne pas exister dans le registre d'utilisateurs WebSphere ; le mappage du principal Kerberos au registre d'utilisateurs WebSphere peut l'exiger.

    [AIX Solaris HP-UX Linux Windows][IBM i]Lecture Mappage d'un nom de principal Kerberos client à l' WebSphere pour plus d'informations.

Informations de prise en charge de l'authentification Web SPNEGO avec un client Java™ utilisant le protocole HTTP

Les scénarios suivants sont pris en charge :
  • Sécurité de domaine dans la même forêt
  • Sécurité de domaine externe directement entre des domaines au sein de forêts différentes.
  • Sécurité de domaine Kerberos
Les scénarios suivants sont pris en charge :
  • Sécurité inter forêts
  • Sécurité externe de forêt

Informations sur la prise en charge de l'authentification Web SPNEGO avec un client de navigation

Les scénarios suivants sont pris en charge :
  • Sécurisation inter-forêts
  • Sécurité de domaine dans la même forêt
  • Sécurité de domaine Kerberos
Les scénarios suivants sont pris en charge :
  • Sécurisations externes à la forêt
  • Sécurisations externes au domaine

Définition de SPNEGO comme mécanisme d'authentification pour WebSphere Application Server

Avant de configurer l'authentification Web SPNEGO dans la console d'administration ou à l'aide des commandes wsadmin , vous devez effectuer les étapes décrites dans la rubrique Création d'une connexion unique pour les demandes HTTP à l'aide de l'authentification Web SPNEGO afin de configurer l'authentification Web SPNEGO pour WebSphere Application Server.
Remarque: l'authentification Web SPNEGO côté serveur doit être effectuée par l'administrateur système. Le fichier de clés Kerberos doit être protégé.