Мы используем хранимые процедуры, чтобы ограничить доступ некоторых пользователей нашей базы данных. Им нужен доступ к определенным частям базы данных (а не только к таблицам/представлениям, но также к определенным строкам), и sproc должен проверить, разрешено ли пользователю видеть строки таблицы, которые он запрашивает.Хранение DATABASE_PRINCIPAL_ID в таблице sql server
Для сохранения правил авторизации, мы планируем использовать таблицу dbo.AuthRules
так:
|ID|UserId |AccessFrom |AccessTo | ...
===============================================
| 1| 1| 01.01.2013 | 31.12.2013 | ...
| 2| 2| 31.05.2012 | 31.12.2015 | ...
Хранимая процедура будет запросить эту таблицу, чтобы проверить, если текущий пользователь имеет доступ к запрашиваемым данным. Чтобы сделать это ясно: Мы не можем просто использовать GRANT PERMISSION
, потому что нам нужны мелкие правила доступа к строкам в БД.
Мы не уверены в колонке UserId
. Лучшим решением будет какой-то внешний ключ для системного представления sys.database_principals
, но нет внешних ключей к просмотру.
- Если мы просто хранить
principal_id
столбецsys.database_principals
, без каких-либо ограничений? - Было бы лучше хранить столбец
name
вместоprincipal_id
? - Существуют ли другие варианты хранения ссылки на пользователя БД?
Параметр 'sid' является более стабильным, чем либо имя/ID –
Но' sid' устанавливается только для пользователей Windows Auth, верно? Поэтому в случае пользователей, прошедших проверку подлинности SQL Server, нам все равно придется использовать 'ID' или' name'. – cheeesus
нет, каждый логин получает SID. Пользователи Windows получают SID, который соответствует их SID окон, тогда как логины SQL получают отдельно созданный. См. [Принципы] (http://msdn.microsoft.com/en-us/library/ms181127.aspx): «** У каждого ** принципала есть идентификатор безопасности (SID)». (Мой акцент), прежде чем он затем описывает различные типы руководителей –