Prise en charge du mécanisme d'authentification Kerberos (KRB5) pour la sécurité

Le mécanisme d'authentification Kerberos active l'interopérabilité avec d'autres applications (telles que .NET, DB2 et d'autres) qui prennent en charge l'authentification Kerberos. Il fournit des solutions interopérables de bout en bout à connexion unique (SSO) et conserve l'identité du demandeur initial.

Remarque : La prise en charge de la sécurité pour Kerberos en tant que mécanisme d'authentification a été ajoutée pour cette édition dev WebSphere Application Server Version 7.0. Kerberos est un protocole d'authentification réseau mûr, souple, ouvert et très sécurisé. Kerberos inclut l'authentification, l'authentification mutuelle, l'intégrité et la confidentialité des messages ainsi que des fonctions de délégation. Vous pouvez activer l'authentification par Kerberos du côté serveur. Cette prise en charge permet au client enrichi Java™ d'utiliser des jetons Kerberos pour l'authentification dans WebSphere Application Server.

Présentation de Kerberos

Kerberos a résisté à l'épreuve du temps et en est à la version 5.0. Il profite d'une prise en charge sur des plateformes largement diffusées (par exemple pour Windows, Linux, Solaris, AIX, et z/OS) en partie car son code source est en téléchargement libre à partir du Massachusetts Institute of Technology (MIT), son lieu de création.

Kerberos comprend trois parties : un client, un serveur et une partie tiers de confiance appelée centre de distribution de clés ou KDC (Kerberos Key Distribution Center). Le centre de distribution de clés fournit l'authentification et les services d'octroi d'autorisations.

Il gère une base de données ou un référentiel de comptes utilisateur pour tous les principaux de sécurité de son domaine. Un grand nombre de distributions Kerberos utilisent des référentiels de fichiers pour la base de données du principal et des règles Kerberos, les autres utilisent LDAP (Lightweight Directory Access Protocol) comme référentiel.

Kerberos ne prend pas en charge les notions de groupe (c'est-à-dire les groupes iKeys ou groupes d'utilisateurs ou de principaux). Le KDC gère une clé à long terme pour chaque principal de sa base de données de comptes. Cette clé à long terme est dérivée du mot de passe du principal. Seuls le KDC et l'utilisateur représenté par le principal devraient connaître la clé à long terme ou le mot de passe.

Avantages de Kerberos en tant que mécanisme d'authentification

Les avantages de Kerberos comme mécanisme d'authentification pour WebSphere Application Server sont les suivants :

  • Le protocole Kerberos est une norme. Ceci permet d'activer l'interopérabilité avec d'autres applications (telles que .NET, DB2 et d'autres) qui prennent en charge l'authentification Kerberos. Il fournit des solutions interopérables de bout en bout à connexion unique (SSO) et conserve l'identité du demandeur initial.
  • Lorsque le mécanisme d'authentification Kerberos est utilisé, le mot de passe en texte en clair ne quitte pas la machine de l'utilisateur. L'utilisateur s'authentifie et obtient un TGT (ticket-granting ticket) Kerberos émis par un centre de distribution de clés, en insérant une valeur de hachage unidirectionnel dans le mot de passe utilisateur. L'utilisateur obtient également un ticket de service Kerberos du centre de distribution de clés via le TGT. Le ticket de service Kerberos représentant l'identité du client est envoyé à ticket that represents the client identity is sent to WebSphere Application Server à des fins d'authentification.
  • Un client Java peut participer à la connexion unique Kerberos à l'aide du cache d'informations d'identification pour s'authentifier sur WebSphere Application Server.
  • Les clients J2EE, Service web, .NET et navigateur Web peuvent qui utilisent le protocole HTTP peuvent utiliser le jeton SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) pour s'authentifier sur WebSphere Application Server et participer à la connexion unique à l'aide de l'authentification Web SPNEGO. La prise en charge de SPNEGO comme service d'authentification Web est une nouveauté de cette édition de WebSphere Application Server.

    Pour plus d'informations, voir Connexion unique pour les demandes HTTP à l'aide de l'authentification Web SPNEGO.

  • WebSphere Application Server peut prendre en charge les mécanismes d'authentification Kerberos et LTPA (Lightweight Third-Party Authentication) simultanément.
  • La communication serveur-à-serveur à l'aide de l'authentification Kerberos est fournie.

