Connexion unique pour les demandes HTTP à l'aide de l'authentification Web SPNEGO

Vous pouvez négocier et authentifier les demandes HTTP de manière sécurisée pour les ressources protégées dans WebSphere Application Server à l'aide du mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) comme service d'authentification Web pour WebSphere Application Server.

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

Qu'est-ce que SPNEGO ?

SPNEGO est une spécification de norme qui est définie dans Mécanisme SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) (IETF RFC 2478).

Lorsque la sécurité serveur Liberty est activée, ainsi que l'authentification Web SPNEGO, ce dernier est initialisé lors du traitement d'une première demande HTTP entrante. Si aucun filtre d'authentification n'est spécifié, ou si les critères ne sont pas remplis, SPNEGO est chargé d'authentifier l'accès à la ressource protégée qui est identifiée dans la demande 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 :
  • Pour plateformes WindowsServeurs Microsoft Windows avec le domaine Active Directory et le centre KDC (Key Distribution Center) Kerberos associé.
  • 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 et Mozilla Firefox sont des exemples de navigateur. Tout navigateur utilisé, quel qu'il soit, doit être configuré pour l'utilisation du mécanisme d'authentification Web SPNEGO.

L'authentification des demandes HTTP est déclenchée par l'utilisateur (côté client), ce qui génère un jeton SPNEGO. WebSphere Application Server reçoit ce jeton. Plus précisément, l'authentification Web SPNEGO décode et extrait l'identité de l'utilisateur du jeton SPNEGO. L'identité est ensuite utilisée pour les décisions d'autorisation.

L'authentification Web SPNEGO est une solution côté client 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é de l'utilisateur dans le registre de sécurité de 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é à partir d'Active Directory au registre de sécurité de WebSphere Application Server.

WebSphere Application Server valide l'identité selon son registre de sécurité. Si la validation aboutit, les données d'identification de délégation GSS du client sont extraites et placées dans le sujet client, puis un jeton de sécurité LTPA (Lightweight Third Party Authentication) est créé. Il renvoie ensuite le cookie LTPA à l'utilisateur dans la réponse HTTP. Les demandes HTTP suivantes de ce même utilisateur pour accéder à d'autres ressources protégées dans WebSphere Application Server utilisent le jeton de sécurité LTPA qui est préalablement créé afin d'éviter des demandes d'authentification de connexion répétées.

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 1. Authentification Web SPNEGO dans un domaine Kerberos unique

L'authentification Web SPNEGO est prise en charge dans un domaine Kerberos unique. Le processus d'échange de protocoles par question-réponse est illustré.

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

  1. Pour commencer, l'utilisateur se connecte au contrôleur de domaine Microsoft MYDOMAIN.EXAMPLE.COM depuis le poste de travail.
  2. Ensuite, l'utilisateur essaie d'accéder à l'application Web. L'utilisateur demande une ressource Web protégée à l'aide d'un navigateur client, lequel envoie une demande HTTP GET au serveur Liberty.
  3. L'authentification SPNEGO sur le serveur Liberty répond au navigateur client avec un en-tête de demande d'authentification HTTP 401 contenant l'état Authenticate: Negotiate.
  4. Le navigateur client reconnaît l'en-tête de négociation car il est configuré pour prendre en charge l'authentification Windows intégrée. Le client analyse l'URL demandée pour trouver le nom d'hôte. Il utilise ce nom d'hôte pour former le nom de principal de service (SPN) Kerberos cible HTTP/myLibertyMachine.example.com afin de demander un ticket de service Kerberos auprès du service d'octroi d'autorisations Kerberos (TGS) dans Microsoft Kerberos KDC (TGS_REQ). Le service TGS émet ensuite un ticket de service Kerberos (TGS_REP) pour le client. Le ticket de service Kerberos (jeton SPNEGO) prouve à la fois l'identité de l'utilisateur et les droits sur le service (serveur Liberty).
  5. Le navigateur client répond ensuite au serveur Liberty la demande d'authentification Authenticate: Negotiate avec le jeton SPNEGO obtenu à l'étape précédente dans l'en-tête HTTP de la demande.
  6. L'authentification SPNEGO sur le serveur Liberty voit l'en-tête HTTP avec le jeton SPNEGO, valide le jeton SPNEGO, puis obtient l'identité (ke principal) de l'utilisateur.
  7. Une fois que le serveur Liberty a obtenu l'identité de l'utilisateur, il valide l'utilisateur dans son registre d'utilisateurs et effectue les vérifications d'autorisations.
  8. Si l'accès est accordé, le serveur Liberty envoie la réponse avec un code HTTP 200. Le serveur Liberty inclut également un cookie LTPA dans la réponse. Ce cookie LTPA est utilisé pour les demandes suivantes.
