Кажется, что решение, использующее SAML, является допустимым решением для случаев, когда пользователи потенциально / действительно требуют доступа к сторонней службе на ESB, но не хотят, чтобы сторонняя служба знала о спецификах безопасности ESB и учетные данные пользователя. Таким образом, ESB может предоставить провайдера токена SAML, где пользователь может получить билет и передать его в разные сервисы для аутентификации, затем сервисы проверяют токен на аутентификацию и возможную информацию авторизации (только с SAML2). В дополнение к этому SAML может использоваться как открытый ID, где пользователи управляются извне, и пользователи обращаются к внешнему провайдеру токенов, чтобы получить билеты SAML.
Это было правильное решение для нас, так как клиент хотел быть очень осведомленным о пользователях, обращающихся к ESB, и не было никакого плана доступа к сторонним службам, поскольку это была полностью закрытая система.
Впоследствии мы внедрили более настраиваемый механизм SAAS (безопасность как сервис) для внутренней аутентификации и авторизации внутри ESB (я знаю, это звучит плохо, но у iWay есть ограниченные возможности) с использованием библиотек безопасности Spring и функциональности Remember Me, которые в наш случай соответствует требованиям.
Низкий, и вот наши клиенты изменили свои требования и попросили об интеграции с share point. Это, однако, упростило модель безопасности в нашей системе, потому что мы тогда разработали следующее:
Основная модель безопасности iWay основана на SSL-сертификатах, можно реализовать поставщика SSL, который будет управлять сертификатами, поэтому вы должны иметь возможность предоставлять точку доступа с вашим SSL-сертификатом, а iWay - с общедоступным сертификатом и защищать каналы. Затем между двумя серверами вы можете управлять пользователями в iWay, которые могут получить доступ к ESB на системном уровне и указать пользователя точки доступа, даже указав его ip, эта информация передается в виде простого текста, но по SSL, а в нашем случае - между серверами в та же сеть.
Затем мы оставляем точку обмена для аутентификации пользователей на более тонком уровне, поэтому доступ к приложениям управляется на уровне портала «точка доступа», и единственное, о чем смутно осведомлен ESB, это информация об авторизации, которая передается с помощью клиентское SOAP-сообщение и определяет, к какому уровню могут быть доступны службы (эта информация используется на уровне службы).
Недостатками этого решения являются:
Для каждого нового клиентского приложения, разработанного для доступа к интерфейсам ESB, должен быть настроен новый пользователь ESB, чтобы не было возможности разрабатывать клиентов, которые могут свободно использовать определенные службы на ESB.
Новые клиенты должны реализовать логику авторизации, чтобы сервисы могли правильно отправлять и понимать правильно сформированную строку авторизации.
Другие баллы:
Мне известно, что более новая версия iWay предоставляет адаптер LDAP, который должен иметь возможность обмениваться данными с AD, чтобы вы могли подключить свой сервер LDAP к ESB таким образом, чтобы он мог использоваться другим клиентом или службами в ESB, но вам придется настроить точку доступа для доступа к информации через бизнес-провайдера iWay.
Я также считаю, что iWay 6 предоставляет провайдера токенов SAML, которого вы можете использовать (возвращаясь к тому, что я говорил ранее об использовании SAML), но я не верю, что это подходит для решения с точкой доступа.
Я бы хотел поделиться с вами другими идеями, поскольку мы оба делаем одно и то же. Можете ли вы найти меня через мой аккаунт в Твиттере, который указан в моем блоге?