Конфигурирование сертификационной кампании#

Определение сертификационной кампании составляется по следующему шаблону:

1. name — название кампании. Например, «Сертификация всех назначений».

2. description — описание кампании для отображения в UI. Например, «Сертифицирует все назначения всех учетных карточек. Согласование выполняется администратором».

3. handlerUri — системный back-end обработчик (handler), используемый для проведения сертификации. В данной версии продукта доступен только один обработчик — http://midpoint.evolveum.com/xml/ns/public/certification/handlers-3#direct-assignment, который может обрабатывать только прямые назначения (объекты, назначенные напрямую объекту, а не косвенно через назначение другого объекта).

4. scopeDefinition — определение диапазона конкретных объектов, групп объектов и связей, которые будут обрабатываться в рамках кампании.

5. ownerRef — указание владельца данного определения и созданных по нему сертификационных кампаний, в виде oid объекта IDMX.

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

   1. outcomeStrategy — стратегия аггрегации решений, если на элемент назначено несколько согласующих. Возможные значения:

      • oneAcceptAccepts — если хотя бы один из согласующих подтвердил элемент, то результат согласования будет «Принято», вне зависимости от решений других согласующих. Стратегия по умолчанию.

        Параметр перехода по умолчанию — stopReviewOn = accept.

      • allMustAccept — все согласующие должны подтвердить элемент, чтобы он был согласован с результатом «Принято». Если в этапе не назначено согласующих — он вернет результат «Нет ответов».

        Параметр перехода по умолчанию — stopReviewOn = revoke, reduce.

      • oneDenyDenies — если хотя бы один из согласующих ответил «Отказать» или «Понизить привилегии», то результат согласования будет «Отказано» (или «Понижены привилегии»), вне зависимости от решений других согласующих. При отсутствии отрицательных решений, должно быть хотя бы одно решение «Принять», чтобы элемент был принят.

        Параметр перехода по умолчанию — stopReviewOn = revoke, reduce.

      • acceptedIfNotDenied — элемент будет принят, если ни один из согласующих не ответит «Отказать» или «Понизить привилегии». Так, например, если по элементу не будет принято никаких решений — он будет автоматически принят.

        Параметр перехода по умолчанию — stopReviewOn = revoke, reduce.

   2. stopReviewOn — Необязательный параметр. Определяет, при получении какого решения процесс сертификации для обрабатываемого элемента завершается и не переходит на следующий этап кампании. Если параметры stopReviewOn и advanceToNextStageOn не задан — используется значение по умолчанию, определяемое согласно выбранной страгетии outcomeStrategy.

   3. advanceToNextStageOn — Необязательный параметр. Определяет, при получении какого решения процесс сертификации для обрабатываемого элемента переходит на следующий этап кампании. Если параметры stopReviewOn и advanceToNextStageOn не задан — используется значение по умолчанию, определяемое согласно выбранной страгетии outcomeStrategy.

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

8. remediationDefinition — определение этапа корректировки, в том числе будет ли он ручным или автоматизированным.

9. reiterationDefinition — определение процесса реитерации — перезапуска кампании для получения ответов от тех согласующих, которые не проставили свои решения во время первого запуска.

10. adHoc — используется ли данная сертификационная кампания для микросертификации. Значение по умолчанию false.

Например, определение простой сертификационной кампании, в которой суперпользователь administrator согласовывает все назначения всех пользователей в системе IDMX будет выглядеть так:

<accessCertificationDefinition
        xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
        xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <name>Сертификация всех назначений</name> <!-- Название кампании -->
    <description>Сертифицирует все назначения всех учетных карточек. Согласование выполняется администратором.</description> <!-- Описание кампании -->
    <handlerUri>http://midpoint.evolveum.com/xml/ns/public/certification/handlers-3#direct-assignment</handlerUri> <!-- Обработчик, используемый в кампании -->
    <stageDefinition> <!-- Определение этапа согласования. Подробнее элементы блока будут расписаны в разделе ниже  -->
        <number>1</number>
        <name>Ревью администратора</name>
        <description>На этом этапе администратор согласовывает все назначения всех учетных карточек.</description>
        <duration>P14D</duration>
        <notifyBeforeDeadline>PT48H</notifyBeforeDeadline>
        <notifyBeforeDeadline>PT12H</notifyBeforeDeadline>
        <notifyOnlyWhenNoDecision>true</notifyOnlyWhenNoDecision>
        <reviewerSpecification>
            <defaultReviewerRef oid="00000000-0000-0000-0000-000000000002" type="UserType" />   <!-- oid пользователя administrator -->
        </reviewerSpecification>
    </stageDefinition>
    <remediationDefinition> <!-- Определение этапа корректировки -->
        <style>automated</style> <!-- Корректировка будет автоматизированной -->
    </remediationDefinition>
