【问题标题】:RavenDb Authorization + SOARavenDb 授权 + SOA
【发布时间】:2011-02-17 08:15:34
【问题描述】:

我的问题是使用 RavenDb 和授权包保护跨服务的文档:

我有一个“帐户”服务,负责管理所有“用户”。

我有一个“消息”服务,负责所有“消息”,即墙帖、对话等。

为了跟踪谁在此服务中做了什么,当发布一条新消息时,我创建了消息和两个 UserProxy 对象(削减了只有 UserId 和 UserName 属性的用户对象 - 这些作为子对象存储在 WallPost 文档中,所以它们本身不是文档)

当用户向另一个用户墙发布内容时,我只想允许:

  • 删除/编辑原始发帖人、收件人和管理员
  • 查看原始发帖人、收件人、管理员和收件人的所有朋友

我还有一个负责图像/视频的媒体服务,一个用于所有音乐事件的 MusicEvent 服务 - 它们都需要有类似的设置。

我的问题是这样的:

*帐户服务是否应该存储具有角色和权限的主用户 - 当它被要求提供用户时,它可以发送回具有角色和权限的 dto(可能会变得笨拙)

*消息服务是否应该维护它自己的用户副本 - 拥有自己的一组角色和权限?

first 更简单,因为它是集中式的 - 但对我来说看起来有点狡猾 第二个可能更好,但是当 AccountService 更改用户名时问题就来了——我可以向 esb 发送一个事件并让所有相关服务接收它并处理更新——但这听起来很复杂。

FTR - 我倾向于选项 2 - 非集中式方法。

【问题讨论】:

    标签: authorization soa ravendb


    【解决方案1】:

    就个人而言,我会考虑引入第三种服务 - 例如。负责角色和权限的 IT / 管理服务。令我震惊的是,这些业务功能/功能与帐户或消息服务中描述的业务功能/功能不同。负责此类功能的服务会将您的服务的安全方面与帐户和消息传递的实际功能区域分离。帐户仍然是帐户信息的所有者。消息服务实际上只需要识别用户,因此在这里使用用户 ID/用户名就足够了,除非它需要额外的用户信息来完成工作(可能是电子邮件地址)。在这种情况下复制数据是可以的,只要 Accounts 仍然是信息的所有者。

    【讨论】:

      【解决方案2】:

      Ayende 在他的博客上很好地回答了我这个问题:

      http://ayende.com/Blog/archive/2011/02/17/distributed-authorization-with-ravendb.aspx

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2023-03-26
        相关资源
        最近更新 更多