Configurer un proxy pour les téléchargements de métadonnées SAML de Spring Security hérité

Une application Spring Security SAML héritée peut récupérer les métadonnées du fournisseur d'identité depuis le processus serveur avec HTTPMetadataProvider. Ce téléchargement sortant utilise le client HTTP fourni au fournisseur de métadonnées.

Pour une application qui utilise le style de configuration Spring Security SAML 1.0.x/OpenSAML 2, configurez son Apache Commons HttpClient avant de l'injecter :

org.apache.commons.httpclient.HttpClient metadataHttpClient =
    new org.apache.commons.httpclient.HttpClient();
metadataHttpClient.getHostConfiguration()
    .setProxy("proxy.example", 8080);

Passez cet objet configuré comme argument du constructeur du client HTTP de org.opensaml.saml2.metadata.provider.HTTPMetadataProvider, avec la minuterie et l'URL de métadonnées existantes. Dans une configuration XML, le bean client référencé doit être cette instance configurée.

Conservez le pool d'analyseurs existant du fournisseur, la configuration d'actualisation et le gestionnaire de métadonnées environnant. Changer la route ne remplace pas ces responsabilités.

L'URL des métadonnées reste celle du fournisseur d'identité. L'hôte du proxy appartient au client HTTP. Pour une URL de métadonnées approuvée et accessible publiquement, un candidat HTTP de la liste de proxys HTTP peut renseigner l'hôte et le port de ce client lorsque des intermédiaires publics sont autorisés et qu'aucun identifiant de proxy n'est conservé. Il s'agit d'un chemin de récupération côté serveur : une redirection réussie du navigateur vers le fournisseur d'identité ne prouve pas que le serveur d'application peut télécharger ou actualiser les métadonnées à travers ses propres restrictions réseau.

N'utilisez cette configuration que pour les classes héritées nommées ici. La prise en charge moderne de Spring Security saml2 utilise une autre API, et un bean écrit pour l'ancienne extension n'est pas interchangeable avec sa configuration de métadonnées actuelle.