Mainframe_старыйДавно пора в вузах ввести курс - управления правами доступа.
Хм. Неужели изложение мысли "не изобретай велосипед" должно занимать целый семестр? Имхо тех, для кого оно так, лучше сразу пристрелить, дабы других не мучали....

Mainframe_старыйПолучилось неплохо, местами даже лучше, чем в классике, но возможно за это время мы могли бы сделать еще кое-что полезное.
Делать именно RBAC или нечто очень похожее имхо неоправданно - согласен, лучше потратить это время на что-нибудь полезное. Имхо свою безопасность имеет смысл делать ради какой-то другой либо другой идеологии защиты, той же мандатной. Скажем, я имел дело с одной интересной собственной системой безопасности; там идеология была кардинально расширена за счет следующих моментов:

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

2. Permission-ы были параметризованными. То есть, например, операция "выписать подарок клиенту". Для продавца лимит цены подарка установлен в 20 у.е., для ведущего продавца - в 100 у.е. Соответственно, подарки в пределах лимита сотрудник выписывает под собственную ответственность; при превышении лимита запрашивается разрешение начальника отдела.

LSVРазделять доступ к данным в полной мере не получится, т.к. далеко не вся логика укладывается в права чтения/записи определенной таблицы. Всё равно неизбежно использование мер безопасности на клиенте.
Хм. Странное утверждение.

1. Меры безопасности на клиенте - это моветон, заведомая "защита только от неграмотного пользователя". Клиент должен поддерживать меры безопасности сервера - скажем, прятать от пользователя пункты меню, вызывающие те операции, на которые у пользователя нет прав. Прятать колонки, значения которых безопасность все равно забивает null-ами. И так далее.

2. Насчет "неизбежно".... Вы имхо очень преувеличили. Я бы сказал, большинство приложений таки избегают.

Как запретить пользователю менять данные в док-те с определенным статусом ?
Триггер.

Как запретить менять(видеть) конкретное поле ?
Триггер (view).

Как запретить ставить определенные значения ?
Триггер.

Как запретить менять(видеть) определенные записи ?
Триггер (view).

Единственный выход для хорошей безопасности - всё делать через хранимые процедуры.
Но там появится масса других проблем.
И это тоже вариант. В MSSQL, кстати, в этом плане хороша концепция inline table function (хотя я и продолжаю считать, что их следовало бы назвать параметризованными view).

Авторизатор- Программа в общем случае представляет набор форм которые работают к таблицами БД (MSSQL2к).
- Собственно разрешение на запуск формы и лимитирует пользователей в правах.
Этого как правило недостаточно - как правило, требуется выдавать права на отдельные операции на форме (точнее - оказывается слишком неудобным делать свою форму под каждую операцию, нуждающуюся в автономной выдаче прав). Даже если сейчас это устраивает, серьезно подумайте, сохранится ли такая ситуация в будущем.

Ну а теперь: исходя из этого, получаем следующее:

1. В БД создается набор ролей, соответствующий формам (либо роль для каждой формы, либо объединенные роли для нескольких форм с заведомо одинаковыми правами)

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

3. Форма знает свою роль и так или иначе отказывается вызываться, если у пользователя роли нет.

Вот и все. Дешево, просто и без извратов получаем неплохо защищенную систему; администратору остается только вовремя применять патчи безопасности сервера.

Mainframe_старыйА не пробовали делать Пермишины на максимальное в единый момент времени число пользователей ? меня в веб-приложениях это сильно смущает, не уверена, что стоит ломать копья. Лучше на организационном уровне договариваться.
Делал когда-то ограничение на максимальное количество сессий одного пользователя. Но такие лимиты сейчас как правило спокойно поддерживаются серверным софтом, на уровне приложения вроде ни к чему.

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

Shtock Никаким грантом Вы не пропасете сумму. А в триггере-это уже что-то писать надо. Разговор шел именно об этом!
Не совсем так, или даже совсем не так.

Говоря формально, LSV выдвинул утверждение, состоящее из верной посылки (I), ложной посылки (II), доказательства и вывода. Я подбросил ему примеров, показывающих ложность посылки II и соответственно вывода. Вы же пытаетесь объяснить мне, что посылка I истинна, и "разговор шел именно об этом".

Bibber8. коннект от SQL-пользователя к БД возможно осуществить только из приложения (так как никто кроме него не умеет расшифровывать пароль).