Authentification Kerberos dans un environnement à super domaine Kerberos unique

WebSphere Application Server prend en charge l'authentification Kerberos dans un environnement de domaine Kerberos unique comme indiqué dans l'illustration suivante :

Figure 1. Authentification Kerberos dans un environnement à super domaine Kerberos uniqueWebSphere Application Server prend en charge l'authentification Kerberos dans un environnement à super domaine Kerberos unique.

Lorsque WebSphere Application Server reçoit un jeton Kerberos ou SPNEGO pour l'authentification, il utilise le principal de service Kerberos (SPN) pour établir un contexte de sécurité avec un demandeur. S'il est établi, le module de connexion à Kerberos de WebSphere extrait des données d'identification de délégation GSS client, crée un jeton d'authentification basé sur les données d'identification Kerberos et place ces deux éléments dans le sujet client avec d'autres jetons.

Si le serveur doit être un serveur en aval ou des ressources d'arrière-plan, il utilise les données d'identification de délégation GSS client. Si un serveur en aval ne prend pas en charge l'authentification Kerberos, le serveur utilise le jeton LTPA au lieu du jeton Kerberos. Si un client n'inclut pas de données d'identification de délégation GSS dans la requête, le serveur utilise LTPA pour le serveur en aval. Le jeton et le principal Kerberos sont transmis au serveur en aval en tant que partie de la fonction de transmission des attributs de sécurité.

Si WebSphere Application Server et le centre de distribution de clés utilisent des registres d'utilisateurs différents, un module de connexion JAAS personnalisé peut être nécessaire pour mapper le nom du principal Kerberos à celui de l'utilisateur WebSphere.

Authentification Kerberos dans un environnement Kerberos inter-domaines ou de confiance

WebSphere Application Server prend également en charge l'authentification dans un environnement Kerberos inter-domaine ou de domaine de confiance, comme indiqué dans l'illustration suivante :

Figure 2. Authentification Kerberos dans un environnement Kerberos inter-domaines ou de confianceWebSphere Application Server prend aussi en charge l'authentification Kerberos dans un environnement à domaines Kerberos multiples ou sécurisés.

Lorsque WebSphere Application Server reçoit un jeton Kerberos ou SPNEGO pour l'authentification, il utilise le principal de service Kerberos (SPN) pour établir un contexte de sécurité avec un demandeur. S'il est établi, le module de connexion à Kerberos de WebSphere extrait toujours un droit d'accès de délégation GSS client ainsi qu'un ticket Kerberos et les place dans le sujet client avec d'autres jetons.

Si le serveur doit être un serveur en aval ou des ressources d'arrière-plan, il utilise le droit d'accès de délégation GSS client. Si un serveur en aval ne prend pas en charge l'authentification Kerberos, le serveur utilise le jeton LTPA au lieu du jeton Kerberos. Si un client n'inclut pas de données d'identification de délégation GSS dans la requête, le serveur utilise LTPA pour le serveur en aval. Le jeton et le principal Kerberos sont transmis au serveur en aval en tant que partie de la fonction de transmission des attributs de sécurité.

Si WebSphere Application Server et le centre de distribution de clés utilisent des registres d'utilisateurs différents, un module de connexion JAAS personnalisé peut être nécessaire pour mapper le nom du principal Kerberos à celui de l'utilisateur WebSphere.

