Дизайн базы данных для многоуровневой авторизации Rolebased - PullRequest
Новая
       29

Дизайн базы данных для многоуровневой авторизации Rolebased

2 голосов
/ 26 октября 2011

Я разрабатываю приложение в ASP.NET Web-From, для которого требуется Multilevel авторизация и разрешение на основе ролей (операция CRUD).

Требуется авторизация пользователей при доступе к веб-формам иОперации CRUD над формами и таблицами базы данных.

Администратор приложения сможет определить, какие роли имеют доступ к определенной странице и какую операцию разрешено выполнять.

//More Info :

Я использую ASP.NET Web-Form 4.0 и Entity Framework 4.1 Database First подход.

Я знаком с членством в ASP.NET 2.0, ролями, проверкой подлинности с помощью форм.

Буду признателен за любые рекомендации или помощь в разработке базы данных.

1 Ответ

2 голосов
/ 26 октября 2011

Если я правильно понимаю, у вас будет набор пользователей (возможно, подразделенный на подмножества: каждое подмножество является группой).

Также:

  1. Пользовательвсегда является частью хотя бы одной группы
  2. Группа может быть частью другой группы
  3. Фактические списки ACL устанавливаются на уровне группы и определяются для каждой формы или таблицы.

Итак: 

    Item     Type  GroupId     C R U D
   Form001    F    ALL_USERS   N Y N N
   Form001    F    Sales       N R U N
   Form002    F    Admin       N Y Y Y
   All_FORMS  T:F  Admin       Y Y Y Y
   Tab-045A   D    Sales       Y Y Y Y

В котором говорится: Form001 - это (F) форма, и каждый может ее прочитать (но не изменять ее структуру).Пользователи из группы SALES также могут использовать форму 1 для обновления.Администраторы (группа) могут изменять, удалять или использовать форму Form002 (но не создавать ее ...). Администраторы могут создавать новые формы.Tab-045A - это таблица, записи которой могут быть созданы / использованы / изменены / удалены пользователями из группы Sales.

Несколько предостережений:

  • Пожалуйста, сделайте всем одолжение ине разрешайте устанавливать привилегии на уровне ОДНОГО ПОЛЬЗОВАТЕЛЯ, но всегда только на уровне группы.Новый пользователь автоматически становится частью ALL_USERS и может быть позже добавлен (или удален) из других групп.
  • Вероятно, лучше иметь не только таблицы и формы, но и "группы форм" (при условии, чтоформы могут быть созданы конечными пользователями).Если это не так, то поле «C» в наборе флагов CRUD становится бесполезным для форм.(Являются ли формы чем-то, что группа пользователей может спроектировать? Или они являются частью приложения, как, я полагаю, было бы в случае с таблицами?).
  • В общем случае вы должны определить подходящую семантику для Create / Read/ Update / Delete.Для таблиц я предполагаю, что это означает СОЗДАНИЕ ОДНОЙ ЗАПИСИ (не таблицы), но для форм это немного запутано в данный момент.
  • Приведенная выше таблица является лишь примером и не нормализована должным образом.В зависимости от специфики вам, возможно, придется разделить его по крайней мере на две таблицы, а возможно и больше.
  • Чтобы выяснить, может ли пользователь X выполнить операцию Y на объекте Z, вам, в основном, нужно найти набор разрешений для элемента./ Таблица групп и посмотреть, в какие группы входит пользователь X.
  • Необходимо правильно управлять случаями, когда пользователь входит в две отдельные группы, и всегда выбирать ту, которая имеет большинство разрешений, или объединение всехразрешения.
  • Вы должны управлять случаями, когда пользователь является частью группы, которая является подгруппой другой группы, и привилегии были определены в группе более высокого уровня.

Управляя группами и подгруппами, вы лучше посмотрите, какие средства существуют в вашей целевой БД для управления древовидными структурами.И вам лучше освежить тему, взглянув на несколько вопросов об этом.Вот один из них, который поможет вам начать, но он не единственный:

Как сохранить дерево в базе данных SQL

...