RavenDb Авторизация + SOA - PullRequest
0 голосов
/ 17 февраля 2011

Вопрос, который у меня возникает, заключается в защите документов между службами с использованием RavenDb и пакета авторизации:

У меня есть служба «Учетная запись», которая отвечает за управление всеми вещами «пользователь».

У меня есть служба «Сообщения», которая отвечает за все «сообщения», то есть сообщения на стене, разговоры и т. Д.

Чтобы отследить, кто чем занимался в этой службе, при публикации нового сообщения я создаю сообщение идва объекта UserProxy (вырезать объекты User, которые имеют только свойства UserId и UserName - они хранятся как дочерние объекты в документе WallPost, поэтому они не являются документами сами по себе)

Когда пользователь отправляет что-то другомуСтена пользователя. Я хочу разрешить только:

  • удаление / редактирование исходного постера, получателя и администраторов
  • просмотр исходного постера, получателя, администраторов и всех друзей получателя

У меня также есть медиа-сервис, который отвечает за изображения / видео, сервис MusicEvent для всехмузыкальное событие hings - все они должны иметь одинаковую настройку.

Мой вопрос такой:

* если служба учетных записей хранит главного пользователя с ролями и разрешениями - когда его просятпользователь может отправлять обратно dto с ролями и разрешениями (может стать коротким)

* должна ли Служба сообщений поддерживать свою собственную копию пользователя - со своим собственным набором ролей и разрешений?

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

FTR - я покажу вариант 2 - нецентрализованный метод.

Ответы [ 2 ]

0 голосов
/ 02 марта 2011

Айенде очень хорошо ответил на это в своем блоге:

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

0 голосов
/ 21 февраля 2011

Лично я бы подумал о введении третьего сервиса - например, ИТ / администрация службы, которая будет отвечать за роли и разрешения. Меня поражает, что это бизнес-функции / возможности, отличные от описанных в службах учетных записей или обмена сообщениями. Служба, отвечающая за этот тип функциональности, будет отделять аспекты безопасности ваших служб от реальных функциональных областей учетных записей и обмена сообщениями. Учетные записи все еще могут оставаться владельцем информации об Учетной записи. Службе обмена сообщениями действительно нужно только идентифицировать пользователя, и поэтому достаточно использовать идентификатор пользователя / имя пользователя, если только для этого не нужна дополнительная информация о пользователе (возможно, адрес электронной почты). В этом случае вполне допустимо дублировать данные, пока учетная запись остается владельцем информации.

...