Remarque : Les autres clients (par exemple, services Web, .NET et J2EE) qui prennent en charge SPNEGO n'ont pas à suivre le processus d'établissement de liaison demande-réponse illustré ci-dessus. Ces clients peuvent obtenir un ticket d'octroi d'autorisations (TGT) 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 demande HTTP.

Authentification Web SPNEGO dans des domaines Kerberos de confiance

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

Figure 2. Authentification Web SPNEGO dans un domaine Kerberos de confiance

L'authentification Web SPNEGO est aussi prise en charge dans un domaine Kerberos sécurisé. Le processus d'échange de protocoles par question-réponse est illustré.

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

  1. L'utilisateur se connecte au contrôleur de domaine Microsoft TRUSTEDREALM.ACME.COM.
  2. Depuis un navigateur client, l'utilisateur demande une ressource Web protégée qui est hébergée sur un serveur Liberty du contrôleur de domaine Microsoft d'origine, MYDOMAIN.EXAMPLE.COM.
  3. Le serveur Liberty répond au navigateur client avec un en-tête de demande d'authentification HTTP 401 contenant l'état Authenticate: Negotiate.
  4. Le navigateur client est configuré pour prendre en charge l'authentification Windows intégrée. Le navigateur client analyse l'URL à l'aide du nom d'hôte du poste de travail qui héberge l'application du serveur Liberty. Le navigateur client utilise le nom d'hôte en tant qu'attribut pour demander ticket interdomaine Kerberos (TGS_REQ) pour MYDOMAIN.EXAMPLE.COM depuis le domaine TRUSTEDREALM.ACME.COM.
  5. Le navigateur client utilise ce permis interdomaine à partir de l'étape 4 pour demander un ticket de service Kerberos du domaine MYDOMAIN.EXAMPLE.COM. Le ticket de service Kerberos (jeton SPNEGO) prouve l'identité de l'utilisateur et les droits sur le service (serveur Liberty).
  6. Le navigateur client répond ensuite au serveur Liberty la demande d'authentification Authenticate: Negotiate avec le jeton SPNEGO obtenu à l'étape précédente dans l'en-tête HTTP de la demande.
  7. Le serveur Liberty reçoit la demande et vérifie l'en-tête HTTP avec le jeton SPNEGO. Il extrait ensuite le ticket de service Kerberos, valide ce ticket, puis obtient l'identité (le principal) de l'utilisateur.
  8. Une fois que le serveur Liberty a obtenu l'identité de l'utilisateur, il valide l'utilisateur dans son registre d'utilisateurs et effectue les vérifications d'autorisations.
  9. Si l'accès est accordé, le serveur Liberty envoie la réponse avec un code HTTP 200. Le serveur Liberty inclut également un cookie LTPA dans la réponse. Ce cookie LTPA est utilisé pour les demandes suivantes.
Remarque : Aucune modification du serveur Liberty n'est nécessaire pour la prise en charge d'autres domaines de confiance. Une relation de confiance entre les domaines Active Directory nécessaires est la seule exigence pour que SPNEGO fonctionne avec les domaines de confiances.

Dans l'environnement des domaines Kerberos de confiance, gardez à l'esprit que la configuration du domaine sécurisé Kerberos doit être effectuée sur chaque centre de distribution de clés Kerberos. Consultez votre administrateur Kerberos et le guide de l'utilisateur pour plus d'informations sur l'installation de domaines sécurisés Kerberos.

Informations sur le support 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

Pour plus d'informations sur la configuration de SPNEGO sur le serveur Liberty, voir Configuration de l'authentification SPNEGO dans Liberty.


Icône indiquant le type de rubrique Rubrique de concept



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