Dans cette édition de WebSphere Application Server, les nouveaux domaines multiples de sécurité prennent uniquement en charge Kerberos au niveau de la cellule. Tous les WebSphere Application Server doivent être utilisés par le même domaine Kerberos. Toutefois les clients et/ou ressources d'arrière-plan (telles que DB2, .NET server, etc.) qui prennent en charge l'authentification Kerberos peuvent avoir leur propre super domaine Kerberos. Seules les authentifications d'égal à égal et inter-domaines transitive trust sont prises en charge. Les étapes suivantes doivent être effectuées pour les domaines Kerberos de confiance :

  • L'installation du domaine sécurisé Kerberos doit être effectuée sur chacun des centres KDC Kerberos. Voir le guide Kerberos Administrator and User's guide pour plus d'informations sur la configuration d'un super domaine de confiance Kerberos.
  • Le fichier de configuration Kerberos peut avoir besoin de répertorier les domaines de confiance.
  • Ajoutez des domaines sécurisés Kerberos dans la console d'administration en cliquant sur Sécurité globale > Communications sortantes CSIv2 > Domaines d'authentification sécurisés - sortant.

L'illustration suivante montre un client Java d'administration qui utilise un cache d'informations d'identification Kerberos pour s'authentifier sur WebSphere Application Server avec un jeton Kerberos dans un domaine Kerberos accédité :

Figure 3. Utilisation d'un cache d'informations d'identification Kerberos pour l'authentification sur WebSphere Application Server avec un jeton Kerberos dans un domaine Kerberos accréditéUtilisation d'un cache d'informations d'identification Kerberos pour l'authentification dans WebSphere Application Server avec un jeton Kerberos dans un super domaine Kerberos sécurisé
Dans la figure précédente, voici les événements qui se produisent :
  1. Le client utilise le cache d'informations d'identification Kerberos, s'il existe.
  2. Le client demande un ticket inter-domaines (TGS_REQ) pour Realm A au KDC de Realm B à l'aide du cache d'informations d'identification Kerberos.
  3. Le client utilise un ticket inter-domaines pour demander un ticket de service Kerberos pour server1 (TGS_REQ) au KDC de Realm A.
  4. Le jeton Kerberos renvoyé par le KDC (TGS_REP ) est ajouté au jeton d'authentification de message CSIv2 et envoyé à server1 pour l'authentification.
  5. Le serveur appelle Krb5LoginModuleWrapper pour établir le contexte de sécurité avec le client en utilisant le nom SPN (Service Principal Name) et les clés Kerberos du serveur contenues dans le fichier krb5.keytab. Si le serveur réussi à établir un contexte de sécurité avec le client, il extrait toujours les données d'identification de délégation GSS et tickets client pour les placer dans le sujet client.
  6. Un module de connexion JAAS personnalisé peut être nécessaire si le centre de distribution de clés et WebSphere Application Server utilisent des registres d'utilisateurs différents.
  7. L'utilisateur est validé avec le registre d'utilisateurs WebSphere Application Server.
  8. Les résultats (succès ou échec) sont renvoyés au client.

L'illustration suivante montre un client Java d'administration qui utilise un un nom de principal et un mot de passe Kerberos pour s'authentifier sur WebSphere Application Server avec un jeton Kerberos :

Figure 4. Utilisation d'un nom de principal et d'un mot de passe Kerberos pour l'authentification dans WebSphere Application Server avec un jeton KerberosUtilisation d'un nom de principal et d'un mot de passe Kerberos pour l'authentification dans WebSphere Application Server avec un jeton Kerberos
Dans la figure précédente, voici les événements qui se produisent :
  1. Le client obtient le ticket d'octroi Kerberos (TGT) du KDC.
  2. Le client obtient un ticket de service Kerberos pour server1 (TGS_REQ) en utilisant le TGT.
  3. Le jeton Kerberos renvoyé par le KDC (TGS_REP ) est ajouté au jeton d'authentification de message CSIv2 et envoyé à server1 pour l'authentification.
  4. Le serveur appelle Krb5LoginModuleWrapper pour établir le contexte de sécurité avec le client en utilisant le nom SPN (Service Principal Name) et les clés Kerberos du serveur contenues dans le fichier krb5.keytab. Si le serveur réussi à établir un contexte de sécurité avec le client, il extrait toujours les données d'identification de délégation GSS et tickets client pour les placer dans le sujet client.
  5. Un module de connexion JAAS personnalisé peut être nécessaire si le centre de distribution de clés et WebSphere Application Server utilisent des registres d'utilisateurs différents.
  6. L'utilisateur est validé avec le registre d'utilisateurs WebSphere Application Server.
  7. Les résultats sont renvoyés au client.

