4.5 Функциональные требования

R4.5.1 Система должна позволять авторизованному пользователю создавать роли, обладающие по крайней мере следующими метаданными:

  • системный идентификатор;
  • метка времени создания;
  • дата/время происхождения;
  • индикатор административной роли;
  • метка времени начала использования;
  • название;
  • описание;
  • ограничительная помета;
  • идентификатор определения функции;
  • метка времени удаления.

 

Каждая роль также обладает:

  • списком доступа для роли;

и также может обладать

  • контекстуальными метаданными (или их эквивалентом, см. 7. Типовая служба метаданных).

 

В зависимости от подхода, используемого в системе для создания 7. Типовой службы метаданных, механизм, с помощью которого осуществляется добавление элементов контекстуальных метаданных к системным объектам, может различаться.

 

Обратите внимание на то, что предзаданные роли поставляются как часть системы управления записями, а не создаются пользователями, однако они обладают теми же метаданными, что и роли, созданные пользователями (см. 4.3.6 Предзаданные роли).

 

R4.5.2 Система должна позволять авторизованному пользователю изменять название, описание и ограничительные пометы роли, равное как и ее контекстуальные метаданные.

 

Обратите внимание на то, что данная функция не может быть применена к предзаданным ролям, установленным в системе по умолчанию (см. 4.3.6 Предзаданные роли).

 

R4.5.3 Система должна позволять авторизованному пользователю придавать роли статус административной/неадминистративной, но только в случае, если роль не была включена ни в одну из записей доступа.

 

После того, как роль была использована, уже невозможно изменить ее статус с административного на неадминистративный, и наоборот — это может иметь непредсказуемые последствия для объектов, по отношению к которым была предоставлена роль, а также к их порожденным объектам.

Обратите внимание на то, что данная функция не может быть применена к предзаданным ролям, установленным в системе по умолчанию (см. 4.3.6 Предзаданные роли).

 

R4.5.4 Система должна позволять добавлять определения функций к активным ролям и удалять их, обеспечивая при этом ассоциацию каждого определения функции по крайней мере с одной ролью.

 

В противном случае могут появиться функции, которые никогда не будут выполнены. Определения функций добавляются во время использования активных ролей.

 

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

Обратите внимание на то, что данная функция не может быть применена к предзаданным ролям, установленным в системе по умолчанию (см. 4.3.6 Предзаданные роли).

 

 

R4.5.5 Система должна позволять авторизованному пользователю полностью удалять роль, ни разу не включенную ни в один из списков доступа, при условии, что каждое определение функции все время ассоциировано по крайней мере с одной активной ролью.

 

 

При первом включении роли в запись доступа система должна установить метку времени начала использования.

 

Обратите внимание на то, что данная функция не применяется к предзаданным ролям, являющимся частью системы по умолчанию. (см. 4.3.6 Предзаданные роли).

 

R4.5.6 Система должна позволять авторизованному пользователю осуществлять частичное удаление роли, которая уже была включена в запись доступа при условии, что каждое определение функции все время ассоциировано по крайней мере с одной активной ролью.

 

После начала использования роль уже может быть удалена не полностью (как это описано в R4.5.6), а лишь частично. После частичного удаления сохраняется остаточная роль. Остаточная роль не дает пользователям прав на выполнение функций.

 

Обратите внимание на то, что данная функция не применяется к предзаданным ролям, являющимся частью системы по умолчанию. (см. 4.3.6 Предзаданные роли).

 

R4.5.7 В соответствии с R2.4.22 и в дополнение к R2.4.11, система должна позволять авторизованному пользователю просматривать роли и определения функций по крайней мере следующими способами:

  • просматривать в службе ролей роли и их метаданные;
  • просматривать в службе ролей определения функций и их метаданные;
  • переходить от роли к определениям функций, включенным в эту роль, и просматривать их метаданные;
  • переходить от определения функции ко всем включающим его ролям и просматривать их метаданные.

 

Значение термина «просматривать» указано в 13. Глоссарий.

 

R4.5.8 Система должна автоматически создавать для каждой службы или группы служб (R2.4.1), а также для каждого системного объекта (в случаях, когда это необходимо) список управления доступом, обладающим следующими метаданными:

 

  • индикатор наследования ролей (M14.4.43)

 

Каждый список управления доступом также включает:

 

  • записи доступа для каждого объекта.

 

 

Список управления доступом представляет собой структуру данных (ее детальное определение приведено в D14.3.2) содержащую записи доступа, определяющие, какие именно пользователи и группы могут получать доступ к объектам в рамках конкретных ролей. Каждый список управления доступом является неотъемлемой частью объекта; каждому объекту принадлежит единственный список управления доступом.

 

Списки управления доступом применяется в MoReq2010 как к объектам, так и к службам, поэтому могут быть унаследованы всеми объектами в службе. Список управления доступом для службы записей наследуется только корневыми агрегациями. Таким образом, например, обеспечивается возможность предоставить группе пользователей административный доступ к классификационной схеме внутри службы классификаций. Если в организации используются две службы классификаций , то управление службами может осуществляться двумя группами независимо друг от друга, и у каждой из служб будет собственный список управления доступом.

 

