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

Le mécanisme d'authentification Kerberos permet 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 car le mécanisme d'authentification a été ajouté pour 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. La prise en charge est fournie pour permettre au client enrichi Java™ d'utiliser le jeton Kerberos pour l'authentification auprès de WebSphere Application Server.
Les sections suivantes décrivent plus en détail l'authentification Kerberos :

Présentation de Kerberos

Kerberos a résisté à l'épreuve du temps et en est à la version 5.0. Kerberos bénéficie d'une prise en charge étendue de la plateforme (par exemple, pour Windows, Linux®, Solaris, AIX®et z/OS®) en partie parce que le code source Kerberos est librement téléchargeable à partir du Massachusetts Institute of Technology (MIT) où il a été créé à l'origine.

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 l'utilisation de Kerberos comme mécanisme d'authentification pour WebSphere Application Server sont les suivants:

  • Le protocole Kerberos est une norme. Cela permet 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 qui représente l'identité du client est envoyé à WebSphere Application Server pour l'authentification.
  • Un client Java peut participer à la connexion unique Kerberos à l'aide du cache de données d'identification Kerberos pour l'authentification auprès de WebSphere Application Server.
  • Les clients J2EE, de service Web, .NET et de navigateur Web qui utilisent le protocole HTTP peuvent utiliser le jeton SPNEGO (Simple and Protected GSS-API Negotiation Mechanism) pour s'authentifier auprès de WebSphere Application Server et participer à la connexion unique à l'aide de l'authentification Web SPNEGO. La prise en charge de SPNEGO en tant que service d'authentification Web est une nouveauté de cette édition de WebSphere Application Server.

    Pour plus d'informations, voir Connexion unique SPNEGO .

  • WebSphere Application Server peut prendre en charge simultanément les mécanismes d'authentification Kerberos et LTPA (Lightweight Third-Party Authentication).
  • 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 seul environnement de domaine Kerberos , comme illustré dans la figure suivante:

Figure 1 : Authentification Kerberos dans un environnement à super domaine Kerberos unique
WebSphere Application Server prend en charge l'authentification Kerberos dans un seul environnement de domaine Kerberos

Lorsque WebSphere Application Server reçoit un jeton Kerberos ou SPNEGO pour l'authentification, il utilise le principal de service (SPN) Kerberos pour établir un contexte de sécurité avec un demandeur. Si un contexte de sécurité est établi, le module de connexion WebSphere Kerberos extrait des données d'identification de délégation GSS client, crée une base de jeton d'authentification Kerberos sur les données d'identification 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 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 n'utilisent pas le même registre d'utilisateurs, un module de connexion personnalisé JAAS peut être nécessaire pour mapper le nom de principal Kerberos au nom d'utilisateur WebSphere .

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

WebSphere Application Server prend également en charge l'authentification Kerberos dans un environnement de domaine Kerberos sécurisé ou croisé, comme illustré dans la figure suivante:

Figure 2. Authentification Kerberos dans un environnement Kerberos inter-domaines ou de confiance
WebSphere Application Server prend également en charge l'authentification Kerberos dans un environnement de superdomaine Kerberos sécurisé

Lorsque WebSphere Application Server reçoit un jeton Kerberos ou SPNEGO pour l'authentification, il utilise le principal de service (SPN) Kerberos pour établir un contexte de sécurité avec un demandeur. Si un contexte de sécurité est établi, le module de connexion WebSphere Kerberos extrait toujours les données d'identification de délégation GSS client et le 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 n'utilisent pas le même registre d'utilisateurs, un module de connexion personnalisé JAAS peut être nécessaire pour mapper le nom de principal Kerberos au nom d'utilisateur WebSphere .

Dans cette édition de WebSphere Application Server, les nouveaux domaines de sécurité multiples prennent uniquement en charge Kerberos au niveau de la cellule. Tous les serveurs WebSphere Application Server doivent être utilisés par le même domaine Kerberos . Toutefois, les clients et / ou les ressources de back end (tels que DB2, serveur .NET, etc.) qui prennent en charge l'authentification Kerberos peuvent avoir leur propre 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 > CSIv2 communications sortantes > Domaines d'authentification sécurisés-sortants.

La figure suivante illustre un client d'administration et Java qui utilise un cache de données d'identification Kerberos pour s'authentifier auprès de WebSphere Application Server avec un jeton Kerberos dans un domaine Kerberos sécurisé:

Figure 3 Utilisation d'un cache de données d'identification Kerberos pour l'authentification auprès de WebSphere Application Server avec un jeton Kerberos dans un domaine Kerberos sécurisé
Utilisation d'un cache de données d'identification Kerberos pour l'authentification auprès de WebSphere Application Server avec un jeton Kerberos dans un 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. En option, un module de connexion JAAS personnalisé peut être nécessaire si le centre de distribution de clés et WebSphere Application Server n'utilisent pas le même registre d'utilisateurs.
  7. L'utilisateur est validé avec le registre d'utilisateurs pour WebSphere Application Server.
  8. Les résultats (succès ou échec) sont renvoyés au client.