</accessCertificationDefinition>

Далее разберем все элементы более подробно. Поскольку элементы name, definition, handlerUri и ownerRef очевидны, опустим их.

Конфигурация диапазона обрабатываемых объектов#

Элемент scopeDefinition состоит из следующих блоков:

1. objectType — тип обрабатываемых объектов. По умолчанию это UserType (учетные карточки пользователей IDMX), однако можно указать RoleType, OrgType, ServiceType, FocusType или AbstractRoleType.

2. searchFilter — фильтр, определяющий, какие именно объекты выбранного типа следует обрабатывать. Составляется как стандартный фильтр в конфигурациях IDMX. По умолчанию (или если блок не указан) обрабатываются «все объекты заданного типа».

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

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

   • Обработчик прямых назначений:

     1. includeAssignments — следует ли включать назначения в сертификацию? По умолчанию true.

     2. includeInducements — следует ли включать косвенные назначения в сертификацию? По умолчанию true.

     3. includeRoles — следует ли включать в сертификацию прямые и косвенные назначения ролей? По умолчанию true.

     4. includeOrgs — следует ли включать в сертификацию прямые и косвенные назначения организаций? По умолчанию true.

     5. includeResources — следует ли включать в сертификацию прямые и косвенные назначения ресурсов? По умолчанию true.

     6. includeServices — следует ли включать в сертификацию прямые и косвенные назначения сервисов? По умолчанию true.

     7. enabledItemsOnly — следует ли включать в сертификацию только активные (а именно имеющие административный статус administrativeStatus = null или ENABLED) прямые и косвенные назначения? По умолчанию true.

Например, более сложный элемент scopeDefinition может выглядеть следующим образом:

<scopeDefinition xsi:type="AccessCertificationAssignmentReviewScopeType"> <!-- Элемент подключает расширение чтобы пользоваться элементами синтаксиса -->
    <objectType>UserType</objectType> <!-- Обрабатываются учетные карточки -->
    <searchFilter> <!-- Задается фильтр карточек -->
        <q:org> <!-- Фильтр по организации -->
            <q:path>parentOrgRef</q:path> <!-- Смотрим на родительскую организацию элементов -->
            <q:orgRef oid="00000000-8888-6666-0000-100000000001">       <!-- Указываем конкретную организацию — Governor Office -->
                <q:scope>SUBTREE</q:scope>  <!-- Диапазон элементов — поддерево организаций, у которых родительская организация — Governor Office -->
            </q:orgRef>
        </q:org>
    </searchFilter>
    <itemSelectionExpression> <!-- Выражение, по которому отбираются карточки для сертификации -->
        <script>
            <code> <!-- Смотрим все роли, назначенные на карточку, и, если они не null и имеют значение параметра riskLevel = critical — берем на согласование -->
                role = midpoint.resolveReferenceIfExists(assignment.targetRef)
                return role != null &amp;&amp; role.riskLevel == 'critical'
            </code>
        </script>
    </itemSelectionExpression>
    <includeRoles>true</includeRoles> <!-- Включаем в обработку только назначения ролей -->
    <includeOrgs>false</includeOrgs>
    <includeResources>false</includeResources>
</scopeDefinition>

Такое определение диапазона будет рассматривать назначения «карточка-роль» для карточек, принадлежащих к организациям под родительской организацией Governor Office и имеющих значение параметра riskLevel = critical.

Конфигурация этапов согласования сертификационной кампании#

В определении сертификационной кампании может быть один или несколько элементов stageDefinition. Один такой элемент может состоять из:

1. numbar — порядковый номер этапа. Определяет очередность этапов в кампании.

2. name и description — название и описание этапа кампании.

3. duration — длительность этапа, указываемая в формате ISO 8601. Время завершения этапа расчитывается как время запуска этапа плюс указанная в параметре длительность, и округляется до 23:59:59 последнего дня. Так, например, если этап был запущен в понедельник, 25 апреля, 13:45, с длительностью P7D (7 дней), то он завершится в понедельник, 2 мая, в 23:59:59.

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

5. notifyOnlyWhenNoDecision — параметр определяет, будет ли отправлено напоминание о скором конце кампании всем согласующим (false), или только тем, кто еще не принял решения по элементам сертификации (true).

