Хранение информации о правах доступа

[MIT]

Нужно организовать гибкую систему членства на основе MSSQL базы (2008). Схема следующая: есть пользователь, есть группа, к которой этот пользователь принадлежит, а у группы есть права (на доступ, на действие и т.п.).
Каким образом это лучше хранить в базе? Если с пользователями и группами все понятно - данные пользователя содержат индекс группы, то как лучше всего хранить права, с учетом того, что количество прав и групп не будет фиксированным (т.е. ни под права, ни под группы выделять столбцы таблицы неприемлимо)?

Вспоминается моя предыдущая тема в этом разделе с аналогичным вопросом, но может есть что-то лучшее...

[iGrok]

Вытащено из BackEndPro (надстройки над php-фреймворком CodeIgniter).

Таблица юзеров.
Таблица групп.
Таблица ресурсов к которым предоставляется доступ.
Таблица разрешений(троек группа - ресурс - действие(разрешить или запретить)).

Там ещё есть таблица возможных действий и таблица разрешения действий, примерно по тому же принципу.

Оптимизировать по вкусу.

[Roman Koff]

А стандартный механизм asp.net авторизации не подходит?

[SLIM]

Как вариант, слышал что MS SQL работает с XML неплохо.
Но, в MS SQL и так гибкий механизм контроля прав доступа. Не знаю как в 2008, но в 2000 точно, а значит и в 2008 тоже.
Там также пользователи объединены в группы и т.д. И права у них разные.

[MIT]

Там ещё есть таблица возможных действий и таблица разрешения действий, примерно по тому же принципу.

А можешь пояснить что это такое и зачем нужно?

А стандартный механизм asp.net авторизации не подходит?

Не очень: система авторизации должна работать на нескольких доменах, а каждый отдельный сайт работает на веб-ферме, что добавляет некоторые сложности в настройке.

Но, в MS SQL и так гибкий механизм контроля прав доступа.

Я довольно поверхностно знаю возможности MSSQL сервера, посему пока не будем трогать данный механизм. (Сейчас изучаю умную книжку по нему, может что и вычитаю хорошего.)

[iGrok]

Там ещё есть таблица возможных действий и таблица разрешения действий, примерно по тому же принципу.

А можешь пояснить что это такое и зачем нужно?

Я ей толком не пользовался, ибо оно было криво реализовано, и не работало, а мне было без надобности, так что "чинить" не стал. )

Вкратце, это в целом была админка сайта.
Ресурсами задавались адреса страниц, доступом к которым надо было управлять.
Действиями задавались возможные действия (создание, изменение, редактирование, модерация, удаление, и т.п.).

В табличке с доступом к действиям указывался ID из таблички с разрешениями на ресурсы, и ID действия.
Т.е. разрешённые или запрещённые действия можно было задавать для конкретной пары группа-ресурс.

Структура получается громоздкая, но достаточно гибкая.
Мне эти "действия" были нафиг не нужны, я ограничился ресурсами. )

[ANDLL]

Ну а в чем проблема
Таблица действий
Таблица объектов
Таблица макеров пользователей(пользователи, группы и что там еще)
И таблица в которой ссылки на все три и плюс еще битовое поле - разрешение, запрет.
Если без наследования - то вытягивается элементарным запросом, имеющим логарифмическую сложность при правильно проставленых индексах.
Да и при чем тут авторизация и права доступа - это разные вещи(совсем)

[FireFenix]

Там ещё есть таблица возможных действий и таблица разрешения действий, примерно по тому же принципу.

А можешь пояснить что это такое и зачем нужно?

Если нужно базовую систему прав, то можно юезр-таблице сделать поле access int, где числовое поле означет уровень прав и проверяешь типа if access < 50 then show()

Если же нужно контролить каждое дыхание юзера отдельно, то лучше заводить отдельную БД для каждого действия c полями типа
int(11) - id_user
bool - can_write
bool - can_read
bool - car_update
потом при авторизации лефтджоинишь к юзеру по ид и при каждой действии проверяешь нужное поле, типа IF user("can_write") = True Then Write()

[MIT]

Да и при чем тут авторизация и права доступа - это разные вещи(совсем)

В ASP.NET есть стандартный membership-функционал, который довольно тесно связан с авторизацией, реализованной, опять же, стандартными методами. От стандартной авторизации я отказался давно, систему членства также хотелось бы свою.

Таблица действий
Таблица объектов

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

лучше заводить отдельную БД для каждого действия

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

[VVitafresh]

Да и при чем тут авторизация и права доступа - это разные вещи(совсем)

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

[iGrok]

Да и при чем тут авторизация и права доступа - это разные вещи(совсем)

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

Нет.
Авторизация - это подтверждение подлинности пользователя.
А права доступа - это права доступа.

[VVitafresh]

Нет.
Авторизация - это подтверждение подлинности пользователя.
А права доступа - это права доступа.

Я думаю тут какая-то путаница между авторизацией и аутентификацией. Вообще-то подтверждение подлинности пользователя -- это аутентификация.

Authentication

Authentication is the process of obtaining identification credentials such as name and password from a user and validating those credentials against some authority. If the credentials are valid, the entity that submitted the credentials is considered an authenticated identity. Once an identity has been authenticated, the authorization process determines whether that identity has access to a given resource.

Authorization

Authorization determines whether an identity should be granted access to a specific resource.

[iGrok]

Тьфу-ты блин. А ведь точно. )

[ANDLL]

Ага, я то же спутал