Ограничение двухстороннего SSL-соединения Wildfly 14 для определенных клиентов

Мы поддерживаем Java-приложение с SOAP API JAX-WS для внешних систем, работающих на сервере приложений WildFly 14. В настоящее время внешние системы подключаются с использованием обычного одностороннего SSL. Наша цель - переключить связь на взаимную аутентификацию, то есть двусторонний SSL. Однако не все внешние системы могут выполнять переключение в одно и то же время, поэтому простое применение двухстороннего SSL - не вариант. Мы должны перенести их шаг за шагом на переходном этапе. Вот почему мне было интересно: есть ли возможность включить двусторонний SSL на интерфейсе WildFly HTTPS только для определенных IP-адресов вызывающих абонентов?

Я основал свои тесты на официальной документации по настройке обычного двустороннего SSL. Следуя этим шагам, каждый абонент должен предоставить сертификат клиента. Изменение этого примера конфигурации для использования want-client-auth вместо need-client-auth смягчает проверки для поддержки двустороннего SSL, но не требует его. К сожалению, этого недостаточно в нашем случае, потому что это не подразумевает гарантии того, что конкретная внешняя система последовательно использует двусторонний SSL или нет. Система может отправить некоторые из своих запросов с предоставлением сертификата клиента, а некоторые без него. Другими словами, бизнес нуждается в способе сказать: "С этого дня внешняя система Foo может использовать API только с сертификатом клиента. На данный момент все остальные внешние системы не затронуты".

Чтобы реализовать это - желательно без изменений кода приложения - я читал документацию нового модуля безопасности WildFly Elytron. Это кажется довольно расширяемым, но детали пользовательских компонентов немногочисленны, и я не нашел точки расширения, которая звучит так, как будто бы это помогло в моем случае.

Единственный подход к решению, который у меня есть сейчас, - это настройка отдельного набора привязки к сокету и https-слушателя для Wildfly, аналогичного описанному здесь. Это означает, что у нас будет два порта HTTPS: один с односторонним SSL, а другой с обязательным двусторонним SSL. Когда внешние системы завершают свои шаги по миграции, они переключают порт, используемый для вызова нашего API. Чтобы заставить их использовать только двусторонний порт SSL, с этого момента потребуются определенные правила брандмауэра, но это должно быть возможно.

Таким образом, это решение довольно просто в технической реализации, но приводит к накладным расходам на переконфигурирование внешних систем и адаптацию правил брандмауэра. Вот почему я буду рад любым предложениям по более элегантному решению или советам, как использовать Elytron для этого. Заранее спасибо!

1 ответ

Я думаю, что вы пришли к лучшему выводу. Elytron не имеет возможности выбирать контекст SSL на основе параметров клиента (что это будет? IP-адрес клиента? Который может измениться за балансировщиком нагрузки).

Поэтому я думаю, что единственный способ - настроить разные SSL Context на разных портах (или именах хостов).

По поводу расширения сервера. Я думаю, SSL рукопожатие - очень ранний шаг, и после этого участвуют различные точки настройки. Я подумал о каком-то пользовательском обработчике Undertow, похожем на [1], но, как я уже сказал, это будет слишком поздно.

[1] http://undertow.io/undertow-docs/undertow-docs-2.0.0/index.html

Другие вопросы по тегам