Jetty 12.0.x SPNEGO : définir le nom du service, pas le principal complet

Séparez l'URI du proxy, l'utilisateur JAAS et le composant de service GSS lors de la configuration de l'authentification Jetty 12.

Une configuration SPNEGO de Jetty comporte trois noms : l'URI servant à faire correspondre l'authentification, l'utilisateur qui se connecte via JAAS et le service pour lequel un ticket est demandé. Ils ont des rôles différents.

Pour l'implémentation Jetty 12.0.x, un extrait d'objet d'authentification est :

var auth = new org.eclipse.jetty.client.SPNEGOAuthentication(
    java.net.URI.create("http://proxy.example:8080"));
auth.setServiceName("HTTP");

Cet extrait illustre le composant de service, pas une recette complète d'authentification par proxy. La connexion JAAS, le routage du proxy et l'échange d'authentification de la requête restent distincts.

Dans cette implémentation, Jetty construit le nom GSS basé sur l'hôte en combinant getServiceName(), le caractère @ et l'hôte de l'échange d'authentification. Fournir [email protected] comme composant de service ajouterait un autre hôte. Lisez le contrat de ce setter au lieu de supposer qu'il accepte un principal Kerberos complet.

Le nom GSS obtenu a la forme conceptuelle HTTP@hostname. Le principal de service correspondant du KDC est généralement représenté par HTTP/hostname. Le nom de proxy sélectionné doit correspondre au service réellement enregistré pour ce compte ; une adresse IP ou un alias peut sélectionner une autre cible de ticket.

Examinez aussi le chemin 407

Dans Jetty 12.0.x, authenticate() obtient le nom d'hôte GSS depuis request.getHost() et construit un résultat avec l'en-tête Authorization par défaut. Faire correspondre un objet d'authentification par URI de proxy ne change pas à lui seul ces choix en nom d'hôte du proxy et Proxy-Authorization.

Une intégration proxy a donc besoin du bon hôte de requête et d'un résultat limité au proxy pour cet échange. Une requête HTTPS CONNECT et une requête d'origine ordinaire peuvent avoir des valeurs d'hôte différentes. Vérifiez le comportement de l'implémentation installée au lieu de supposer que le setter du nom de service fournit le flux 407 complet.

Pour un 407, examinez l'échange d'authentification du proxy et l'hôte utilisé par cette requête. Un 401 relève de l'authentification d'origine. Un ticket utilisateur valide ne prouve pas à lui seul que Jetty a demandé le bon ticket de service ni que l'intermédiaire l'a accepté.

Articles similaires