Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Методы авторизации в больших системах  [new]
Stupindo
Member

Откуда:
Сообщений: 143
Есть задача - организовать систему аутентификации и авторизации пользователей, работающих с системой, которая основывается на MS SQL Server. Система большая - на данный момент даже не могу предположить сколько подсистем в ней будет.
С аутентификацией как бы всё просто - пароль, логин и вперёд. А вот с разграничением прав...
Помимо самых простых средств авторизации - есть\нету доступ на чтение\редактирование\исполнение определённых таблиц\представлений\процедур присутствуют ещё такие не совсем, на мой взгляд стандартные ограничения как горизонтальная фильтрация(видеть не все записи, а профильтрованные по каким-то полям) и такие штучки как, к примеру - просмотр всех записей, а возможность редактирования только определённых "своих" записей.
По вопросу гоизонтальной фильтрации вроде как сами собой напрашиваются представления (view), но в условиях большого количества всяческих ролей и обширности системы, представлений этих будет слишком много и плодиться будут они как кролики.
А по второму - вообще не совсем представляю как это красиво описать.

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

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

Спасибо.
12 окт 04, 11:25    [1025801]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Stupindo
По вопросу гоизонтальной фильтрации вроде как сами собой напрашиваются представления (view)


По поводу горизонтальной фильтрации действительно спасут view.
С триггерами instead of.

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


Отчего же, не обязательно их плодить для каждой роли...
Достаточно к записям цеплять права пользователей.
А как их цеплять - дело любителя.
Вот Билли Калиткин любит например ACL (такой список лиц, которым "мона"), а вот все юниксоиды легко и непринужденно обходятся фиксированным набором.
Ну, например: 4 байта - owner записи, и по 4 байта на select, modify, delete.
Итого, по 16 байт на запись.
Добавить сюда древовидную иерархию, и вполне гибкая система разграничения прав готова.

Я такое пробовал, правда в мелких масштабах (1000 записей, 10 пользователей), но все равно столкнулся с тем, что пользователи не слишком-то приспособлены к такому разграничению прав. Они откровенно недоумевали, отчего "Ваня видит, а я - нет"...


Stupindo
просмотр всех записей, а возможность редактирования только определённых "своих" записей.


Опять же, триггеры instead of вам помогут.
12 окт 04, 11:42    [1025891]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Stupindo
Может кто подскажет по-опыту - как организовать такую подсистему авторизации? Может где какая литературка есть?
Не хотелось бы изобретать велосипед.


Unix. :)
12 окт 04, 11:44    [1025900]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
Плюс я бы добавил динамическое наполнение меню и форм в зависимости от прав доступа пользователей.
По view - делается функция или view, который на основе логина пользователя показывает его права. Количество view будет определяться в данном случае не количеством ролей, а количеством объектов в системе. При том не таблиц, а сущностей.
12 окт 04, 11:47    [1025910]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Stupindo
Member

Откуда:
Сообщений: 143
А я вот думаю - может не цеплять к каждой записи дескриптор прав, а наоборот создать что-то типа таблицы прав для каждого из пользователей?
И на основе этой таблицы строить выборки и всё остальное?
Т.е., к примеру, если пользователю можно просматривать только заказы на свой товар с идентификатором 37, то при выборке через ХП этим пользователем заказов автоматом накладывается фильтр на запрос что-то типа "product_id = 37"
12 окт 04, 12:43    [1026190]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
andsm
Member

Откуда: Москва
Сообщений: 1315
Блог
Сервер приложений очень удобно использовать когда есть сложные требования к системе разграничения доступа.
12 окт 04, 13:10    [1026374]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
Stupindo
А я вот думаю - может не цеплять к каждой записи дескриптор прав, а наоборот создать что-то типа таблицы прав для каждого из пользователей?
И на основе этой таблицы строить выборки и всё остальное?


Именно так и нужно. Т.е. права пользователя относятся к объекту "Пользователь"...
12 окт 04, 13:16    [1026406]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Breakneck
Stupindo
А я вот думаю - может не цеплять к каждой записи дескриптор прав, а наоборот создать что-то типа таблицы прав для каждого из пользователей?
И на основе этой таблицы строить выборки и всё остальное?


Именно так и нужно. Т.е. права пользователя относятся к объекту "Пользователь"...


Не очень эффективно.
Вернее, эффективно для объектов типа "глобальные права доступа к меню".
Дык, такие объекты есть во всех системах.
Но никто не отменял при этом права на конкретный объект.
А если эти права цепляются не на сам объект, а на пользователя (прописываются в отдельную, ассоциированную с пользователем таблицу), то...