Необходимость наличия списков управления доступом для большинства типов объектов прописана в других требованиях. Например, требованием R2.4.2 для модуля системных служб, требованием R2.4.10 для типов объектов, требования R2.4.12 для определений функций; аналогичным образом в службе пользователей и групп — требованием R3.4.1 (для пользователей) и требованием R3.4.8 (для групп).

 

В базовых службах MoReq2010 только списки управления доступом, записи доступа, события и компоненты не имеют собственных списков управления доступом. Обратите внимание на то, что в состав метаданных списков управления доступом не входит отдельный системный идентификатор, так как список управления доступом принадлежит объекту и является его неотъемлемой частью. Индикатор наследования ролей, таким образом, включается в состав метаданных каждого объекта, имеющего список контроля доступа.

 

Значение индикатора для службы не имеет никакого значения, так как службы не наследуют списков управления доступом.

 

Индикатор наследования ролей означает лишь то, что объект унаследует только списки управления доступом для административных ролей. Наследование административных ролей не может быть заблокировано.

 

R4.5.9 Система должна позволять авторизованному пользователю просматривать списки управления доступом и содержащиеся в них записи.

 

Данная функция является отдельной от общих метаданных объекта.

 

R4.5.10 Система должна позволять авторизованному пользователю изменять список управления доступом к объекту, изменяя таким образом значение индикатора наследования ролей, а также добавлять, изменять и удалять записи доступа со следующими метаданными:

 

  • идентификатор пользователи или группы и
  • идентификатор роли.

 

Записью доступа называется структура данных, включенная в список управления доступом. Записи доступа всегда ходят в какой-либо список.

 

Каждый объект может иметь только одну запись доступа, относящуюся к конкретному авторизованному пользователю или группе. Каждая запись должна быть снабжена идентификатором пользователя или группы и по крайней мере одним идентификатором роли. Добавляя запись в список управления доступом, авторизованный пользователь предоставляет определенным пользователям и группам право на выполнение функций по отношению к объекту и его порожденным объектам. Удаляя запись из списка, авторизованный пользователь лишает определенных пользователей и группы этого права. Изменяя запись доступа, авторизованный пользователь может увеличить или уменьшить число ролей, тем самым расширяя или сужая набор функций, применяемый по отношению к объекту и его порожденным объектам.

В ситуации, описываемой требованием R2.4.15, в соответствии c R2.4.13, при добавлении, изменении или удалении записи доступа в истории событий объекта всегда создается новое событие.

 

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

 

 

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

 

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

 

Наследование объектом ролей от его службы, родительского объекта или класса зависит от значения индикатора наследования ролей. Административные роли наследуются всегда, тогда как неадминистративные роли будут наследоваться только в случае, если включено наследование ролей.

 

При получении роли группой пользователи, входящие в ее состав, наследуют роль в течение всего время, пока они остаются членами группы, а группа остается активной. Пользователи не наследуют ролей, назначенных удаленным группам.

 

В этом требовании разъясняется значение понятия «авторизованный пользователь». Не имеет значение, каким именно образом осуществляется авторизация пользователя и сколько именно существует способов такой авторизации.

 

R4.5.12 Система должна предоставлять активному пользователю возможность получать информацию о том, выполнение каких функций по отношению к любому объекту ему разрешено.

 

Метод, с помощью которого осуществляется обратная связь с пользователями, зависит от используемого в системе интерфейса (см. R2.4.6)

 

 

R4.5.13 Система должна позволять авторизованному пользователю создавать отчет с информацией о том, какие именно функции имеет право осуществлять по отношению к объектам системы выбранный пользователь и каким образом эти функции определены.

 

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

Отчет должен включать:

 

  • все функции, на выполнение которых по отношению к определенному объекту пользователь имеет право;
  • для каждой функции — активные роли, включающие эту функцию, в которых может выступать пользователь;
  • для каждой активной роли — список путей, посредством которых они могут быть предоставлены пользователю, включая членство в активных группах и наследование ролей от родительского объекта

 

 

 

R4.5.14 Система должна предоставлять авторизованному пользователю возможность создавать отчет, содержащий информацию об определениях функций, принадлежавших конкретной роли на конкретную дату и время.

 

В отчете должно быть указано, относятся ли введенные дата и время к периоду до создания роли или к периоду после ее уничтожения.

 

 

R4.5.15 Система должна позволять авторизованному пользователю искать и находить:

 

  • объекты, в списки доступа которых включена конкретная роль;
  • объекты, в списки доступа которых включены конкретные пользователи или группы.

 

Пользователи могут искать и находить объекты, на просмотр списков доступов которых они обладают достаточными правами (R4.5.9). Авторизованный пользователь может искать как объекты в системе, по отношению к которым была назначена роли, так и пользователей и группы, которым была назначена роль. Более подробную информацию см. в 10. Служба поиска и отчетов.

Оставить комментарий

Вы должны войти, чтобы оставить комментарий.