La figure suivante illustre les communications serveur-à-serveur :

Figure 5. Communications serveur-à-serveurQuand une instance de WebSphere Application Server démarre, elle utilise l'ID et le mot de passe du serveur pour se connecter au KDC puis obtenir un TGT. Elle utilise ensuite ce TGT pour demander un ticket de service afin de communiquer avec un autre serveur. Si une instance de WebSphere Application Server utilise l'ID de serveur interne au lieu de l'ID et du mot de passe du serveur, la communication inter-serveur demande un jeton LTPA.

Lorsqu'un WebSphere Application Server démarre, il utilise l'ID et le mot de passe serveur pour se connecter au KDC et obtient ensuite le TGT. Il utilise alors le TGT pour demander un ticket de service afin de communiquer avec un un autre serveur. Si un WebSphere Application Server utilise l'ID serveur interne au lieu de l'ID et du mot de passe serveur, la communication serveur-à-serveur est effectuée avec un jeton LTPA. Dans la figure précédente, voici les événements qui se produisent :

  1. WebSphere Application Server 1 appelle la méthode, foo(), sur un Enterprise JavaBeans (EJB) exécuté dans l'instance WebSphere Application Server 2.
  2. Server1 obtient un ticket de service Kerberos pour Server2 (TGS_REQ) en utilisant Server1 TGT.
  3. Identique à l'étape 2.
  4. Le jeton Kerberos renvoyé par un KDC (TGS_REP) est ajouté au jeton d'authentification de message CSIv2 et envoyé à Server2 pour l'authentification.
  5. Server2 appelle la méthode acceptSecContext() pour établir le contexte de sécurité avec server1 en utilisant le nom SPN (Service Principal Name) et les clés Kerberos du server2 du fichier krb5.keytab. Si le server2 réussit à établir un contexte de sécurité avec le server1, il extrait toujours les données d'identification de délégation GSS et tickets server1 pour les placer dans le sujet.
  6. L'ID serveur est validé avec le registre d'utilisateurs WebSphere.
Eviter les incidents Eviter les incidents: Si une application client Java et le serveur d'applications existent sur la même machine et utilisent des noms de super domaine Kerberos différents, l'environnement d'exécution utilise le nom de super domaine par défaut défini dans le fichier de configuration Kerberos. Vous pouvez également spécifier le nom de super domaine à l'ouverture de session.gotcha

Eléments à prendre en compte avant de configurer Kerberos comme mécanisme d'authentification pour WebSphere Application Server

WebSphere Application Server prend à présent en charge les jetons SPNEGO dans l'en-tête HTTP, les jetons Kerberos, les jetons LTPA et BasicAuth (GSSUP) pour l'authentification.

