在企业应用程序 (EAI) 中将用户凭据存储在哪里？
背景/背景
我们正在开发事件通知服务。高层应用程序如下所示： 
我们的开发范围涉及 widget 和 ENS。
“ENS”充当用户感兴趣的某些类型事件的中心收集点。 任何想要知道此类事件何时发生的用户都可以向 ENS 注册， 它按顺序识别事件并将通知与订阅进行匹配。
想要订阅的用户应该是集成应用程序（db、sap 系统等）的有效用户。
事件顺序：
现在我的问题是：
存储用户数据库、sap 等凭据的最佳实践是什么
编辑 用户应该多久进行一次身份验证？应该是每次消息传递时？（正如 @duffymo 提到的，如果我使用此策略，它将影响源系统）
其他信息： ENS 是网络服务。
ENS 轮询 SAP（和其他应用程序），这就是问题变得更加复杂的地方。 SAP中有数据级授权。因此并非所有用户都可以查看所有事件/数据。
如果 SAP 已推送数据以及有权查看的用户信息，则完全没有问题。
情况1：Scheduler由ENS User发起
- 订阅订阅。订阅时，将检查用户在 SAP 系统中的授权。如果可以，那么他将被允许订阅。
- 调度程序在预定时间运行。
- 调度程序识别订阅的用户。
- 如果事件发生，调度程序将使用存储的用户凭据（存储在 ENS 中）进行 POLL。
- 如有变更，通知用户。
这里的缺点：
- 用户凭据存储在某处 外部 - 安全团队可能不会 则接受
- 如果有多个用户， 冗余点击 订阅了同一篇文章 信息
情况2：调度程序由WIDGET 发起。用户信用信息将仅存储在用户本地计算机中。 Diadv：
- 如果订阅是每日的，并且如果 用户系统/小部件未启动。这 用户可能会错过通知 这发生在周末。
- 如果更多，则对服务器进行冗余命中 超过一个用户订阅了 同一条信息。
Background/Context
We are developing a Event Notification Service. The application at a high level looks like below:
Our developene scope involves widget and the ENS.
"ENS" acts as a central point of collection for certain types of events that are of interest to users.
Any user who wants to know when these types of events occur registers with ENS,
which identifies events in order and matches notifications with subscriptions.
The user who wants to subscibe should be a valid user of the intergrated application(db, sap system etc)
The sequence of events:
Now my question is:
What is the best pracitces in storing the Users db, sap etc credentials.
EDIT
How often should the user be authenticated? Should be everytime the messages are delivered?(As @duffymo mentioned, if I use this strategy, it will affect the source system)
Additional Info: ENS are the web-services.
ENS polls the SAP(and other applications) and this is where the problem is becoming more complex.
In SAP there is data-level authorization. So not all users are allowed to see all the events/data.
If the SAP has PUSHed the data, along with the User info who has authorized to see, then no issues at all.
Case 1: Scheduler is initiated by the ENS
- User subscribes to a subscription. At the time of subscription, user is checked for his authorization in the SAP system. If OK, then he will be allowed for Subscription.
- The scheduler runs at the scheduled time.
- The scheduler identifies the users who are subscribed.
- The scheduler uses the stored credentials of the users(stroed in ENS) to POLL if the event occured.
- Notify users if there are changes.
Disadvs here:
- User credentials are stored somewhere
external - Security team might not
accept it - Reduntant hits if more than one user
is subscribed for the same piece of
information
Case 2: Scheduler is intitated by the WIDGET. User creds will be stored in the users local machine only.
Diadv:
- If the subscription is daily, and if
the user system/widget is not up. The
user might miss the notifications
that happened on say, weekends. - Reduntant hits to the server if more
than one user is subscribed for the
same piece of information.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
通常是应用程序向数据库、SAP 等提供凭据。单个用户的凭据将存储在 LDAP 或数据库中；身份验证和授权将作为应用程序、EAI 服务器或 SiteMinder 等设备的横切关注点进行处理。
传入的请求将被拦截并检查授权令牌。如果未出现令牌，请检查身份验证和授权。如果允许，创建授权令牌并缓存它。
这是 Web 应用程序的常见场景。对于像您这样的事件通知情况，情况会更复杂。当用户订阅时，您必须检查授权。如果用户未经授权，您应该立即通知他们，因为您不希望每次发布时都检查凭据。用户、订阅事件和授权凭证之间必须存在关联。
我只看到一个问题。
您可以向未经授权的用户广播事件，如果他们订阅了某个事件，发现他们已获得授权，收到第一个广播，然后由于某种原因变得未经授权。这表明您每次向订阅者广播时都必须检查凭据。这可能会变得繁重并减慢您的应用程序的速度。
查看 SAML 等标准，看看它是否可以帮助您。
缓存问题取决于事件之间的时间和授权更改之间的时间之间的比较。如果事件之间的时间间隔与授权更改相比较长，则您必须每次都进行检查，因为您无法知道自上次事件以来授权是否已被撤销。
Usually it's the application that's given credentials to the database, SAP, etc. Individual users would have credentials stored in an LDAP or database; authentication and authorization would be handled as a cross-cutting concern by the application, EAI server, or an appliance like SiteMinder.
Incoming requests would be intercepted and checked for authorization tokens. If the token doesn't appear, check for authentication and authorization. If allowed, create the authorization token and cache it.
This is the usual scenario for web applications. For an event notification situation like yours it's more complicated. You'll have to check for authorization when the user subscribes. You should notify them right away if the user is unauthorized, because you don't want to have to check credentials every time you publish. There will have to be an association between a user, a subscribed event, and the authorization credential.
I see just one problem.
You may broadcast events to an unauthorized user if they subscribe to an event, find out they are authorized, receive the first broadcast, and then become unauthorized for some reason. This suggests that you'll have to check credentials each and every time you broadcast to subscribers. This could become onerous and slow your app down.
Have a look at standards like SAML to see if it can help you.
The caching issue hinges on the comparison between the time between events and between authorization changes. If the time between events is long compared to authorization changes you have to check each time, because you have no way to know if the authorization has been rescinded since the last event.
我见过这种模式最常实现的方式是授权发生在订阅而不是后端。主题层次结构反映了后端应用程序的安全模型。如果后端有查询Producer、Deli、Grocery的功能，则存在相同分类的主题节点。在后端系统中获得 Grocery 授权的用户也获得了 Grocery 主题的授权。后端系统中的授权可以定期导出（通常是每晚）并转换为 pub/sub 代理上的授权设置。在一个实现中，我负责后端系统，将在安全管理主题上向发布/订阅代理发布授权更改，以便订阅者授权能够近乎实时地保持最新状态。
将凭证传回源系统的概念乍一看听起来很安全，但经过更深入的检查却存在一些问题。首先，您打算如何扩大规模？我从未见过一个成功的事件通知系统没有被大量重用。每个后端系统都有不同的身份验证要求，通常是不同的凭据、不同的有效性和缓存要求等。构建系统以将凭据流回几个后端应用程序是一回事。做10或20次是一场噩梦。
假设您解决了上述问题，您现在已将一半后端企业系统的用户凭据缓存在一处。如果该中央系统受到损害，那么与其通信的所有后端系统也会受到损害。该中央系统刚刚成为企业中最关键的安全焦点。解决这个问题所需的严格安全措施代价高昂。
是的，让主题树和发布/订阅代理的授权反映后端应用程序的安全模型是一件很痛苦的事情。但最终，它比设计一个足够安全的中央代理服务要容易（而且成本更低），足以存储所有凭证，并且能够跨多个后端系统验证它们，而不会导致代理或发布的源系统陷入困境。到它。
The way I've seen this pattern implemented most often is that the authorization occurs at the subscription rather than at the back end. The topic hierarchy mirrors the security model of the back-end application. If the back-end has functions for inquiring on Produce, Deli and Grocery, there exist topic nodes with the same classifications. Users who are authorized in the back end system for Grocery are also authorized to the Grocery topic. The authorizations in the back-end system can be periodically exported (frequently this is nightly) and converted to authorization settings on the pub/sub broker. In one implementation I worked on the back-end system would publish authorization changes to the pub/sub broker on a secure administrative topic so that subscriber authorizations would be kept up to date in near-real time.
The notion of passing credentials back to the source system sounds secure at first glance but on deeper inspection has some problems. First, how do you plan to scale this? I have never seen a successful event notification system that did not get heavily reused. Each back-end system will have different requirements for authentication, usually different credentials, different validity and caching requirements, etc. Building the system to flow credentials back to a couple of back-end applications is one thing. Doing it for 10 or 20 is a nightmare.
Assuming that you addressed the problems above, you now have cached user credentials for half the back end enterprise systems in one place. If that one central system is compromised, so are all the back-end systems it talks to. That central system just became the most critical security focal point in the enterprise. Serious security-fu needed to address this problem is costly.
Yes, it is a pain in the butt to make the topic tree and authorizations of the pub/sub broker mirror the security model of the back-end applications. But in the end it is a lot easier (and less costly) than designing a central broker service secure enough to store all the credentials and also capable of validating them across several back-end systems without bogging down the broker or the source systems that publish to it.
在您在问题中描述的设置中，您必须构建一种清除消息队列的方法。例如，当订阅者出现问题并停止接收消息时会发生什么，或者如果订阅主题上意外出现一些格式错误的消息并且这些消息导致接收消息的客户端崩溃，会发生什么情况。这就是为什么您的系统必须具有一些管理功能来删除消息。您可以重用此管理功能来触发从外部系统到 ENS 的用户已删除消息，此用户删除消息将导致用户通知队列被清空并且其订阅变得无效。
您可以用来处理外部系统删除用户的情况的另一件事是让来自外部系统的通知消息具有到期时间。例如，SAP 通知消息可能在创建时间后 2 小时内有效。如果用户在 2 小时内未收到消息，则该消息将被删除。如果将消息过期与来自 SAP 的用户不再有效的通知消息结合起来，那么您可以知道用户将存在一个时间限制。
我认为，如果您提供有关用于实施 ENS 的技术的更多背景信息，那么我们也许能够为您提供更具体的答案。
In the setup you describe in the question there you will have to build a way for clearing the message queues. For example what happens when a subscriber has problems and stops receiving messages, or what happens if accidentally some badly formatted messages get on the subscription topics and those messages cause the client receiving the messages for crash. This is why your system will have to have some admin functionality to delete messages. You could reuse this admin functionality to fire off a user has been deleted message from the external system to the ENS, this user deleted message would cause the users notification queue to be emptied and their subscription to become invalid.
Another thing you can use to deal with the case on the external systems deleting the user is to have notification messages from external systems have expiry times on them. For example an SAP notification message might be valid for 2 hours after creation time. If the user does not get the message in 2 hours the message is deleted. If you combine message expiry with notification messages from SAP that a user is no longer valid then you can know that there is a time limit during which a user will be invalidated.
I think if you provide more context about the technologies you are using to implement ENS then we might be able to give you more concrete answers.
LDAP 将是安全、快速和便携存储的更好选择
*编辑：在访问企业应用程序方面是可移植的。
LDAP will be a better option for storage it safe and fast and portable also
*EDIT: Portable in sense of access to your enterprise app.