Génération de jetons SPNEGO pour des demandes JAX-WS sortantes
La classe com.ibm.wsspi.security.auth.krb5. SpnegoTokenHelper peut être utilisée pour créer un jeton SPNEGO à l'aide d'un programme.
- 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 avec un ID utilisateur doté des données d'identification Kerberos, le système d'exploitation Windows gère un ticket TGT (Ticket Granting Ticket) pour cet utilisateur. La classe SpnegoTokenHelper utilise ce ticket TGT (Ticket Granting Ticket) pour demander un jeton SPNEGO qui peut être demandé pour un nom principal du service (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's 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. La classe SpnegoTokenHelper utilise ce ticket TGT (Ticket Granting Ticket) pour demander un jeton SPNEGO qui peut être demandé pour un nom principal du service (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 qui utilisent un ID utilisateur et un mot de passe. Dans ce scénario, le processus WebSphere utilise la classe SpnegoTokenHelper pour se connecter au serveur de distribution de clés Kerberos avec l'ID utilisateur et le mot de passe fournis afin d'obtenir un ticket TGT (Ticket Granting Ticket). La classe demande ensuite le jeton SPNEGO avec ce ticket TGT (Ticket Granting Ticket). La classe SpnegoTokenHelper 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 de données d'identification Kerberos existant 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 sur 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 l'ID utilisateur et le mot de passe, et le serveur WebSphere Application Server a été 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 a été configuré pour l'authentification LTPA et Kerberos. La classe SpnegoTokenHelper utilisera les données d'identification existant dans le sujet pour demander un ticket de service pour le nom principal du service (ServicePrincipalName) du système de service cible. Les méthodes associées à cette approche nécessitent un paramètre de sujet Java, en plus de la valeur de nom principal de service.
- Jeton demandé à l'aide de données d'identification Kerberos existant dans le sujet Java de l'identité de l'appelant en cours. Cette approche est semblable à la précédente, et une méthode de simplification est utilisée dans la classe SpnegoTokenHelper pour obtenir l'identité de l'appelant en cours. Les contraintes du sujet mentionnées précédemment s'appliquent tout de même. Les méthodes associées à cette approche nécessitent uniquement le nom principal du service (ServicePrincipalName).
2 variations s'appliquent à chacune des 5 approches ; dans la première variation, la durée de vie du jeton peut être spécifiée ainsi qu'un indicateur booléen signalant qu'un jeton pouvant être délégué doit être demandé. Dans la seconde variation, la durée de vie du jeton est illimitée, et ce dernier n'est pas demandé comme jeton pouvant être délégué.
Chacune de ces 5 approches renvoie une chaîne (par exemple, “Negotiate YIIFKwYG….”). Il revient au programmeur d'utiliser la chaîne pour injecter l'en-tête Authorization sortant.
- 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.
Référencement d'un fichier de clés
JAASClientUsingKeytab {
com.ibm.security.auth.module.Krb5LoginModule required useKeytab="file:///C:\\WAS\\ND855\\profiles\\AppSrv01\\config\\cells\\testserver-vmCell01-855\\cachKerbUser.keytab" credsType=both
tryFirstPass=true forwardable=true noAddress=true;
};
Exemples d'utilisation de la classe SPNEGOTokenHelper
Dans le premier exemple, un jeton SPNEGO est obtenu pour un utilisateur en fonction des données d'identification natives Windows sous lesquelles le processus WebSphere s'exécute.
String nativeToken = SpnegoTokenHelper.buildSpnegoAuthorizationStringFromNativeCreds(spn, GSSCredential.INDEFINITE_LIFETIME, false);
- spn - Nom principal du service (ServicePrincipalName) du système pour lequel le jeton SPNEGO est ciblé. Par exemple, ce nom serait une chaîne de type “HTTP/service.host.ibm.com@IBM.COM”.
- Durée de vie du contexte. Dans l'exemple, GSSCredential.INDEFINITE_LIFETIME.
- Delegate - Indique si le jeton inclut des données d'identification pouvant être déléguées. Dans cet exemple, le jeton n'inclut pas de données d'identification pouvant être déléguées.
Le deuxième exemple illustre l'utilisation d'un fichier de clés ou d'un fichier de données d'identification mis en cache. Dans cet exemple, la méthode la plus simple est utilisée (pas de durée de vie spécifiée et le jeton ne peut pas être délégué).
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromUpn(spn,upn, jaas);
- upn - Nom principal de l'utilisateur (UserPrincipalName) de l'identité provenant du fichier. Par exemple, alice@IBM.COM.
- Jaas - Nom de la configuration JAAS à utiliser (qui fait référence au fichier de clés du fichier des données d'identification mises en cache, par exemple “JAASClientUsingKeytab”.
Le troisième exemple illustre l'utilisation d'un ID utilisateur et d'un mot de passe pour générer un jeton Kerberos.
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromUseridPassword(spn,userid,pwd,1000,true);
Les nouveaux paramètres introduits sont les suivants : userid et password. L'exemple illustre également la demande d'un jeton à durée de vie non illimitée. Le jeton est généré pour une durée de 1000 secondes et il peut être délégué (le service qui est associé à ce nom principal de service doit être activé pour délégation).
Le quatrième exemple illustre un mécanisme rarement utilisé, dans lequel vous commencez avec un sujet contenant des données d'identification kerberos. Cet exemple est présenté à des fins d'exhaustivité, mais il est peu probable que vous serez amené à utiliser cette méthode, sauf si vous contrôlez la création du sujet à l'aide d'un programme.
String token = buildSpnegoAuthorizationFromSubject(spn, subject);
String token = SpnegoTokenHelper.buildSpnegoAuthorizationFromCallerSubject(spn);
Pour plus de détails, voir Génération de jetons SPNEGO pour des demandes JAX-WS sortantes via des liaisons d'ensemble de règles du client.