Connexion unique SPNEGO

Vous pouvez négocier et authentifier en toute sécurité les requêtes HTTP pour les ressources sécurisées dans WebSphere® Application Server en utilisant le mécanisme de négociation GSS-API simple et protégé (SPNEGO) comme service d'authentification Web pour WebSphere Application Server.

Note: Dans WebSphere Application Server Version 6.1, un intercepteur d'association de confiance (TAI) qui utilise le mécanisme de négociation SPNEGO (Simple and Protected GSS-API) pour négocier et authentifier en toute sécurité les requêtes HTTP pour les ressources sécurisées a été introduit. Cette fonction était 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 et les filtres SPNEGO sur WebSphere Application Server en utilisant la console d'administration.
  • Le rechargement dynamique de SPNEGO est fourni sans avoir besoin 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 WebSphere niveau du domaine de sécurité. Lire à propos Plusieurs domaines de sécurité pour plus d'informations.

Vous pouvez activer soit un intercepteur TAI 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 Le mécanisme de négociation GSS-API simple et protégé (IETF RFC 2478).

Quand WebSphere Application Server la sécurité globale et celle des applications sont activées et l'authentification Web SPNEGO est activée, SPNEGO est initialisé lors du traitement d'une première requête 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.

En plus de WebSphere Application Server services d'exécution de sécurité, certains composants externes sont requis pour permettre le fonctionnement de SPNEGO. Ces composants externes comprennent :
  • [Windows]Microsoft Windows Serveurs avec Active Directory domaine et associé Kerberos Centre de distribution de clés (KDC). Pour plus d'informations sur les Microsoft Windows Serveurs, consultez la configuration système requise pour WebSphere Application Server Version 8.5 sous Windows.
  • Une application client, par exemple Microsoft .NET, ou un service Web et J2EE client qui prend en charge le mécanisme d'authentification Web SPNEGO, tel que défini dans IETF RFC 2478. Mozilla Firefox est un exemple de navigateur. Tout navigateur doit être configuré pour utiliser le mécanisme d'authentification Web SPNEGO. Pour plus d'informations sur l'exécution de cette configuration, voir Configuration du navigateur client pour utiliser 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 WebSphere Application Server le registre de sécurité doit être identique à l’identité récupérée par l’authentification Web SPNEGO. Une correspondance identique se produit lorsque Microsoft Windows Active Directory Le serveur est le serveur LDAP (Lightweight Directory Access Protocol) utilisé dans WebSphere Application Server. Un module de connexion personnalisé est disponible sous forme de plug-in pour prendre en charge le mappage personnalisé de l'identité à partir du Active Directory au WebSphere Application Server registre de sécurité.

[AIX Solaris HP-UX Linux Windows][IBM i]Lire à propos Cartographie d'un client Kerberos nom principal du WebSphere identifiant du registre d'utilisateurs 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. Requêtes HTTP ultérieures de ce même demandeur pour accéder à des ressources sécurisées supplémentaires dans WebSphere Application Server utilisez le jeton de sécurité LTPA créé précédemment pour éviter les défis de connexion répétés.

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é
Un diagramme qui montre la relation entre SPNEGO et les éléments de configuration de sécurité

Les avantages de l'authentification Web SPNEGO

Les avantages d'avoir WebSphere Application Server utilisez SPNEGO comme service d'authentification Web pour WebSphere Application Server inclure les éléments suivants:

  • [Windows]Un environnement d'authentification unique intégré avec Microsoft Windows Serveurs utilisant Active Directory le domaine 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 services Web qui utilisent l'authentification SPNEGO au niveau du transport est obtenue.
  • 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 de prise de contact défi-réponse est illustré.

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

  1. Le client envoie une requête HTTP/Post/Get/Web-Service à WebSphere Application Server.
  2. WebSphere Application Server Retour HTTP401 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 d'autorisation SPNEGO à 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. UNKRBAuthnToken avec un client Kerberos l'identifiant est créé.
  8. WebSphere Application Server valide l'ID utilisateur avec le WebSphere registre d'utilisateurs et crée un jeton LTPA.
  9. WebSphere Application Server Retour HTTP200, le contenu et le jeton LTPA au client.
Note: D'autres clients (par exemple, services Web, .NET et J2EE) qui prennent en charge SPNEGO n'ont pas à suivre le processus de prise de contact défi-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 de prise de contact défi-réponse est illustré.

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

  1. Le client envoie une requête HTTP/Post/Get/Web-Service à WebSphere Application Server.
  2. WebSphere Application Server Retour HTTP401 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 d'autorisation SPNEGO à 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. UNKRBAuthnToken avec un client Kerberos l'identifiant est créé.
  8. WebSphere Application Server valide l'ID utilisateur avec le WebSphere registre d'utilisateurs et crée un jeton LTPA.
  9. WebSphere Application Server Retour HTTP200, 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 Kerberos Le nom principal du client du jeton SPNEGO peut ne pas exister dans le WebSphere registre d'utilisateurs ; le Kerberos mappage principal avec le WebSphere le registre d'utilisateurs peut l'exiger.

    [AIX Solaris HP-UX Linux Windows][IBM i]Lire à propos Cartographie d'un client Kerberos nom principal du WebSphere identifiant du registre d'utilisateurs 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 en utilisantwsadmin commandes, vous devez effectuer les étapes répertoriées dans Création d'une authentification unique pour les requêtes HTTP à l'aide de l'authentification Web SPNEGO pour configurer l'authentification Web SPNEGO pour WebSphere Application Server.
Note: 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é.