Client JAX-WS pour l'authentification intégrée Windows IIS (NTLM)

Question

Récemment, je travaille sur un projet qui nécessite la construction d'un client de service Web en Java fonctionnant sur le moteur JAX-WS pour parler à un service Web .NET sécurisé par Integrated Authentification Windows (également appelée protocole NTLM)

J'ai effectué une recherche sur Internet. Cela semble un problème bien connu, mais personne n'a encore de bonne solution.

Quelqu'un l'a déjà fait?

Toute suggestion sera appréciée.

Answer 1

Options de client HTTP Java Cette section décrit les implémentations connues du support NTLM avec un client HTTP Java afin que vous puissiez sélectionner l'implémentation qui répond le mieux à vos besoins.

Les implémentations disponibles sont:

Sun JRE 1.4.2 ou (gratuit) - Prise en charge complète du protocole NTLM (LM/NTLM/V2 NTLM) uniquement sur la plate-forme Windows. Prend en charge tous les niveaux de configuration NTLM (j'imagine, je n'ai pas essayé). Sun JRE 6 ou 5 (seulement 1.5_08 ou supérieur) (gratuit) - Prise en charge complète du protocole NTLM (LM/NTLM/NTLM V2) sur toutes les plates-formes. Prend en charge tous les niveaux de configuration NTLM (j'imagine, je n'ai pas essayé). Cependant, sur une machine Windows, il est supposé que vous souhaitez vous authentifier en utilisant l'utilisateur actuellement connecté. Vous pouvez contourner ce problème uniquement après l'échec de l'authentification. Client HTTP Jakarta (Apache) (gratuit, licence Apache) - Prise en charge du protocole LM/NTLM (non NTLM V2) sur toutes les plateformes Java. Nécessite JRE 1.2 ou supérieur. Non compatible avec les classes Java UrlConnection. Pas de support pour l'encodage OEM (comme requis par certains serveurs proxy). Le support de NTLM a été ajouté il y a un certain temps et ils ne semblent pas intéressés à l'étendre. Prend en charge les niveaux de configuration NTLM 0-3 uniquement. Client HTTP d'innovation avec support Luigi Dragone NTLM (gratuit, LGPL) - Le statut de ceci n'est pas clair; J'ai eu du mal à le faire fonctionner de manière fiable, et le logiciel n'a pas été publié depuis 2002. Il n'est pas compatible avec les classes Java URLConnection. Prend probablement uniquement en charge les niveaux de configuration NTLM 0-3 uniquement. JCIFS (gratuit, LGPL) - Prise en charge compatible pour LM/NTLM (non NTLM V2) sur toutes les plates-formes Java. Pas clair si l'encodage OEM est implémenté. Prend en charge les niveaux de configuration NTLM 0-3 uniquement. Client Java HTTP Java d'Oakland (non disponible gratuitement) - Prise en charge complète de LM/NTLM/NTLMv2 sur toutes les plates-formes Java JRE version 1.2 ou ultérieure. Prend en charge l'encodage Unicode et OEM. Prend en charge tous les niveaux de configuration NTLM. Si votre implémentation Java est 1.4.2 ou supérieure et que vous exécutez Java sous Windows, utilisez le support JRE intégré et vous avez terminé. Utilisez la classe java.net.Authenticator en conjonction avec la définition de certaines propriétés réseau

Si vous pouvez modifier la machine Windows à un niveau de configuration NTLM inférieur à 4 (ne pas requérir NTLM V2) et assurez-vous que la sécurité réseau: La sécurité de session minimale pour les serveurs NTLM SSP (y compris les serveurs RPC sécurisés) n'est pas définie pour requérir NTLM V2, puis utilisez le client HTTP Jakarta (si vous ne vous souciez pas de la compatibilité des prises) ou le client HTTP JCIFS si vous le faites. En outre, si vous accédez à votre serveur HTTP via un proxy qui ne prend en charge que l'encodage OEM pour NTLM, vous ne pouvez pas utiliser le client HTTP Jakarta (est-ce également le cas de JCIFS?).

Notez cependant, il y a une compatibilité potentielle liée à la baisse du client JCIFS HTTP

Answer 2

de http://jcifs.samba.org/, il montre jcifs-1.3.1 publié/NTLM Filtre HTTP fixe. cela signifie-t-il pouvoir utiliser le filtre http avec ntlmV2 sans problème?

Answer 3

Nous utilisons JAX-WS qui est intégré à Java 6, et exécutant le client sur Windows XP et Windows 2003 Server.Le serveur est IIS 7 sur Windows 2003 Server. J'ai découvert à ma surprise que l'authentification intégrée fonctionne dès la première utilisation. Aucune configuration fournie. J'ai activé la consignation de trace sur la couche HTTP et constaté que l'authentification NTLM était utilisée. Vous ne savez pas si cela fonctionnerait si seule l'authentification Négocier était utilisée et que NTLM était désactivé.

Donc, fondamentalement, la réponse est: ça marche.

Pour tester:

package url.auth; 

import java.io.IOException; 
import java.io.InputStream; 
import java.net.URL; 
import java.net.URLConnection; 
import java.util.List; 
import java.util.Map; 

import org.apache.commons.io.IOUtils; 

public class DownloadUrl { 
    public static void main(String[] args) { 

     try { 
      URL url = new URL("http://myserver/url/that/requires/authentication"); 
      URLConnection conn = url.openConnection(); 
      InputStream is = conn.getInputStream(); 
      Map<String, List<String>> headers = conn.getHeaderFields(); 
      for(String header : headers.keySet()) { 
       System.out.println(header + ": " + headers.get(header)); 
      } 
      System.out.println(""); 
      System.out.println(IOUtils.toString(is)); 
     } catch (IOException e) { 
      e.printStackTrace(); 
     } 
    } 
}