La figure suivante illustre un client d'administration et Java qui utilise un nom de principal et un mot de passe Kerberos pour s'authentifier auprès de 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 auprès de WebSphere Application Server avec un jeton Kerberos
Utilisation d'un nom de principal et d'un mot de passe Kerberos pour l'authentification auprès de 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. En option, un module de connexion JAAS personnalisé peut être nécessaire si le centre de distribution de clés et WebSphere Application Server n'utilisent pas le même registre d'utilisateurs.
  6. L'utilisateur est validé avec le registre d'utilisateurs pour WebSphere Application Server.
  7. Les résultats sont renvoyés au client.

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

Figure 5. Communications serveur-à-serveur
Lorsqu'un serveur d'applications WebSphere démarre, il utilise l'ID et le mot de passe du serveur pour se connecter au centre de distribution de clés, puis obtient le ticket d'octroi d'autorisations. Il utilise alors le TGT pour demander un ticket de service afin de communiquer avec un un autre serveur. Si un serveur d'applications WebSphere utilise l'ID serveur interne à la place de l'ID serveur et du mot de passe, la communication serveur à serveur est effectuée à l'aide d'un jeton LTPA.

Lorsqu'un serveur WebSphere Application Server démarre, il utilise l'ID et le mot de passe du serveur pour se connecter au centre de distribution de clés, puis obtient le ticket d'octroi d'autorisations. Il utilise alors le TGT pour demander un ticket de service afin de communiquer avec un un autre serveur. Si un serveur WebSphere Application Server utilise l'ID serveur interne à la place de l'ID serveur et du mot de passe, la communication entre serveurs est effectuée à l'aide d'un jeton LTPA. Dans la figure précédente, voici les événements qui se produisent :

  1. WebSphere Application Server 1 appelle une méthode, foo (), sur un EJB ( JavaBeans ) exécuté dans 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 problèmes: Si une application client Java et le serveur d'applications existent sur la même machine et qu'ils utilisent des noms de domaine Kerberos différents, l'environnement d'exécution utilise le nom de domaine par défaut du fichier de configuration Kerberos . Vous pouvez également spécifier le nom de super domaine à l'ouverture de session.
Eviter les problèmes: Kerberos et LTPA peut être configurée dans plusieurs environnements KDC. L'authentification de base peut consistée en un mot de passe et un nom abrégé sans le nom de domaine Kerberos. Pour cette authentification de base, une combinaison des éléments domain_realm et default_realm détermine le KDC utilisé par le client Kerberos pour authentifier la demande. Les utilisateurs qui n'appartiennent pas au KDC déterminé doivent se connecter avec un nom principal kerberos complet (par exemple, Bob@myKerberosRealm).

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

WebSphere Application Server prend désormais 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. Pour plus d'informations sur cette option, voir Configuration de Kerberos comme mécanisme d'authentification à l'aide de la console d'administration .
  • 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.
  • 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: le client, WebSphere Application Server et les machines KDC doivent maintenir l'horloge synchronisée. Une bonne pratique consiste à utiliser un serveur d'horloge pour maintenir tous les systèmes synchronisés.
Pour cette édition de WebSphere Application Server, tenez compte des points suivants:
  • La prise en charge complète de Kerberos de bout en bout avec Tivoli ® Access Manager est disponible à l'aide des KDC suivants:
    • z/OS
    • Microsoft (domaine unique ou multi-domaine)
    • AIX
    • Linux
  • Vous pouvez désormais 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 par les éléments suivants:
    • 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.
    • Alors que l'authentification Kerberos est prise en charge pour les clients d'administration (wsadmin ou clients Java), vous devez utiliser le même domaine KDC que celui administré par WebSphere Application Server . A défaut, il est conseillé d'utiliser un ID utilisateur et un mot de passe.
    • La configuration de cellules mixtes Kerberos et LTPA n'est pas prise en charge lorsque certains des noeuds sont des noeuds WebSphere Application Server Release 6.x ou des noeuds 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 sont pris en charge :
  • Sécurité inter forêts
  • Sécurisations externes à la forêt

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

Vous devez effectuer les étapes dans l'ordre indiqué dans Configuration de Kerberos comme mécanisme d'authentification pour WebSphere Application Server pour configurer Kerberos en tant que mécanisme d'authentification pour WebSphere Application Server.
Remarque: le mécanisme d'authentification Kerberos côté serveur doit être effectué par l'administrateur système et côté client Java par les utilisateurs. 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 finaux peuvent éventuellement configurer le mécanisme d'authentification Kerberos pour le client Java pur. Pour plus d'informations, voir Configuration d'un client Java pour l'authentification Kerberos .

[9.0.5.7 ou ultérieure]

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

Vous pouvez configurer Kerberos comme mécanisme d'authentification de liaison pour établir la liaison au serveur LDAP et effectuer des recherches d'utilisateur et de groupe. Ce mécanisme d'authentification de liaison est une alternative au mécanisme d'authentification de liaison simple qui utilise un nom distinctif et un mot de passe de liaison.

Pour configurer Kerberos comme mécanisme d'authentification de liaison pour les serveurs LDAP dans des référentiels fédérés, suivez les étapes indiquées dans la rubrique relative à la configuration de LDAP dans une configuration de référentiel fédéré.

Pour configurer Kerberos comme mécanisme d'authentification de liaison pour un serveur LDAP autonome, suivez les étapes indiquées dans la rubrique relative à la configuration de registres utilisateur LDAP.