Налаштування проксі для завантаження метаданих SAML у старому Spring Security

Налаштуйте HTTP-клієнт, який упроваджується у старий Spring Security SAML HTTPMetadataProvider, для завантаження метаданих на боці сервера.

Старий застосунок Spring Security SAML може отримувати метадані постачальника ідентичності із серверного процесу за допомогою HTTPMetadataProvider. Це вихідне завантаження використовує HTTP-клієнт, переданий постачальнику метаданих.

Для застосунку зі стилем конфігурації Spring Security SAML 1.0.x/OpenSAML 2 налаштуйте його Apache Commons HttpClient перед упровадженням:

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

Передайте цей налаштований об'єкт як аргумент конструктора HTTP-клієнта org.opensaml.saml2.metadata.provider.HTTPMetadataProvider разом із наявним таймером і URL метаданих. У конфігурації XML зазначений bean клієнта має бути саме цим налаштованим екземпляром.

Збережіть наявний пул парсерів постачальника, конфігурацію оновлення та навколишній менеджер метаданих. Зміна маршруту не замінює ці обов'язки.

URL метаданих залишається URL постачальника ідентичності. Хост проксі належить HTTP-клієнту. Для схваленого й загальнодоступного URL метаданих HTTP-кандидат зі списку HTTP-проксі може заповнити хост і порт цього клієнта, коли публічні посередники дозволені й облікові дані проксі не зберігаються. Це шлях отримання на боці сервера: успішне переспрямування браузера до постачальника ідентичності не доводить, що сервер застосунку може завантажувати або оновлювати метадані крізь власні мережеві обмеження.

Використовуйте цю конфігурацію лише для перелічених тут старих класів. Сучасна підтримка Spring Security saml2 використовує інший API, і bean, написаний для старого розширення, не взаємозамінний з його поточною конфігурацією метаданих.

Схожі статті