ну это мазохизм - заставлять пользователя выбирать роль.. он что должен помнить, в какой момент "не читать, тут рыбу заворачивали" ? Пользователь должен заходить и ему без всяких вопросов должны даваться те функции, которые положены по объединению назначенных ему ролей.

guest_20040621> ну это мазохизм

Зависит от реализации. Например, от того, как реализовано делегирование (возможно, временное). Или от правил определения атрибутов для новых данных: если объединить в сессии несколько ролей, какие атрибуты получит новая запись?

Вообще imho удобнее представлять роль как явный набор элементарных сущностей.

так и будет массив ролей.

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

iscrafm Если в конкретный момент времени у человека есть доступ к нескольким ролям, то как ему выбрать нужную, без "мазохизма". Вы рассматриваете Роль, просто как набор модулей(функций). На самом деле, в системах где применяется ролевой доступ, понятие роли несколько шире. Например, образно, одна и та же цифра, введенная под разными ролями, обрабатывается по разному. Одна и таже информация представляется по разному. и т.д. и т.п.

если разная обработка - то значит разаня функциональность - разве нет? обработка - это действие, функциоанльность тоже самое. Представление - тоже смое действие- та же самая функциональность. Просто ее можно разбить на такие мелкие - обработка цифры, представление 1 , представление 2 и т.п. и потом привязывать к разным ролям.
Но я написала, что есть два понятия роли, то, что вы говорите - это , если роль прописана в программе (насколько я поняла).

iscrafmнет. ничего в программе не прописывается. Простой пример... Если менеджер вводит документ, то он требует подписи и согласования, а если начальник отдела, то нет. Документ один, роли разные, реакция на событие разная
ну эта тогда ситуация, когда роли приписываются к элементарным функциональностям - функциональность "подписать" , "согласовать" (если они чем-то различаются). ну можно еще роли объединять (наследовать) - хотя тут этого и не нужно. То, что документ один - ничему не мешает и не помогает, документ - это совсем другая абстракция - это данные, с которыми манипуляции проводятся. у разных ролей могут быть одни и те же данные - никому это не мешает. Возможно, мы говорим про одно, но разными понятиями.

guest_20040621> так и будет массив ролей.

Да. Если честно, я не люблю использовать абстракцию "роль". По сути, у нее одна основная функция: группировка экземпляров сущностей. При этом что является источником, что целью, а что правилами - не имеет явного определения. Imho нагляднее эти явные определения иметь. Чуть сложнее, но удобнее и понятнее.
правила - более или мене понятно - некие корпоративные правила (ДНФ условий), а вот автоматизация всего этого - вещь просто незаменимая, например, назначить роль просмотр учебных планов тем, кто является начальником подразделений, с роль Деканат ( по И налажение тех, кто работает в подразделениях с ролью Деканат и тех, кто имеет должность с ролью Начальник и именно в соответствующих подразделениях). Если кадры меняются или подразделения приобретают или теряют роли , то роль для доступа автоматически снимается или назначается.

