где хранить учетные данные пользователя в корпоративном приложении (EAI)?

Question

Предпосылки / контекст

Мы разрабатываем Службу уведомления о событиях . Приложение на высоком уровне выглядит так:

Наша область разработки включает виджет и ENS.

" ENS " действует как центральная точка сбора для определенных типов событий, которые представляют интерес для пользователей. Любой пользователь, который хочет знать, когда происходят подобные события, регистрируется в ENS, который идентифицирует события в порядке и сопоставляет уведомления с подписками.

Пользователь, который хочет подписаться, должен быть действительным пользователем интегрированного приложения (db, sap system и т. Д.)

Последовательность событий:

Теперь мой вопрос:

Как лучше всего хранить учетные данные пользователей db, sap и т. Д.

EDIT Как часто пользователь должен проходить аутентификацию? Должно быть каждый раз, когда сообщения доставляются? (Как уже упоминалось @duffymo, если я использую эту стратегию, это повлияет на исходную систему)

Дополнительная информация: ENS - это веб-сервисы.

ENS опрашивает SAP (и другие приложения), и здесь проблема становится все более сложной. В SAP есть авторизация на уровне данных. Поэтому не всем пользователям разрешено видеть все события / данные.

Если SAP выдвинула данные вместе с информацией о пользователе, который разрешил просматривать, то никаких проблем вообще нет.

Случай 1: Планировщик инициируется ENS

1. Пользователь подписывается на подписку. Во время подписки пользователь проверяется на предмет его авторизации в системе SAP. Если все в порядке, он будет допущен к подписке.
2. Планировщик работает в запланированное время.
3. Планировщик идентифицирует пользователей, которые подписаны.
4. Планировщик использует сохраненные учетные данные пользователей (выделено в ENS) для опроса, если произошло событие.
5. Уведомлять пользователей, если есть изменения.

Disadvs здесь:

• Учетные данные пользователя хранятся где-то внешний - команда безопасности может не принять это
• Редуцирующие удары, если более одного пользователя подписан на тот же кусок информация

Случай 2: Планировщик запускается WIDGET. Пользовательские кредиты будут храниться только на локальном компьютере пользователя. Diadv:

• Если подписка ежедневная, и если пользовательская система / виджет не работает. пользователь может пропустить уведомления это случилось, скажем, в выходные дни.
• Избыточные попадания на сервер, если больше чем один пользователь подписан на та же информация.

Answer 1

Обычно это приложение, которое предоставляет учетные данные для базы данных, SAP и т. Д. У отдельных пользователей учетные данные хранятся в LDAP или базе данных; проверка подлинности и авторизация будут рассматриваться в качестве сквозного вопроса приложением, сервером EAI или устройством, таким как SiteMinder.

Входящие запросы будут перехватываться и проверяться на наличие токенов авторизации. Если токен не появляется, проверьте аутентификацию и авторизацию. Если разрешено, создайте токен авторизации и кешируйте его.

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

Я вижу только одну проблему.

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

Посмотрите на стандарты, подобные SAML, чтобы узнать, может ли он вам помочь.

Проблема кэширования зависит от сравнения времени между событиями и между изменениями авторизации. Если время между событиями велико по сравнению с изменениями авторизации, вы должны проверять каждый раз, потому что у вас нет возможности узнать, была ли авторизация отменена с момента последнего события.

Answer 2

Чаще всего этот шаблон реализован таким образом, что авторизация происходит при подписке, а не на бэкэнде.Иерархия тем отражает модель безопасности внутреннего приложения.Если в бэкэнде есть функции для запросов по продуктам, продуктам и продуктам, существуют тематические узлы с одинаковыми классификациями.Пользователи, авторизованные в бэкэнд-системе для бакалеи, также авторизованы в разделе «Бакалея».Полномочия в серверной системе могут периодически экспортироваться (часто это происходит по ночам) и преобразовываться в настройки авторизации в пабе / субброкере.В одной реализации, над которой я работал, внутренняя система публиковала изменения авторизации в брокере pub / sub по защищенной административной теме, чтобы авторизация подписчиков поддерживалась в актуальном состоянии практически в реальном времени.передача учетных данных обратно в исходную систему на первый взгляд кажется безопасной, но при более глубокой проверке возникают некоторые проблемы.Во-первых, как вы планируете масштабировать это?Я никогда не видел успешную систему оповещения о событиях, которая не использовалась бы повторно.Каждая внутренняя система будет иметь разные требования к аутентификации, обычно разные учетные данные, разные требования к валидности и кешированию и т. Д. Создание системы для передачи учетных данных обратно в пару внутренних приложений - это одно.Выполнение этого для 10 или 20 - это кошмар.

Предполагая, что вы решили указанные выше проблемы, вы теперь кэшировали учетные данные пользователя для половины серверных корпоративных систем в одном месте.Если эта центральная система скомпрометирована, то же самое относится и ко всем внутренним системам, с которыми она общается.Эта центральная система стала самой важной точкой безопасности на предприятии.Серьезное обеспечение безопасности, необходимое для решения этой проблемы, является дорогостоящим.

Да, это неприятно, когда дерево тем и разрешения посредника pub / sub отражают модель безопасности внутренних приложений.,Но, в конце концов, это намного проще (и дешевле), чем разработка централизованного брокерского сервиса, достаточно безопасного для хранения всех учетных данных, а также способного проверять их в нескольких внутренних системах, не перегружая брокера или исходные системы, которые публикуютк этому.

Answer 3

LDAP будет лучшим вариантом для безопасного, быстрого и портативного хранения

* РЕДАКТИРОВАТЬ: Портативный в смысле доступа к вашему корпоративному приложению.

Answer 4

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

Другойвещь, которую вы можете использовать, чтобы иметь дело с делом на внешних системах, удаляющих пользователя, состоит в том, чтобы у уведомительных сообщений от внешних систем было время истечения срока действия на них.Например, уведомление SAP может быть действительным в течение 2 часов после создания.Если пользователь не получит сообщение в течение 2 часов, оно будет удалено.Если вы объедините срок действия сообщения с уведомлением от SAP о том, что пользователь больше не действителен, то вы можете знать, что существует ограничение по времени, в течение которого пользователь будет признан недействительным.технологий, которые вы используете для внедрения ENS, тогда мы могли бы дать вам более конкретные ответы.