Использование перехватчика ассоциации доверия (TAI) для получения токена LTPA2

у нас есть специальное веб-приложение, размещенное на сервере tomcat, и мы хотим получить LTPA2Token при входе в это приложение на tomcat. Все приложения на обоих серверах приложений используют один и тот же LDAP. Приложение на сервере tomcat не может размещаться на сервере приложений Web Sphere (WAS).

Идея заключается в следующем:

1. Введите имя пользователя и пароль в веб-приложении tomcat через веб-браузер. 2 Создайте пользовательский токен с учетными данными. 3. Отправьте эти учетные данные в пользовательский TAI на сервере приложений Web Sphere.

Вопрос в том, можем ли мы получить LTPA2Token от TAI после успешного входа в систему и отправить его обратно в приложение tomcat, чтобы LTPA2Token можно было установить в браузере?

Спасибо и с наилучшими пожеланиями Бенджамин


single-sign-on websphere jakarta-ee websphere-8 ltpa
person Ben    schedule 14.08.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Это может сработать, но оба сервера должны быть на одном и том же sso domain, например. tomcat.company.com и websphere.company.com. В административной консоли WebSphere в Security > Global security > Single sign-on (SSO) укажите в Domain name например .company.com. Вы можете указать там несколько доменов, но будет проще отлаживать, если будет только один.

Самый простой подход — создать фиктивное веб-приложение с одним jsp, которое отправит перенаправление в ваше приложение tomcat. Защитите это приложение с помощью безопасности JEE и создайте TAI, который будет перехватывать вызов этого приложения, и создайте TAIResult на основе переданного токена с идентификатором пользователя, используя:

public static TAIResult create(int status, String principal);

Это найдет основного пользователя в реестре WAS, аутентифицирует его и создаст токен LTPA. Затем перейдет на вашу страницу, которая в свою очередь перенаправит на tomcat, установив куки в браузере.

Возможно, можно было бы просто сделать это в TAI, но я никогда не пробовал это решение (и решение с пользовательским приложением будет работать).

Однако вы должны создать хороший пользовательский токен, иначе кто-то другой сможет использовать ваш TAI для аутентификации под другим именем.

PS.
Почему ваше приложение tomcat нельзя развернуть на WAS? Может быть, решить это будет проще, чем создавать это решение TAI?

person Gas    schedule 14.08.2014
comment
Спасибо за Ваш ответ. Для нас есть несколько причин, по которым развертывание этого приложения на WAS требует слишком много усилий. Два основных момента касаются управления транзакциями (WAS не предоставляет стандартный JTA javax.transaction.TransactionManager), а только проприетарные API. Кроме того, наше приложение имеет собственное асинхронное управление потоками, которое необходимо изменить, чтобы заставить его работать на WAS. Если вас интересуют подробности, вы можете прочитать это: bpm-guide.de/2012/01/22/ - person Ben; 21.08.2014

arrow_upward
1
arrow_downward

Вы, конечно, не хотите и не должны передавать учетные данные (например, пароль) в WebSphere; процесс TAI не нуждается в фактическом пароле - сама природа структуры заключается в том, чтобы разрешить доверительные отношения с помощью альтернативных средств.

Кроме того, также нет острой необходимости внедрять собственный класс TAI и связанный с ним проприетарный протокол SSO (токен, шифрование и т. д.).

WebSphere 7+ поставляется как с OAuth, так и с SAML готовые TAI (хотя для их настройки требуется настройка). Это дает вам на выбор две открытые стандартные спецификации, каждая из которых имеет обширную библиотеку Java поддержка вашего приложения Tomcat. В конечном итоге вы пишете никакого кода на стороне WebSphere, и в качестве дополнительного бонуса вы можете использовать процесс поддержки IBM PMR, если что-то пойдет не так или окажется, что оно не работает — не в случае с доморощенным TAI. решение, так как это чисто пользовательский код. Ваша половина решения Tomcat также будет работать с другими приложениями поставщика услуг на других платформах в будущем. Эти протоколы единого входа широко распространены и хорошо проработаны — проверены целой отраслью веб-разработчиков, и при правильной реализации практически не имеют векторов атак. Для этих подходов также не требуется выравнивание DNS или домена — они предназначены для работы в разных доменах.

person Scott Heaberlin    schedule 20.08.2014