iscrafmOFF
Mainframe_старый,
а чем отличаются группы не имеющие доступа к ресурсу от групп, которым закрыт доступ к ресурсу? Или это взаимоисключающие списки? т.е. или методом запрета или методом разрешения?
Это взаимодополняющие списки. Три типа разрешений - разрешено/не назначено/запрещено. (1,0,-1). Удобно, когда назначено какой-то большой группе, а вот отдельной подгруппе (из этой группы) надо запретить. Например, если в данном примере, добавить запрет на декана института заочного оборазования, то все деканы получат доступ, а декан заочного не получит, так как хотя он входит в первую группу, но и во вторую (запрет), которая должна иметь дату назначения позже первой. (приоритет определяется датой-временем начала действия назначения, если периоды назначения накладываются (а они могут и не пересекаться - с 1.09-1.10 открыт, с 2.10 - закрыт)

Petro123Mainframe_старый,
в NTFS почти то же, только есть наследуемые разрешения и нет "не назначено".
При проверке, если есть запрет, то разрешения даже не проверяются.
(админу можно запретить сверху разрешения)
там совсем не тоже (вам кажется тоже, так как в основе всех ролевых подходов лежит RBAC). наследование есть, конечно, без них невозможно реализовать большие назначения.
а вот по поводу запрета - я анализировала как лучше сделать в разных ситуациях. Единственное приемлимое решение по дате/времени приоритет, а не по запрету (такой вариант тоже думали). Потому что могут быть (и у нас были) такие ситуации, когда приоритет запрета не позволяет легко выполнить нужные назначение, а вот дата/время пока всегда выручало.

guest_20040621Карина Иосифовна, трехзначная логика какую задачу в данном случае решает? Есть какой-то смысл в неопределенных значениях?

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

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

Но у нас большинство назначений (80% ) выполняется в групповом режиме, на выделенное множество пользователей. Т.е. нужно по каким-то правилам выделить народ - эти правила - в основном бизнес-правила - где работает, в какой должности, роль подразделения, роль должности, учебная группа, институт, где учится, кафедра, проживание в общежитии и т.п. (сейчас 13 фильтров). Причем эти выделения являются не ролью, а функцией. Например, может быть роль Сотрудник, а фильтр - Категории, где среди категорий может быть и сотрудник.

Пусть мы выделяем народ по фильтру работющие в подразделениях ВГУЭС (или как на риснуке, работающие в Институтах - вкдючая вложенные в них кафедры, лаборатории и т.п.). В результате выделяется около 800 человек, часть из которых почасовики (человк 150). Наша задача - дать права всем, кто работает в Институтах, но не почасовикам. как это сделать? (разница множеств).

Мы даем разрешение всем , кто в Институтах (800) и запрещаем всем, кто имеет должность почасовик (150). Назначение Занимет 1 минуту (а если персонально - саим предсатвлете сколько бы надо было каждого 800 искать и при том, что 1/3 уже к конце назначений перешла в другое место или уоволилась) . И галвное - оно всегда актуально, если человек увольянется, но остается почасовиком, ему назначение сразу запрещается, с того момента, с которого он стал почасовиком и наоборот.

На рисунке пример - Даны права тем кто рабоатет в институтах или в ректорате, или является Кононовой, и запрещены там , кто рабоатет в институте ИСМД или Почасовикам. (можно запретить почасовикам , которые работают в ИМСД или как угоджно любой вариант ДНФ).

Без запрещения в нашем случае реализовать простые назначения - я не вижу как. Вручную назначать 650 = 800-150 соррудникам доступ - никаких ресурсов не хватит.

Про индивидуальнео назначение и запреты - в целом, конечно, тут и без него легко обойтисть. Но иногда - можно и с ним. например, у нас биллиннг свой - как раз на управлении правами сделан. Человку дается доступ в Интернет (роль - Доступ в Интернет), если он превзошел свой лимит трафика, то можно использовтаь два варианта. 1. Автоматически Дать роль Доступ закрыт - с периодом действия до конца месяца (или какая-тто другая логика ). 2. Автоматически Добавить назанчение этой же роли - Доступ в Интернет с момента закрытия до конца периода с запретом. (Далее на оснвое наличия ролей генерируется на прокси сервере разрешения, но это уже не в тему обсуждения). Большой разницы в этих вариантах нет, вопрос удобства - в одном месте искать, если надо посмотреть, или в двух, не более того.

guest_20040621> Это взаимодополняющие списки.

Интересная реализация.

Кстати, это пример в тему такого нашего давнего разговора, чем отличаются процессы вуза от иных .. вон Валере наверняка не нужны групповые назначения, да и не в вузах - такое мало кому нужно, а в вузе ситуация иная - все - есть пользователи - в том числе и студенты (и большую часть процессов надо делать через системы) и управлять правами без автоматизации (т.е. по индивидуальным назанчениям) - это держать штат админов и все равно будет не актуально.

Тут на эту тему с наим забавная сиутация приключилась. были у нас интеграторы - ставили турникеты (третий вид уже). ну ставить они моугт тролько физически - устнавить, питание подключить и все. Дальше мы сделали все сами (печать картчоек у нас уже лет 7 своя, а там еще добавили залитие в данный вид турникетов нужных карточек - по системе управления правами в том числе). Ну ребята из Интеграторов у нас потусовались - посмотрели , что у нас и картчоки и ключи на вахте через карточки и посещаемость студентов автоматически через карточки и считыватели в аудиториях , вернулись к себе и стали другим вузам предлагать - что они для них могут сделать ... и некий менеджер, который был не в курсе, откуда ноги растут - и нам тоже предложил . Людям далеким от вузов на самом деле тяжело заниматься в вузах автоматизацией - ведь им же хотя бы надо былдо сообразить , что чтобы сделать полноценную посещаемость, нужна полноценная система Расписания ... вот эти причинно-следственные связи ускользают с непривычки ;))