Архитектура ACL для программного обеспечения как службы в Spring 3.0 - PullRequest
Новая
       23

Архитектура ACL для программного обеспечения как службы в Spring 3.0

2 голосов
/ 12 марта 2010

Я создаю программное обеспечение как сервис, используя Spring 3.0 (Spring MVC, Spring Security, Spring Roo, Hibernate)

Я должен придумать механизм гибкого списка контроля доступа. У меня есть три разных типа пользователей

  • Система (которая может делать с системой все, включая администраторов и внутренних демонов)
  • Операции (кто может добавлять и удалять пользователей, организации и выполнять работы по обслуживанию от имени пользователей и организаций)
  • Конечные пользователи (они принадлежат одной или нескольким организациям, для каждой организации пользователь может иметь одну или несколько ролей, например, быть администратором организации или участником организации только для чтения) (роль типа orgadmin также может добавлять пользователей для этой организации)

Теперь мой вопрос: как мне смоделировать сущность пользователя?

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

Так, например, пользовательский UX принадлежит организациям og1, og2 и og3, а для og1 он является orgadmin и org-read-only-user, где для og2 он только orgadmin, а для og3 он только org- только для чтения пользователь

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

Если у вас есть лучшая расширяемая архитектура ACL, предложите ее. Поскольку это программное обеспечение как услуга, можно было бы ожидать, что множество разных организаций будет частью одной и той же системы. У меня было одно опасение, что не стоит хранить данные og1 и og2 в одной и той же БД (если og1 решит создать 100 отчетов в системе, og2 не должен страдать). непосредственно связанные с ACL, но с физическим распределением данных и настройкой служб на основе этих ACL

Это вопрос Wiki сообщества, пожалуйста, исправьте все, что вы хотите сделать. Спасибо

1 Ответ

2 голосов
/ 30 июля 2010

Нет ничего плохого в том, что один пользователь может принадлежать к нескольким организациям, и он / она может иметь несколько ролей в одной организации. В типичной модели управления доступом на основе ролей у вас могут быть группы. А роли могут быть глобальной (например, системным администратором) или быть эффективными только внутри группы. Вы защищенные элементы данных должны быть соответственно разделены на группы. Когда пользователь получает доступ к одной группе данных, вы сначала проверите, имеет ли он / она права на эту группу. Затем загрузите его / ее права для этой группы. Это трудно сделать с помощью Spring Security Acl, если вы не расширяете его с помощью собственной службы aclservice. Это похоже на проблему производительности весеннего фильтра acl. В конце концов вам придется подключить часть вашей безопасности к вашей бизнес-логике, так или иначе.

...