Génération de jetons SPNEGO pour des demandes JAX-WS sortantes via des liaisons d'ensemble de règles du client
Les clients JAX-WS peuvent procéder à l'authentification en utilisant différents mécanismes d'authentification de transport HTTP.
Outre l'authentification pour les applications de fournisseur de service via l'authentification WS-Security,
les clients JAX-WS peuvent procéder à l'authentification en utilisant différents mécanismes d'authentification de transport HTTP, tels que les suivants :
- Authentification de base via les propriétés des liaisons de transport HTTP.
- Authentification client SSL/TLS via les liaisons de transport SSL.
- Authentification SPNEGO via les propriétés personnalisées des liaisons de transport HTTP.
Il existe 5 méthodes permettant d'obtenir les données d'identification Kerberos utilisées pour le jeton SPNEGO sortant :
- Un jeton demandé à l'aide des données d'identification natives Windows. Lorsque le processus WebSphere Java™ s'exécute sur un système Windows sous un ID utilisateur doté des données d'identification Kerberos, le système d'exploitation Windows gère un ticket TGT (Ticket Granting Ticket) Kerberos pour cet utilisateur. L'environnement d'exécution client JAX-WS utilise ce ticket TGT (Ticket Granting Ticket) pour demander un jeton SPNEGO qui peut être demandé pour un nom principal du service Kerberos (ServicePrincipalName) du système de service cible.
- Un jeton demandé à l'aide des données d'identification Kerberos mises en cache. Sur un système auquel un utilisateur s'est connecté, généralement à l'aide d'outils tels que l'outil kinit de Java, les données d'identification Kerberos de l'utilisateur sont stockées dans un fichier cache nommé krb5cc_<userid>. Sinon, un fichier de clés contenant la clé d'un utilisateur peut être créé à l'aide d'un certain nombre d'outils, tels que l'outil Microsoft ktpass ou l'outil Java ktab. Ces fichiers contiennent une copie de la clé Kerberos de l'utilisateur pouvant être utilisée pour obtenir un ticket TGT (Ticket Granting Ticket) pour cet ID utilisateur. L'environnement d'exécution client JAX-WS utilise ce ticket TGT (Ticket Granting Ticket) pour demander un jeton SPNEGO qui peut être demandé pour un nom principal du service Kerberos (ServicePrincipalName) du système de service cible. Le processus WebSphere doit être configuré pour utiliser le fichier krb5cc_<userid> ou le fichier de clés. Le nom principal de l'utilisateur (UserPrincipalName) des données d'identification mises en cache au sein du fichier doit également être fourni.
- Un jeton demandé à l'aide des données d'identification Kerberos avec un ID utilisateur et un mot de passe. Dans ce scénario, l'environnement d'exécution JAX-WS se connecte au serveur de distribution de clés kerberos à l'aide de l'ID utilisateur et du mot de passe fournis pour obtenir un ticket TGT (Ticket Granting Ticket). La classe demande ensuite le jeton SPNEGO avec ce ticket TGT (Ticket Granting Ticket). L'environnement d'exécution client JAX-WS requiert le nom principal du service (ServicePrincipalName) pour le système de service cible, ainsi que l'ID utilisateur et le mot de passe.
- Un jeton demandé à l'aide des données d'identification Kerberos qui existent
dans un sujet Java. Le sujet peut obtenir des données d'identification Kerberos de l'une des manières suivantes :
- L'utilisateur s'est connecté à une application Web à l'aide de l'authentification Web SPNEGO entrante. Seule l'authentification Web SPNEGO doit être configurée et activée dans le serveur WebSphere Application Server pour cette option. L'ID utilisateur Kerberos qui est associé au service SPNEGO entrant doit être activé pour la délégation Kerberos complète.
- Une demande de service Web JAX-WS a contenant un jeton Kerberos WS-Security a été reçue. L'ID utilisateur Kerberos qui est associé à la demande de service Web entrant doit être activé pour une délégation Kerberos totale.
- L'utilisateur s'est connecté avec un ID utilisateur et un mot de passe, et le serveur WebSphere Application Server est configuré pour l'authentification LTPA et Kerberos.
- Une demande de service Web JAX-WS contenant un jeton de nom d'utilisateur et un mot de passe a été reçue, et le serveur WebSphere Application Server est configuré pour l'authentification LTPA et Kerberos.
Pour les 5 variations décrites précédemment pouvant être utilisées
afin d'obtenir les données d'identification Kerberos utilisées pour le jeton SPNEGO sortant, des propriétés personnalisées
doivent être définies sur les liaisons HTTP dans les liaisons d'ensemble de règles du client.
Nom de la propriété | valeur | Commentaires |
---|---|---|
com.ibm.websphere.webservices.spnego.enabled | Boolean | Doit avoir pour valeur true afin d'activer des options d'authentification SPNEGO dans l'environnement d'exécution de liaison de client JAX-WS. |
com.ibm.websphere.webservices.spnegoOutboundSPN | String | Doit avoir pour valeur le nom principal du service pour le fournisseur de service Web. |
com.ibm.websphere.webservices.spnegoLoginMechanism | String | Doit avoir pour valeur GSSUP, native, caller ou keytab. |
com.ibm.websphere.webservices.JAASConfigName | String | Lorsque le fichier de clés est indiqué pour spnegoLoginMechanism, la configuration de connexion JAAS qui identifie le fichier de clés à utiliser doit être indiquée pour cette propriété. |
com.ibm.websphere.webservices.spnegoUPN | String | Lorsque le fichier de clés est indiqué pour spnegoLoginMechanism, le nom principal d'utilisateur de la clé dans le fichier de clés à utiliser doit être indiqué pour cette propriété. |
com.ibm.websphere.webservices.spnegoOutboundLifeTime | Entierr | Si cette propriété n'est pas spécifiée, le jeton SPNEGO est demandé pendant une durée illimitée. |
com.ibm.websphere.webservices.spnegoOutboundDelegate | Boolean | Si cette propriété a pour valeur true et que le compte SPN de service Web est activé pour délégation, le jeton SPNEGO envoyé au service Web peut être délégué. |
Lorsque la propriété spnegoLoginMechanism a pour valeur GSSUP, l'ID utilisateur et le mot de passe sont obtenus à partir des propriétés Authentification de base pour les demandes de service sortantes.
Lorsque la propriété spnegoLoginMechanism a pour valeur caller, les données d'identification Kerberos sont obtenues à partir du sujet de l'appelant.
Lorsque la propriété spnegoLoginMechanism a pour valeur Native, les données d'identification Kerberos sont obtenues à partir du système d'exploitation Windows.
- Remarques sur les données d'identification natives
- La mémoire cache des données d'identification d'ouverture de session Kerberos
Microsoft (MSLSA) repose sur la possibilité
d'extraire la totalité du ticket Kerberos, y compris la clé de session de la mémoire cache
des données d'identification d'ouverture de session Kerberos (LSA). Dans le but d'améliorer la sécurité, Microsoft a implémenté une fonction
qui permet de ne plus exporter les clés de session pour les tickets d'octroi de ticket,
ce qui peut les rendre inutiles pour IBM® JGSS lors des tentatives de demandes de ticket de service
supplémentaires. Cette nouvelle fonction est visible à partir des systèmes Windows 2003 Server. Microsoft a fourni la clé de registre suivante pour
désactiver cette nouvelle fonction :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters AllowTGTSessionKey = 0x01 (DWORD)
- Exigences relatives au fichier de configuration Kerberos
- Le fichier de configuration Kerberos doit être correctement configuré, quelle que soit l'approche choisie.
- La manière dont le processus WebSphere atteint le centre de distribution de clés doit être correctement configurée via les sections [realms] et [domain_realm].
- Les types de chiffrement à utiliser dans la section [libdefaults] doivent spécifier les valeurs default_tkt_enctypes et default_tgs_enctypes.
- La section [libdefaults] doit inclure les éléments suivants :
- forwardable = true
- renewable = true
- noaddresses = true
- La section [libdefaults] doit définir une valeur clockskew raisonnable.