Дано: пользователи, группы пользователей, права доступа, роли пользователей.
Группы могут включать пользователей и другие группы. Группа может быть включена в несколько групп, лишь бы не было циклов.
Права доступа объединяются в роли.
Группам, но не пользователям, назначаются роли.
Проверка наличия права доступа у пользователя выглядит как:
Есть ли среди всех групп пользователей, в которые входит данный пользователь прямо или косвенно те, которым назначена роль разрешающая право доступа одновременно с отсутствием групп пользователей, в которые входит данный пользователь прямо или косвенно, у которых назначена роль запрещающая право доступа?
Проблема в том, что группы и пользователи могут быть по отношению к системе внешние (например, из Active Directory или любого другого LDAP-каталога), а права доступа и роли пользователей тоже необходимо иметь возможность хранить по-разному (например, в базных БД).
Это всё на фоне очень жёстких требований по производительности операции проверки наличия права доступа у пользователя.
Здравствуйте, adontz, Вы писали:
A>Дано: пользователи, группы пользователей, права доступа, роли пользователей.
A>Группы могут включать пользователей и другие группы. Группа может быть включена в несколько групп, лишь бы не было циклов.
A>Права доступа объединяются в роли.
A>Группам, но не пользователям, назначаются роли.
A>Проверка наличия права доступа у пользователя выглядит как: A>Есть ли среди всех групп пользователей, в которые входит данный пользователь прямо или косвенно те, которым назначена роль разрешающая право доступа одновременно с отсутствием групп пользователей, в которые входит данный пользователь прямо или косвенно, у которых назначена роль запрещающая право доступа?
A>Проблема в том, что группы и пользователи могут быть по отношению к системе внешние (например, из Active Directory или любого другого LDAP-каталога), а права доступа и роли пользователей тоже необходимо иметь возможность хранить по-разному (например, в базных БД).
A>Это всё на фоне очень жёстких требований по производительности операции проверки наличия права доступа у пользователя.
A>Что делать? Есть ли какие-то стандартные схемы?
писал систему в которой полный набор прав доступа кэшировался в зашифрованном виде на токен (=смарткарту) (шифрование шло через сертификаты и т.д.)
в этом случае обращаться никуда для проверки не надо, все проверки идут по обращению к токену
соответственно скорость достаточно высокая
Здравствуйте, rsdnuser2007, Вы писали:
R>писал систему в которой полный набор прав доступа кэшировался в зашифрованном виде на токен (=смарткарту) (шифрование шло через сертификаты и т.д.) R>в этом случае обращаться никуда для проверки не надо, все проверки идут по обращению к токену R>соответственно скорость достаточно высокая
Не катит, изменение прав доступа должно отображаться немедленно.
Здравствуйте, adontz, Вы писали:
A>Проблема в том, что группы и пользователи могут быть по отношению к системе внешние (например, из Active Directory или любого другого LDAP-каталога), а права доступа и роли пользователей тоже необходимо иметь возможность хранить по-разному (например, в базных БД).
Первое что приходит в голову: реплицировать всю учетную информацию в одну локальную базу данных,
эффективные права доступа считать по ней.
Здравствуйте, ivb22, Вы писали:
I>Первое что приходит в голову: реплицировать всю учетную информацию в одну локальную базу данных, I>эффективные права доступа считать по ней.
А синхронизировать потом как? Мне такое решение не нравится.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, ivb22, Вы писали:
I>>Первое что приходит в голову: реплицировать всю учетную информацию в одну локальную базу данных, I>>эффективные права доступа считать по ней.
A>А синхронизировать потом как? Мне такое решение не нравится.
сделай оценку снизу по кол-ву обращений к внешним источникам данных. если это будет достаточно эффективно, то внутренняя машинерия вероятно будет лишь небольшим довеском к этому
Здравствуйте, BulatZiganshin, Вы писали:
BZ>сделай оценку снизу по кол-ву обращений к внешним источникам данных. если это будет достаточно эффективно, то внутренняя машинерия вероятно будет лишь небольшим довеском к этому
Вот смотри. У меня есть NT группы GroupA и Group2. GroupA разрешено что-то там, а Group2 — нет. Пользователь MegaUser состоявший в Group2 переводится в GroupA и при следующей проверке должен получить права доступа.
При отображении внешних групп на внутренние я это должен буду учитывать, но когда начинать синхронизацию совсем не ясно.
Можно группы не отображать, но тогда я совсем ясна структура БД. Многие FK придётся ликвидировать, да и сами идентификаторы какие делать? INT, GUID, string? GUID хорошо, а вдруг во внешнем LDAP каталоге авторизация (не AD), откуда тогда брать GUID?
Очень хочу продумать всё заранее.
A>Вот смотри. У меня есть NT группы GroupA и Group2. GroupA разрешено что-то там, а Group2 — нет. Пользователь MegaUser состоявший в Group2 переводится в GroupA и при следующей проверке должен получить права доступа. A>При отображении внешних групп на внутренние я это должен буду учитывать, но когда начинать синхронизацию совсем не ясно.
есть три варианта
1) кеширование
2) без кеширования
3) оповещения об изменениях, присылаемые источниками данных
A>Можно группы не отображать, но тогда я совсем ясна структура БД. Многие FK придётся ликвидировать, да и сами идентификаторы какие делать? INT, GUID, string? GUID хорошо, а вдруг во внешнем LDAP каталоге авторизация (не AD), откуда тогда брать GUID?
string или посл-ть байтов — вполне универсальный вариант. всё остальное можно в них засериализовать
A>Очень хочу продумать всё заранее.
ВСЁ заранее продумать невозможно. иди по другому пути — продумай реализацию того, что возможно будет использоваться
Здравствуйте, adontz, Вы писали:
A>Вот смотри. У меня есть NT группы GroupA и Group2. GroupA разрешено что-то там, а Group2 — нет. Пользователь MegaUser состоявший в Group2 переводится в GroupA и при следующей проверке должен получить права доступа.
Возможно, что стоит взять пример с NT. Там, для форсирования данного процесса придется сделать logon/logoff
A>При отображении внешних групп на внутренние я это должен буду учитывать, но когда начинать синхронизацию совсем не ясно.
При логине пользователя можно выдавать ему специальный токен (в который так или иначе может содержать информацию о его принадлежности к тем или иным группам) в данном токене размещается его expiration время.
A>Можно группы не отображать, но тогда я совсем ясна структура БД. Многие FK придётся ликвидировать, да и сами идентификаторы какие делать? INT, GUID, string? GUID хорошо, а вдруг во внешнем LDAP каталоге авторизация (не AD), откуда тогда брать GUID?
Для идентификаторов пользователей есть замечательный тип данных под названием SID. Основная идея в том, что кроме собственное самого идентификатора в нем присутствует компонента под названием Authority т.е идентификатор того, кто выдал данный SID. Можно почитать MSDN на эту тему — там все замечательно расписано.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
BZ>есть три варианта BZ>1) кеширование BZ>2) без кеширования BZ>3) оповещения об изменениях, присылаемые источниками данных
вмспомнил четвёртый — пользователь наживает кнопку Refresh, еали его не устаривает текущее содержимое кеша. можно это даже автоматизировать — сбрасывать кеш если пользователь пытается получить доступ к закрытым для него данным
Здравствуйте, TK, Вы писали:
TK>Возможно, что стоит взять пример с NT. Там, для форсирования данного процесса придется сделать logon/logoff
Приемлемо.
TK>При логине пользователя можно выдавать ему специальный токен (в который так или иначе может содержать информацию о его принадлежности к тем или иным группам) в данном токене размещается его expiration время.
То есть я перечисление групп содержащих пользователя делаю в момент аутентификации, создаю токен, запихиваю туда этот список и плюю на его последующие изменения пока токен не сгниёт?
TK>Для идентификаторов пользователей есть замечательный тип данных под названием SID. Основная идея в том, что кроме собственное самого идентификатора в нем присутствует компонента под названием Authority т.е идентификатор того, кто выдал данный SID. Можно почитать MSDN на эту тему — там все замечательно расписано.
Здравствуйте, adontz, Вы писали:
TK>>При логине пользователя можно выдавать ему специальный токен (в который так или иначе может содержать информацию о его принадлежности к тем или иным группам) в данном токене размещается его expiration время.
A>То есть я перечисление групп содержащих пользователя делаю в момент аутентификации, создаю токен, запихиваю туда этот список и плюю на его последующие изменения пока токен не сгниёт?
Все примерно так и делают. Например, в AzMan принадлежность пользователя к группе может быть динамической — узнать когда пользователь из нее пропадет практически нереально. Кеширование таком случае наиболее простой вариант.
TK>>Для идентификаторов пользователей есть замечательный тип данных под названием SID. Основная идея в том, что кроме собственное самого идентификатора в нем присутствует компонента под названием Authority т.е идентификатор того, кто выдал данный SID. Можно почитать MSDN на эту тему — там все замечательно расписано.
A>О, а вот это уже очень интересно! Спасибо!
Тут вообще можно сделать всю систему безопасности по образу и подобию NT (см Authz функции). единственное, только положить все это на свое хранилище данных.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Тут вообще можно сделать всю систему безопасности по образу и подобию NT (см Authz функции). единственное, только положить все это на свое хранилище данных.