Вы хотя бы себе в таком случае представьте скрипт для удаления записи из таблицы...
12 окт 04, 13:28    [1026449]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Лео
Member

Откуда: Москва
Сообщений: 207
Breakneck
Именно так и нужно. Т.е. права пользователя относятся к объекту "Пользователь"...

Мне кажется верным. Имя пользователя можно определить из ф-ции, а в связанной таблице держать набор правил, приемлимых для объединения с данными, допустим список отделов или счетов или и того и другого. В зависимости от задачи.
12 окт 04, 13:46    [1026535]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
Makar4ik
Но никто не отменял при этом права на конкретный объект.
А если эти права цепляются не на сам объект, а на пользователя (прописываются в отдельную, ассоциированную с пользователем таблицу), то...
Вы хотя бы себе в таком случае представьте скрипт для удаления записи из таблицы...


Когда есть несколько сотен пользователей + более сотни ролей/групп, весьма невыгодно к каждой записи прицеплять права доступа к ней. Тем более, если права доступа для группы записей абсолютно одинаковы.
В Вашем-то случае нарушаются требования нормализации, что приводит к серьезной избыточности.
Куда как проще и выгоднее хранить права доступа к классам, группам и срезам. И вдобавок хранить права доступа к самим объектам. Но отдельно от объектов. В таком случае получится нормализованная структура, которая очень легко оптимизируется и очень удобно администрируется.
12 окт 04, 14:19    [1026725]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Breakneck
Когда есть несколько сотен пользователей + более сотни ролей/групп, весьма невыгодно к каждой записи прицеплять права доступа к ней. Тем более, если права доступа для группы записей абсолютно одинаковы.
В Вашем-то случае нарушаются требования нормализации, что приводит к серьезной избыточности.
Куда как проще и выгоднее хранить права доступа к классам, группам и срезам. И вдобавок хранить права доступа к самим объектам. Но отдельно от объектов. В таком случае получится нормализованная структура, которая очень легко оптимизируется и очень удобно администрируется.


Дано: 500 пользователей и групп, 1000000 записей в 30 таблицах.
Каждый пользователь или группа имеет доступ к некоторой части записей из базы.

Задача: Выяснить, к чему эффективнее цеплять секьюрити: к записи (аналог unix) или к пользователю/группе (аналог виндовых ACL).
В случаях, когда у каждого пользователя есть доступ к: a) 1% записей б) 20% записей в) 80% записей

Вот и посчитайте, сколько места займет к 500 пользователям прицепить ссылки даже на 1% записей.
И что дешевле, 1 раз 100%, или 500 раз по 1%, да еще и умножая сущности при этом!

А про нормализацию - пожалуйста поподробнее.
Какую нормальную форму вы в виду имели?
Первую? Третью? BCNF? PJ/NF?
12 окт 04, 14:43    [1026833]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Да, вот еще:
Есть высокая вероятность того, что при использовании аналога ACL на любой доступ к записи прав не будет НИ У КОГО.
А при полях, ссылающихся на группу/пользователя такого RI не допустит.
12 окт 04, 14:48    [1026855]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
Makar4ik
Дано: 500 пользователей и групп, 1000000 записей в 30 таблицах. Каждый пользователь или группа имеет доступ к некоторой части записей из базы. Задача: Выяснить, к чему эффективнее цеплять секьюрити: к записи (аналог unix) или к пользователю/группе (аналог виндовых ACL).
В случаях, когда у каждого пользователя есть доступ к: a) 1% записей б) 20% записей в) 80% записей Вот и посчитайте, сколько места займет к 500 пользователям прицепить ссылки даже на 1% записей. И что дешевле, 1 раз 100%, или 500 раз по 1%, да еще и умножая сущности при этом!

А Вы обратили внимание, что я предлагал в первую очередь управление правами доступа к классам, группам и срезам. А к конкретным объектам предоставлять отдельные, независимые от классов права доступа только при необходимости. В результате получается схема, когда большинство записей имеет в правах доступа одну группу (в лучшем случае, несколько).
По моему опыту, таким образом построенная система доступа имеет намного большую эффективность из-за:
1. Простота разработки (механизм управления правами реализован независимо от объектов, вследствие чего достаточно при вставке/модификации/удалении присоединять view с правами доступа, нежели контролировать для каждой записи, участвующей в операции, права доступа).
2. Объем хранения (при хорошо продуманной структуре групп, классов и срезов объем информации о правах доступа невысок. Ведь гораздо проще группе предоставить доступ к диапазону записей, нежели в каждой прописывать одну и ту же группу).
3. Гибкость администрирования. Работа с правами доступа не затрагивает объекты, вся информация о правах доступа сосредоточена в одном хранилище, изменение механизма (добавление вида права, группы) также не затрагивает объекты непосредственно.
12 окт 04, 15:46    [1027154]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
andsm
Member

