Connexion unique pour les demandes HTTP à l'aide de l'authentification Web SPNEGO
Vous pouvez négocier et authentifier en toute sécurité les requêtes HTTP portant sur des ressources sécurisées dans WebSphere Application Server en utilisant SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) comme service d'authentification Web de WebSphere Application Server.
- Vous pouvez configurer et activer l'authentification Web SPNEGO et les filtres sur WebSphere Application Server à l'aide de la console d'administration.
- SPNEGO peut être rechargé dynamiquement, de sorte qu'il n'est pas 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 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 ?
- Les avantages de l'authentification Web SPNEGO
- Authentification Web SPNEGO dans un domaine Kerberos unique
- Authentification Web SPNEGO dans un domaine Kerberos de confiance
- Informations sur la prise en charge de l'authentification Web SPNEGO avec un client Java utilisant le protocole HTTP
- Informations sur la prise en charge de l'authentification Web SPNEGO avec un client de navigation
- Définition de SPNEGO comme mécanisme d'authentification pour WebSphere Application Server
Qu'est-ce que SPNEGO ?
SPNEGO est une spécification standard définie dans le document The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478).
Lorsque la sécurité globale et d'application de WebSphere Application Server est activée, ainsi que l'authentification Web SPNEGO, SPNEGO est initialisé lors du traitement de la 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.
Serveurs Microsoft Windows avec le domaine Active Directory et le centre KDC (Key Distribution Center) Kerberos associé. Pour plus d'informations sur les serveurs Microsoft Windows compatibles, voir la rubrique Configuration système requise pour WebSphere Application Server Version 9.0 sur Windows.
- Une application client, telle que Microsoft .NET ou un service Web et un client J2EE prenant en charge le mécanisme d'authentification Web SPNEGO, tel que défini dans le document IETF RFC 2478. Microsoft Internet Explorer version 5.5 ou suivante et Mozilla Firefox version 1.0 sont des exemples de navigateurs. Tout navigateur doit être configuré pour utiliser le mécanisme d'authentification Web SPNEGO. Pour plus d'informations sur le processus de configuration, voir Configuration du navigateur client pour l'utilisation de 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 coté 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é de WebSphere Application Server doit être identique à l'identité extraite par l'authentificateur 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é à partir d'Active Directory vers le registre de sécurité de WebSphere Application Server.
Pour plus d'informations sur l'utilisation
de ce module de connexion personnalisé, voir
Mappage d'un nom de principal Kerberos client à l'ID du registre d'utilisateurs WebSphere.
WebSphere Application Server valide l'identité selon 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 ultérieures émises par le même demandeur concernant l'accès à des ressources sécurisées supplémentaires dans WebSphere Application Server utilisent le jeton de sécurité LTPA précédemment créé pour éviter des demandes de connexion répétées.
L'administrateur Web a accès aux composants de sécurité SPNEGO suivants et aux données de configuration associées, comme indiqué dans la figure suivante :

Les avantages de l'authentification Web SPNEGO
L'utilisation de SPNEGO comme service d'authentification Web pour WebSphere Application Server présente les avantages suivants :
Etablissement d'un environnement de connexion unique intégré aux serveurs Microsoft Windows utilisant le domaine Active Directory.
- 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.
- Interopérabilité avec les services Web et les applications Microsoft .NET ou les applications de service Web qui utilisent l'authentification SPNEGO au niveau du transport.
- 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 :

Dans la figure précédente, voici les événements qui se produisent :
- Le client envoie une requête HTTP/Post/Get/Web-Service à WebSphere Application Server.
- WebSphere Application Server retourne HTTP 401 Authentifier/Négocier.
- Le client obtient un ticket TGT (Ticket Granting Ticket).
- Le client demande un ticket de service (TGS_REQ).
- Le client obtient un ticket de service (TGS_REP).
- Le client envoie HTTP/Post/Get/Web-Service et un jeton d'autorisation SPNEGO WebSphere Application Server.
- 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. Créez un jeton KRBAuthnToken avec des droits d'accès de client Kerberos.
- WebSphere Application Server valide l'ID utilisateur avec le registre d'utilisateurs WebSphere et crée un jeton LTPA.
- WebSphere Application Server retourne HTTP 200, le contenu et le jeton LTPA au client.
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 :

Dans la figure précédente, voici les événements qui se produisent :
- Le client envoie une requête HTTP/Post/Get/Web-Service à WebSphere Application Server.
- WebSphere Application Server retourne HTTP 401 Authentifier/Négocier.
- Le client obtient un ticket TGT (Ticket Granting Ticket).
- Le client demande un ticket interdomaine (TGS_REQ) pour REALM2 à partir du centre KDC REALM1.
- Le client utilise le ticket interdomaine à partir de l'étape 4 pour demander un ticket service à partir du centre KDC REALM2.
- Le client envoie HTTP/Post/Get/Web-Service et un jeton d'autorisation SPNEGO WebSphere Application Server.
- 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. Créez un jeton KRBAuthnToken avec des droits d'accès de client Kerberos.
- WebSphere Application Server valide l'ID utilisateur avec le registre d'utilisateurs WebSphere et crée un jeton LTPA.
- WebSphere Application Server retourne 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 principal du client Kerberos provenant du jeton SPNEGO risque de ne pas
se trouver dans le registre d'utilisateurs WebSphere ; il peut être requis pour le mappage principal Kerberos du registre d'utilisateurs WebSphere.
Pour plus d'informations, voir
Mappage d'un nom de principal Kerberos client à l'ID du registre d'utilisateurs WebSphere.
Informations sur la prise en charge de l'authentification Web SPNEGO avec un client Java™ utilisant le protocole HTTP
- 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
- 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
- Sécurités inter-forêts
- Sécurité de domaine dans la même forêt
- Sécurité de domaine Kerberos
- Sécurités externes de forêt
- Sécurités externes de domaine