Avant de fournir des solutions de bout en bout Kerberos et de bout-en bout SPNEGO vers Kerberos, prenez en compte ce qui suit :
  • L'option Activer la délégation des justificatifs Kerberos doit être sélectionnée. Consultez Configuration de Kerberos comme un mécanisme d'authentification utilisant la console d'administration pour plus d'informations sur cette option.
  • Un client doit obtenir un ticket TGT (ticket-granting ticket) avec des indicateurs transmissible, sans adresse et renouvelable pour qu'un serveur cible puisse extraire un droit d'accès Kerberos de délégation de client et l'utiliser pour accéder au serveur en aval.
  • Un ticket TGT assorti d'une adresse ne peut pas s'utiliser avec un serveur en aval, un cache DRS (Data Replication Service) ou un environnement en clusters.
  • Reportez-vous aux plates-formes du KDC Kerberos pour vous assurer qu'il autorise la délégation de client Kerberos.
  • Dans le cas d'une application de longue durée, un client doit demander un TGT avec indicateur renouvelable pour que le serveur cible puisse renouveler la délégation Kerberos.
  • Dans le cas d'une application à exécution longue, vérifiez que le ticket Kerberos est valable pour une durée au moins égale à celle de l'exécution. Par exemple, si l'application traite une transaction qui prend 5 minutes, le ticket Kerberos doit être valable pendant au moins 5 minutes.
  • L'authentification Kerberos et l'authentification Web SPNEGO sont toutes les deux prises en charge pour les relations de confiance inter-domaines Active Directory dans la même forêt.
  • Pour que l'agent d'administration puisse utiliser le mécanisme d'authentification Kerberos, il doit échanger une clé LTPA contre un profil de sous-système administratif.

    [z/OS]Vous devez affecter à la propriété personnalisée de sécurité suivante la valeur true : com.ibm.websphere.security.krb.longLivedTicket.

  • Si vous prévoyez d'utiliser les données d'identification de la délégation de client Kerberos pour l'authentification en aval, assurez-vous que le client peut demander un ticket de service dont la durée est supérieure à 10 minutes. Si la durée de vie des données d'identification utilisées pour la délégation de client Kerberos est inférieure à 10 minutes, le serveur tente de la renouveler.
Remarque : Les horloges des ordinateurs du client, de WebSphere Application Server et du KDC doivent être synchronisées. Une bonne pratique consiste à utiliser un serveur d'horloge pour maintenir tous les systèmes synchronisés.
Pour cette version de WebSphere Application Server, notes les éléments suivants :
  • Une prise en charge de bout en bout de Kerberos avec Tivoli Access Manager est disponible avec les KDC suivants :
    • z/OS
    • Microsoft (domaine simple ou multi-domaines)
    • AIX
    • Linux
  • Vous pouvez à présent configurer et activer les domaines croisés Kerberos pour WebSphere Application Server et le client léger.
  • La fonction d'administration WebSphere Application Server avec Kerberos est limitée comme suit :
    • Par défaut, le mécanisme d'authentification utilisé pour les activités de gestion flexibles est RSA (Rivest Shamir Adleman).
    • Si le gestionnaire de travaux est configuré avec Kerberos comme mécanisme d'authentification administrative, les domaines Kerberos croisés ne sont pas pris en charge. Ils doivent résider dans le même domaine Kerberos que les noeuds enregistrés ou utiliser le mécanisme d'authentification RSA.
    • L'authentification Kerberos est prise en charge pour les clients d'administration (wsadmin ou les clients Java), mais vous devez utiliser le même domaine KDC que celui qu'administre WebSphere Application Server. A défaut, il est conseillé d'utiliser un ID utilisateur et un mot de passe.
    • Il est impossible d'utiliser une configuration contenant à la fois des cellules Kerberos et LTPA si certains des noeuds sont des noeuds sont des noeuds WebSphere Application Server 6.x ou antérieurs.

Informations sur le support de l'authentification Kerberos

Les scénarios suivants sont pris en charge :
  • Sécurités de domaine externe ne se trouvant pas dans les mêmes forêts
  • Sécurité de domaine dans la même forêt
  • Sécurité de domaine Kerberos
Les scénarios suivants ne sont pas pris en charge :
  • Sécurité inter forêts
  • Sécurités externes de forêt

Configuration de Kerberos comme mécanisme d'authentification pour WebSphere Application Server

Vous devez exécuter les étapes selon leur ordre dans Configuration de Kerberos comme mécanisme d'authentification pour WebSphere Application Server pour configurer Kerberos comme mécanisme d'authentification pour WebSphere Application Server.
Remarque : La configuration du mécanisme d'authentification Kerberos côté serveur doit être effectuée par l'administrateur système et par les utilisateurs côté clientJava. Le nom du fichier de clés Kerberos doit être protégé.

Configuration de Kerberos comme mécanisme d'authentification pour le client Java pur.

Les utilisateurs peuvent éventuellement configurer le mécanismes d'authentification Kerberos pour le client Java pur. Pour plus d'informations, voir Configuration d'un client Java pour l'authentification Kerberos.


Icône indiquant le type de rubrique Rubrique de concept



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