Откуда: Москва
Сообщений: 1315
Блог
У меня при ~10000 пользователях, при довольно сложной схеме прав, места для хранения информации о правах уходит совсем немного.
12 окт 04, 15:52    [1027179]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
andsm
У меня при ~10000 пользователях, при довольно сложной схеме прав, места для хранения информации о правах уходит совсем немного.

А у Вас какая методика?
12 окт 04, 15:53    [1027186]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Stupindo
Member

Откуда:
Сообщений: 143
andsm
Сервер приложений очень удобно использовать когда есть сложные требования к системе разграничения доступа.


Ну, вот с двумя подходами разграничения прав с помощью сервера БД я приблизительно понял и даже начал представлять какие минусы у каждого из них. И мне, кстати, больше нравится способ аналог АСL.
А как это можно эффективно сделать с помощью сервера приложений?
12 окт 04, 16:27    [1027374]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Breakneck
А Вы обратили внимание, что я предлагал в первую очередь управление правами доступа к классам, группам и срезам.


Угу. И это называется "множить сущности". А про лезвие Оккама слыхали?

А что такое классы, группы и срезы?
Типа
select * from objects where class = 11
???
Дык! Если мне не хочется прописывать объектам права, а только классам, то
select * from objects where class in (select class from ClassView where class = 11)

Breakneck
А к конкретным объектам предоставлять отдельные, независимые от классов права доступа только при необходимости.


Типа: 3 записи скрыть от всех, 15 выдать ТОЛЬКО вот этим вот, а остальные - удаляйте и меняйте, кто хочет!
Да, есть и такие подходы к решению задач по безопасности.
Ноги вытирать будем при входе в дом, вот пылесосить и необязательно будет...

Breakneck

В результате получается схема, когда большинство записей имеет в правах доступа одну группу (в лучшем случае, несколько).


Угу. А я предлагал, чтобы ВСЕ записи имели по 2 группы в правах.
Хозяина, и
Unix до сих пор живет с такой схемой защиты файлов, и ни кого это не напрягает.

Breakneck

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



Куда уж проще:
4 лишних поля у таблицы
ACLOwnerID int -- группа или юзер - хозяин записи, все права
ACLGroupID int -- группа или юзер, права которой указаны дополнительно
ACLGroupRights tinyint -- права группы ACLGroupID, bitmask 1-й бит - чтение, 2-update, 3-delete, 4-change rights, 5..7- свободны
ACLAllRights tinyint -- права всех остальных, bitmask

Итого, 10 байтов довесок.
А выбрать можно так:

CREATE VIEW dbo.VControlRoot
AS
SELECT     ID, ...................., ACLOwnerID, ACLGroupID, ACLGroupRights, ACLAllRights
FROM         dbo.TabControlRoot
WHERE     (ACLAllRights & 1 = 1) OR
                      (ACLOwnerID IN
                          (SELECT     GroupID
                            FROM          TGroupHint
                            WHERE      UserID =
                                                       (SELECT     ID
                                                         FROM          TUsers
                                                         WHERE      login = CURRENT_USER))) OR
                      (ACLGroupID IN
                          (SELECT     GroupID
                            FROM          TGroupHint
                            WHERE      userID =
                                                       (SELECT     ID
                                                         FROM          TUsers
                                                         WHERE      login = CURRENT_USER))) AND (ACLGroupRights & 1 = 1)

Breakneck

2. Объем хранения (при хорошо продуманной структуре групп, классов и срезов объем информации о правах доступа невысок. Ведь гораздо проще группе предоставить доступ к диапазону записей, нежели в каждой прописывать одну и ту же группу).


Ну тогда вешайте такую вьюху на подобную же, отвечающую за группу.
И будет вам то же самое разграничение.

CREATE VIEW dbo.VControlRoot
AS
select * from TabControlRoot, VControlGRP where TabControlRoot.GRP = VControlGRP.GRP

В чем проблема-то?

Breakneck

3. Гибкость администрирования. Работа с правами доступа не затрагивает объекты, вся информация о правах доступа сосредоточена в одном хранилище, изменение механизма (добавление вида права, группы) также не затрагивает объекты непосредственно.


В данном случае, под понятием "Гибкость администрирования" подразумевается "подобность Майкрософту"? Ну живут же как-то мэйнфреймы с десятками тысяч пользователей, и администраторы как-то под юниксом справляются с работой...
12 окт 04, 16:31    [1027399]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Stupindo
Member

