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

Question

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

Мы разрабатываем Notification Service в событий. Приложение на высоком уровне выглядит следующим образом:

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

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

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

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

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

Что является лучшим решением для хранения учетных данных db, sap и пользователей.

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

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

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

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

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

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

Disadvs здесь:

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

Способ, которым я чаще всего видел этот шаблон, заключается в том, что авторизация происходит на подписке, а не на обратной стороне. Иерархия тем отражает модель безопасности внешнего приложения. Если в фокусе есть функции для запроса на Produce, Deli и Grocery, существуют узлы темы с одинаковыми классификациями. Пользователи, авторизованные в задней системе для бакалеи, также имеют право на тему бакалеи. Разрешения в внутренней системе могут периодически экспортироваться (часто это ночное время) и преобразуются в настройки авторизации в pub/sub broker. В одной из реализаций, которые я работал над внутренней системой, будут публиковаться изменения авторизации в pub/sub broker в защищенной административной теме, чтобы авторизация подписчика была обновлена ​​в почти реальном времени.

Понятие передачи учетных данных обратно в исходную систему звучит безопасно с первого взгляда, но при более глубоком осмотре возникают некоторые проблемы. Во-первых, как вы планируете масштабировать это? Я никогда не видел успешной системы уведомлений о событиях, которая не использовалась повторно. Каждая внутренняя система будет иметь разные требования к аутентификации, обычно разные учетные данные, различные требования к действительности и кэшированию и т. Д. Создание системы для передачи учетных данных обратно в несколько внутренних приложений - это одно. Делать это на 10 или 20 - это кошмар.

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

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

Answer 4

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

* EDIT: Портативный в смысле доступа к корпоративному приложению.