6. reviewerSpecification — блок определяет, кто будет согласовывать элементы сертификации для данного этапа.

   В данном элементе используются два референсных объекта - цель (Target) и объект (Object). Target — это тот объект, который назначется, Object — объект, которому назначается цель. Например, если у нас есть пользователь Ivan, с назначенной ролью Суперпользователь, то Ivan будет Object, а Суперпользователь — Target. Дальнейшие параметры будут описываться с учетом этих отношений и терминов.

   Возможные значения:

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

   • useTargetOwner — согласующим будет назначен владелец Target (для примера выше — владелец роли Суперпользователь).

   • useTargetApprover — согласующим будет назначен объект (как правило учетная карточка, имеющая назначение на соответствующую роль с отношением approver), который является согласующим для Target.

   • useObjectOwner — согласующим будет назначен владелец Object, на который назначена Target. Как правило такая связь применяется, когда Object является организация или другая роль.

   • useObjectApprover — согласующим будет назначен объект, являющийся согласующим для Object.

   • useObjectManager — согласующим будет назначен объект (как правило учетная карточка), являющаяся менеджером в организации/организациях, к которым принадлежит Object.

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

7. outcomeIfNoReviewers — параметр определяет решение по умолчанию (accept, revoke и другие), принимаемое, если на элемент не было задано ни одного согласующего (например, в reviewSpecification задано значение useObjectManager, но у обрабатываемого Object нет ни одного менеджера в организационной структуре). Обратите внимание, ситуации, когда на элемент был назначен хотя бы один согласующий, но он не принял никакого решения по элементу, не обрабатываются данным параметром!

8. outcomeStrategy — стратегия аггрегации решений для данного этапа. Обратите внимание — значение данного параметра заменяет значение параметра reviewStrategy, определенного для всей кампании!

   Возможные значения:

   • oneAcceptAccepts — если хотя бы один из согласующих подтвердил элемент, то результат согласования будет «Принято», вне зависимости от решений других согласующих. Стратегия по умолчанию.

     Параметр перехода по умолчанию — stopReviewOn = accept.

   • allMustAccept — все согласующие должны подтвердить элемент, чтобы он был согласован с результатом «Принято». Если в этапе не назначено согласующих — он вернет результат «Нет ответов».

     Параметр перехода по умолчанию — stopReviewOn = revoke, reduce.

   • oneDenyDenies — если хотя бы один из согласующих ответил «Отказать» или «Понизить привилегии», то результат согласования будет «Отказано» (или «Понижены привилегии»), вне зависимости от решений других согласующих. При отсутствии отрицательных решений, должно быть хотя бы одно решение «Принять», чтобы элемент был принят.

     Параметр перехода по умолчанию — stopReviewOn = revoke, reduce.

   • acceptedIfNotDenied — элемент будет принят, если ни один из согласующих не ответит «Отказать» или «Понизить привилегии». Так, например, если по элементу не будет принято никаких решений — он будет автоматически принят.

     Параметр перехода по умолчанию — stopReviewOn = revoke, reduce.

9. stopReviewOn — Необязательный параметр. Определяет, при получении какого решения процесс сертификации для обрабатываемого элемента завершается и не переходит на следующий этап кампании. Если параметры stopReviewOn и advanceToNextStageOn не задан — используется значение по умолчанию, определяемое согласно выбранной страгетии outcomeStrategy.

10. advanceToNextStageOn — Необязательный параметр. Определяет, при получении какого решения процесс сертификации для обрабатываемого элемента переходит на следующий этап кампании. Если параметры stopReviewOn и advanceToNextStageOn не задан — используется значение по умолчанию, определяемое согласно выбранной страгетии outcomeStrategy.

Также в рамках конфигурации этапов кампании можно задать настройки эскалации.

Варианты решений по элементам согласования#

В рамках этапа сертификационной кампании по каждому элементу в итоге должно быть принято какое-либо решение. Итоговое решение по элементу может изменяться в зависимости от выбранной стратегии аггрегации решений.

Возможные решения, которые может принять согласующий по элементу:

• accept — Принять, оставить объекту (Object) целевое назначение (Target).

• revoke — Отказать, снять с объекта целевое назначение.

• reduce — «Понизить» уровень привилегий — согласующий считает что обрабатываемое назначение недопустимо для объекта, но для решения конфликта недостаточно простого выбора «отнять/оставить привилегии», и специалистам следует найти другое решение.

• not_decided — Согласующий не может принять решение по данному элементу (воздерживается от ответа).

• delegate — Согласующий передает свое право голоса по данному элементу другому пользователю.

• no_response — Согласующий не принял решения по данному элементу до окончания сертификационной кампании. Обратите внимание, данный ответ отличается от ответа not_decided.

При аггрегации решений нескольких согласующих, в зависимости от используемой стратегии аггрегации, решение по элементу в рамках этапа может изменяться.

Ниже приведены таблицы соответствия стратегии и итогового решения. Для аннотирования используются следующие символы:

• + — По элементу принято одно или более решений столбца.

• - — По элементу не принято ни одного решения столбца.

• * — Решение столбца игнорируется, вне зависимости от количества таких решений по элементу.

• Стратегия oneAcceptAccepts

  revoke	reduce	not_decided	no_response	accept	Итоговый результат
  *	*	*	*	+	accept
  +	*	*	*	-	revoke
  -	+	*	*	-	reduce
  -	-	+	*	-	not_decided
  -	-	-	+	-	no_response
  -	-	-	-	-	Ответ по умолчанию, если задан

• Стратегия allMustAccept

  revoke	reduce	not_decided	no_response	accept	Итоговый результат
  +	*	*	*	*	revoke
  -	+	*	*	*	reduce
  -	-	+	*	*	not_decided
  -	-	-	+	*	no_response
  -	-	-	-	+	accept
  -	-	-	-	-	Ответ по умолчанию, если задан

• Стратегия oneDenyDenies

  revoke	reduce	not_decided	no_response	accept	Итоговый результат
  +	*	*	*	-	revoke
  -	+	*	*	-	reduce
  -	-	+	*	-	not_decided
  -	-	-	+	-	no_response
  -	-	*	*	+	accept
  -	-	-	-	-	Ответ по умолчанию, если задан

• Стратегия acceptedIfNotDenied

  revoke	reduce	not_decided	no_response	accept	Итоговый результат
  +	*	*	*	*	revoke
  -	+	*	*	*	reduce
  -	-	+	*	*	accept
  -	-	-	+	*	accept
  -	-	-	-	+	accept
  -	-	-	-	-	Ответ по умолчанию, если задан

Конфигурация процесса корректировки#

Конфигурация корректировки в данной версии ограничивается двумя параметрами — стилем и решением отказа.

• style — будет ли корректировка полномочий проводиться вручную или автоматически. При автоматической корректировке полномочия будут только отниматься, а именно нет возможности задать более сложные действия. Возможные варианты - manual или automated.

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

Ручная и автоматическая корректировка#

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

Таким образом, для каких-либо более сложных действий потребуется ручная работа наделенных достаточными привилегиями администраторов IDMX. Например, если по решению кампании требуется сократить количество привилегий у пользователя (результат reduce), то администраторам потребуется вручную снять привилегию с пользователя и выдать более подходящую согласно решению кампании.

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

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

Конфигурация процесса реитерации сертификационной кампании#

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

Более подробно процесс реитерации выглядит так:

1. После завершения кампании сертификации, она может быть реитерирована.

2. При запуске процесса реитерации будут обрабатываться только элементы, у которых итоговое решение по результатам предыдущего запуска кампании было no_response.

3. При начале каждого этапа сертификации для обрабатываемых элементов возможно два варианта развития событий:

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

   2. Для данного элемента на данном этапе не было принято решения во время предыдущих итераций. В таком случае IDMX создаст элементы только для тех согласующих, которые не приняли решений во время предыдущих итераций. При этом итоговое решение по элементу будет учитывать решения других согласующих, принятые во время предыдущих итераций (кроме решений no_response).

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

      По результатам обработки ситуации возможны два исхода:

      1. Создаются новые элементы для согласования.

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

         В таком случае итоговое решение по элементу будет расчитано исходя из решений, полученных в предыдущих итерациях.

Обратите внимание:

1. Если для этапа не было создано ни одного нового элемента (все элементы находятся в ситуации 3-ii-b), то этап будет длиться весь указанный в параметре duration промежуток времени.

2. При расчете итогового решения по элементу в рамках этапа учитываются все решения, вне зависимости от того, в какой из итераций они были приняты.

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

Блок конфигурации реитерации содержит следующие элементы:

1. startsAfter — после какого промежутка времени после завершения сертификационной кампании следует автоматически запустить реитерацию. По умолчанию параметр пуст, и реитерация запускается только вручную. Значение указывается в формате ISO 8601.

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

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