Откуда:
Сообщений: 143
[quot Makar4ik]
Дано: 500 пользователей и групп, 1000000 записей в 30 таблицах.
Каждый пользователь или группа имеет доступ к некоторой части записей из базы.
[quot]

А можно пример? Вот есть у нас табличка:
CREATE TABLE t1(
id int,
name nvarchar(256)
)

Какие поля надо к ней добавить, чтоб разграничить доступ пользователям vasya, kolya?
12 окт 04, 16:34    [1027411]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
Stupindo
И мне, кстати, больше нравится способ аналог АСL.
А как это можно эффективно сделать с помощью сервера приложений?

У меня во всех системах распределение прав доступа возложено на сервер БД. Сформирован ряд функций и view, которые выдают права пользователя и которые при работе просто подключаются к рабочим таблицам join'ами.

Кстати, ACL подход (будем уже называть его так) выгоднее в случаях:
1. Когда нужно хранить историю об изменении прав доступа.
2. Когда необходимо вести отложенное изменение прав доступа (на будущее - с определенного момента).

2Makar4ik:
А эффективная система безопасности строится по принципу "запрещено все, что явно не разрешено". Т.е. вариант "Типа: 3 записи скрыть от всех, 15 выдать ТОЛЬКО вот этим вот, а остальные - удаляйте и меняйте, кто хочет!" не пройдет by design.
12 окт 04, 16:40    [1027447]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Stupindo
Member

Откуда:
Сообщений: 143
Stupindo
[quot Makar4ik]
Дано: 500 пользователей и групп, 1000000 записей в 30 таблицах.
Каждый пользователь или группа имеет доступ к некоторой части записей из базы.
[quot]

А можно пример? Вот есть у нас табличка:
CREATE TABLE t1(
id int,
name nvarchar(256)
)

Какие поля надо к ней добавить, чтоб разграничить доступ пользователям vasya, kolya?


А, понятно, ответ уже выше.
12 окт 04, 16:41    [1027452]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Breakneck
вся информация о правах доступа сосредоточена в одном хранилище


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

Breakneck
изменение механизма (добавление вида права, группы) также не затрагивает объекты непосредственно.


Добавление вида права?
Я правильно понял, что вы хотите наложить объектную модель на реляционную структуру? Или вы сами себе, как разработчику прощаете то, что сели за проектирование без надлежащей постановки задачи?
12 окт 04, 16:42    [1027457]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Stupindo

А можно пример? Вот есть у нас табличка:
CREATE TABLE t1(
id int,
name nvarchar(256)
)

Какие поля надо к ней добавить, чтоб разграничить доступ пользователям vasya, kolya?


см. выше, там вьюха.
12 окт 04, 16:43    [1027467]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Breakneck
Member

Откуда: Kiev
Сообщений: 2454
[quot Makar4ik]И это называется "множить сущности".[quot]

Это не есть множение сущностей.
1. Под классом я понимаю группу объектов (Вам их тоже придется использовать для определения прав доступа).
2. Под группой я понимаю группу пользователей (опять-таки, у Вас они используются).
3. Под срезом понимается горизонтальное деление.
12 окт 04, 16:45    [1027480]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
Stupindo
Какие поля надо к ней добавить, чтоб разграничить доступ пользователям vasya, kolya?


Прошу прощения.

Там таблица есть TGroupHint.
Это табличка - хинт, которая перечисляет все группы всех юзеров.
Правится триггером при каждом добавлении/удалении юзера/группы.

Чтобы не прыгать каждый раз по всей иерархии прав.
12 окт 04, 16:47    [1027487]     Ответить | Цитировать Сообщить модератору
 Re: Методы авторизации в больших системах  [new]
Stupindo
Member

Откуда:
Сообщений: 143
Breakneck

У меня во всех системах распределение прав доступа возложено на сервер БД. Сформирован ряд функций и view, которые выдают права пользователя и
которые при работе просто подключаются к рабочим таблицам join'ами.


Да именно так я и подумал.
Но меня ещё беспокоит - не будут ли эти джойны сильно напрягать\усложнять выборки. Понятно, что в единичном варианте они не заметны, но при массовости количества пользователей к каждому запросу приклеить этот искусственный джойн...

Breakneck

Кстати, ACL подход (будем уже называть его так) выгоднее в случаях:
1. Когда нужно хранить историю об изменении прав доступа.
2. Когда необходимо вести отложенное изменение прав доступа (на будущее - с определенного момента).


Ну да. Тут можно наворачивать, по идее всё что угодно.

Кстати, я вот как бы идеологически проникся, а как это на практике выглядет будет ещё не вырисовалось. Мож покажете маленький пример фильтрации по правам? Чисто намётку, плз.
12 окт 04, 16:49    [1027504]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить