RavenDb 授权 +面向服务架构
我的问题是使用 RavenDb 和授权包保护跨服务的文档：
我有一个“帐户”服务，负责管理“用户”的所有内容。
我有一个“消息传递”服务，负责所有“消息传递”，即墙贴、对话等。
为了跟踪谁在该服务中做了什么，当发布新消息时，我创建消息和两个 UserProxy 对象（减少 User仅具有 UserId 和 UserName 属性的对象 - 这些对象作为子对象存储在 WallPost 文档中，因此它们本身不是文档）
当用户将某些内容发布到另一个用户墙上时，我只想允许：
- 删除/编辑原始发帖人、收件人和管理员
- 查看原始发帖人、收件人、管理员和收件人的所有朋友
我还有一个负责图像/视频的媒体服务、一个负责所有音乐事件的 MusicEvent 服务 - 他们都需要有一个类似的设置。
我的问题是：
*帐户服务是否应该存储具有角色和权限的主用户 - 当请求用户时，它可以发回具有角色和权限的 dto（可能会变得笨重）
*消息服务是否应该维护它自己的用户的副本 - 具有自己的一组角色和权限？
第一个是更简单的前进，因为它是集中的 - 但对我来说看起来有点狡猾 第二个可能更好，但是当 AccountService 更改用户名时就会出现问题 - 我可以向 esb 发送一个事件并让所有相关服务接收它并负责更新 - 但这听起来很复杂。
FTR - 我倾向于选择 2 - 非中心化方法。
The question I have is that of securing documents across services using RavenDb and the Authorization bundle:
I have an 'Account' service which is responsible for managing all things 'user'.
I have a 'Messaging' service which is responsible for all things 'messaging' i.e. wall posts, conversations etc.
To trace who did what in this service, when a new message is posted I create the message and two UserProxy objects (cut down User objects which only have UserId and UserName properties - these are stored as child objects on the WallPost doc so they aren't documents in their own right)
When a user posts something to another users wall i only want to allow:
- delete/edit to the original poster, the recipient and admins
- view to original poster, recipient, admins and all friends of the recipient
I also have a media service which is responsible for images/video, a MusicEvent service for all things music event - they all need to have a similar setup.
My question is this:
*should the account service store the master User with Roles and Permissions - when it is asked for a user it can send back a dto with the roles and permissions (could get chunky)
*should the Messaging Service maintain it's own copy of a User - with it's own set of roles and permissions?
first is simpler moving forward as it's centralised - but looks a bit dodgy to me
second is probably better but the issue comes when the AccountService changes the username - i can send an event to the esb and have all the relevant services pick it up and take care of the update - but that sounds complicated.
FTR - i'm swaying to option 2 - the non-centralised method.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
就我个人而言，我会考虑引入第三种服务 - 例如负责角色和权限的 IT/管理服务。让我印象深刻的是，这些业务功能/能力与帐户或消息服务中描述的业务功能/能力不同。负责此类功能的服务会将服务的安全方面与帐户和消息传递的实际功能区域分离。帐户仍然可以保留帐户信息的所有者。消息传递服务实际上只需要识别用户，因此在这里使用用户 ID/用户名就足够了，除非它需要其他用户信息来完成其工作（可能是电子邮件地址）。在这种情况下，只要帐户仍然是信息的所有者，就可以复制数据。
Personally, I would think about introducing a third service - e.g. IT / Administration service that would be responsible for Roles and Permissions. Its strikes me that these are different business functions / capabilities to those described in Account or Messaging services. A service responsible for that type of functionality would decouple the security aspects of your services from the actual functional areas of Accounts and Messaging. Accounts could still remain the owner of Account information. The messaging service really only needs to identify the user and so using user id / username here is sufficient, unless it nees aditional user information to do its work (email address perhaps). Its ok to duplicate data in this instance, as long as Accounts remains the owner of information.
Ayende 在他的博客上很好地回答了我的问题：
http://ayende.com/Blog/archive/2011/02/17/distributed-authorization-with-ravendb.aspx
Ayende answered this for me quite nicely on his blog:
http://ayende.com/Blog/archive/2011/02/17/distributed-authorization-with-ravendb.aspx