Как назначить роли членства .net отдельным записям базы данных

Question

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

например. У меня есть столик под названием EventType (ID, EventTypeDescription) который содержит следующие записи:

1, 'Basic Event'
2, 'Intermediate Event'
3, 'Admin Event'

Что мне нужно сделать, так это отфильтровать возвращенные записи на основе имени пользователя (и, следовательно, роли) вошедшего в систему пользователя. например, если опытный пользователь вошел в систему, он увидит все типы событий, если стандартный пользователь вошел в систему, он увидит только основной тип события и т. д.

В идеале, я хотел бы сделать это таким образом, чтобы при необходимости его можно было легко распространить на другие таблицы. Поэтому я хотел бы избежать простого добавления поля «Роли» в каждую таблицу, где данные чувствительны к пользовательскому контексту.

Одна идея, о которой я думаю, - это создать некую таблицу разрешений, такую ​​как:

PermissionsTable
(
  ID,
  Aspnet_RoleId,
  TableName,
  PrimaryKeyValue
)

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

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

TableNames
(
  ID,
  TableName
)

UserPermissionsTable
(
  ID,
  Aspnet_UserId,
  TableID,
  PrimaryKeyValue
)

Answer 1

Я делал нечто подобное, когда создавал CMS ...

По сути, я создал несколько таблиц в БД: пользователей Роли UsersInRoles Объекты ObjectPermissions

Хорошо, это работает примерно так ...

Первые 3 довольно понятны, пользователи, роли и связи между ними. Пользователю предоставляются разрешения в зависимости от его членства в ролях.

Следующее, что я делаю, это определяю «объекты», которым я хочу управлять разрешениями и уровнями разрешений, которым я хочу их назначить ...

Таким образом, объекты содержат список определений объектов, которые затем расширяются в других таблицах, связанных идентификатором объекта, и таблица ObjectPermissions в основном связывает объект с ролью.

Теперь, возможно, стоит объяснить кое-что о ролях ...

Роль, как я понимаю, это список разрешений, не более и не менее.

Итак, если я создаю роль с именем guest и устанавливаю роль разрешения на чтение, то создаю роль с именем admin, у которой есть глобальные права делать все, что я могу, затем сделать что-то вроде этого ...

Добавить пользователя 1 роль администратора. Добавить объект 1 в роль администратора.

Пользователь 1 теперь будет иметь полный доступ к объекту 1, и здесь важно то, что разрешения наследуются, поэтому любые дочерние объекты (например, разрешения для файлов и папок) также будут иметь одинаковый набор ролей, если не будут рекурсивно переопределены.

поэтому по умолчанию я назначаю объект корневого уровня каждой ключевой системной роли. Затем я выборочно добавляю пользователей к различным ролям в разных точках дерева.

Имеет ли это смысл?

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

Теперь нужно кое-что отметить по этому поводу ...

Если бы я хотел, чтобы у пользователя были права администратора для глубоко вложенного объекта, но не на корневом уровне, мне пришлось бы создать новую роль, которая предоставляет все разрешения, и добавить к ней как пользователя, так и объект.

Причина в том, что если бы я добавил пользователя в основную роль администратора, ему бы были предоставлены эти права от корневого уровня, а не от моего вложенного объекта.

это больше, чем это, но, по сути, именно так работают разрешения файловой системы.

Answer 2

Мы делаем что-то похожее. Нашим решением было использовать табличную функцию для объединения. то есть.

выбрать * из событий e внутреннее соединение [dbo] .fn_AvailableEvents (@User_ID) a на e.id = a.id

функция возвращает только идентификатор события, которое пользователь может видеть.

Answer 3

Даже если вы им не пользуетесь, это позор, но вы, по крайней мере, можете узнать все тонкости концепции из Rhino.Security .

Answer 4

Вы не упоминаете, какую (если есть) базу данных, которую используете, но при условии использования SQL Server, тогда, если вы подключаетесь с использованием аутентификации Windows, вы можете создать представления или хранимые процедуры, которые фильтруют данные на основе SYSTEM_USER * 1002. * функция.