А как раздавать права на работу с метаданными?

Понятно что вновь создаваемые объекты регистрируются в системе и на них можно раздавать права
Я так понимаю что в системе должен быть класс Classes и у него должны быть методы Создать, Изменить, Удалить
Но таблицы Classes и др являются сами системой - как на них в таком случае раздавать права?

Forums: 

Изображение пользователя st.

Очень просто

Добавить класс "ClassSecurity", связав его с системным классом (тот, что в Classes), и раздавать права на него в обычном порядке (ACL).
Права на экземпляр соответствующего ClassSecurity будут правами "по умолчанию" на все объекты этого класса.

Немного не

Немного не понятно что и как создавать
что означает "Добавить класс "ClassSecurity", связав его с системным классом (тот, что в Classes)" ?
Я так понимаю в таблицу Classes надо добавить "ClassSecurity"
Но при создании "ClassSecurity" будут созданы таблицы и т.п., но их же не нужно создавать!

Изображение пользователя st.

Это значит

Это значит, что в таблице для объектов класса ClassSecurity будет ссылка на класс, права к которому требуется моделировать.

CREATE TABLE ClassSecurity (
ObjectID,
ClassID // ссылка на класс
)

INSERT INTO CObject (123 /* ID объекта */, 12 /* ID класса ClassSecurity */)
INSERT INTO ClassSecurity (123, 25 /* ID класса, к которому нужен доступ, например "Customer" */)

В ACL заносим доступ на чтение/запись/создание/удаление для созданного объекта ClassSecurity, соответствующего классу Customer. Это будет означать соответствующий доступ для всех экземпляров класса Customer.

Понятно....значи

Понятно....значит вы меня не поняли :)
Как дать доступ к классу Customer - мне понятно, мне непонятно как запретить/разрешить доступ к "командам" доступа/управления метаданными системы!!
Т.е. я хочу дать только аналитикам доступ к функциям управления метаданными и запретить всем остальным
Но в таблице Classes я ж не могу записать Classes - получится цикл...

Изображение пользователя st.

Для этого

Для этого используйте систему безопасности СУБД. Группа пользователей "Аналитики" будут иметь доступ к функциям управления метаданными на выполнение (grant execute), остальные - нет.

В качестве

В качестве клиента планируется использовать браузер и соответственно роли будут не SQL Server а роли в самой БД (таблица Roles, UserRoles, Users) - поэтому разраничение на уровне ролей и прав сервера не подходит (

Изображение пользователя st.

Браузер или смарт-клиент - неважно

Браузер или смарт-клиент - неважно. Вам все равно надо как-то идентифицировать соединение с одним из прикладных пользователей в Users.

Типовая схема такая. Для первичной авторизации используется соединение с минимумом прав (на чтение Users/Roles), после чего сессия использует строку соединения, назначенную данному пользователю или его группе. А она уже специфична и управляется системой безопасности СУБД. Иначе у вас будет одна большая дыра, через которую к базе данных ходят все.

вопрос спорный

вопрос спорный - откуда может возникнуть дыра если все обращения идут через среднее звено и дергаются только методы класса, которые четко разграничены по правам доступа? прямые запросы в БД - просто запрещены.
Иначе же какой смысл в объектной парадигме??

Изображение пользователя st.

Каким образом

Каким образом вы передаете контекст соединения в хранимую процедуру, если все пользователи используют один и тот же СУБДшный логин?

я передаю SID

я передаю SID юзера зашифрованный в идентификационном куке

Изображение пользователя st.

SID пользователя

SID пользователя означает, что у вас есть соответствующий ему login SQL Server. В таком случае проще открывать соединение с СУБД под профилем этого пользователя в сессии. Ну, это уже детали, а выше я написал вариант решения.

Нет - у меня custom

Нет - у меня custom авторизация - таблицы Users/UserRoles/Roles
Поэтому раздача прав на уровне login SQL невозможна, да и вопрос еще и в том что я строю и храню меню (доступные для роли классы) в БД и соответственно чтоб класс появился в меню и с ним можно было выполнять разрешенные операции в БД - должны быть права даны на этот класс -> нужно давать права на Classes, Attributes и т.д.

Изображение пользователя st.

Ладно, мы отклонились

Ладно, мы отклонились. Создайте класс ClassMeta, а в его методы вложите вызовы функции работы с таблицей Classes. Аналогично для атрибутов и связей. Классы *Meta должны быть сиглетонами, то есть создайте соответствующие объекты при инициализации и запретите пользователям их создавать. Как-то так.

В ASP.NET нельзя

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

Изображение пользователя st.

При желании

При желании все возможно. Пул соединений на 100-200-300 пользователей стоит копейки, тут даже обсуждать нечего. Одно соединение на уровне SQL занимает около 50 Кб. В пуле ADO немногим больше. При этом вы получаете в полное распоряжение уже готовую систему безопасности SQL Server/Windows.

Но как я уже сказал, мы отклонились от темы. Возможное решение вашей проблемы такое: Создайте класс ClassMeta, а в его методы вложите вызовы функции работы с таблицей Classes. Аналогично для атрибутов и связей. Классы *Meta должны быть сиглетонами, то есть создайте соответствующие объекты при инициализации и запретите пользователям их создавать.