Активация#

Часть активации определения типа объекта ресурса находится в разделе schemaHandling определения ресурса. Часть активации определяет, как объект ресурса активируется — должен ли он существовать или нет, должен ли он быть включен, отключен или заархивирован. Эта часть может использоваться для тонкой настройки политик активации и деактивации. Например, она может использоваться для указания того, следует ли удалять учетную запись или отключать ее при отмене назначения пользователя.

Часть активации определения объекта ресурса состоит из трех частей: сопоставление существования, сопоставление административного статуса и сопоставления действительности.

Сопоставление существования#

Сопоставление существования определяет, должен ли ресурсный объект существовать или нет. Если сопоставление активации возвращает true, то ресурсный объект будет существовать (будет сохраняться как есть или будет создан). Если оно возвращает false, то ресурсный объект не будет существовать (не будет создаваться или будет удален).

Сопоставление существования обычно использует концепцию законности. Законность определяется путем оценки назначений и режима принудительного выполнения назначений. Результат такой оценки предоставляется как input для сопоставления существования. Поэтому простого выражения asIs обычно достаточно:

Сопоставление существования asIs

<activation>
    <existence>
        <outbound>
            <expression>
                <asIs/>
            </expression>
        </outbound>
    </existence>

</activation>

Приведенное выше сопоставление вернет true, если объект ресурса является законным. Следовательно, такой объект будет существовать. Он возвращает false, если объект не является законным (например, отсутствует назначение для него в режиме полного принудительного назначения). Следовательно, такой объект будет удален. Это также сопоставление по умолчанию, которое предполагается в случае отсутствия явного сопоставления существования.

Обратите внимание, что аналогичная переменная называется assigned. Она истинна тогда и только тогда, когда существует допустимое назначение для этого ресурса объекта.

В режиме полного применения назначения assigned всегда такой же, как input (legal). В других режимах обеспечения соблюдения они могут отличаться. Например, в режиме ОТНОСИТЕЛЬНОГО режима объект ресурса может быть законным даже в том случае, если он не назначен.

Переменная	Тип	Описание
`input`	логический	законность: установлено значение `true`, если объект является законным (основанным на оценке назначения и режиме принудительного исполнения).
`assigned`	логическое	Истинно, если существует допустимое назначение для этого объекта.
`focusExists`	логическое	Указывает, существует ли фокусный объект (например, пользователь), к которому привязан ресурсный объект. Установите его на `true`, если ресурсный объект связан с существующим фокусным объектом.
`focus`	Тип фокуса	Содержит полный фокусный объект (например, пользователь).
`shadow`	`ShadowType`	Содержит теневую копию, для которой оценивается существование (может отсутствовать, если еще не создана).

Слабое сопоставление существования#

Что касается сопоставлений, концепция существования учетной записи является странной. Выход (целевой) сопоставления напрямую не связан ни с каким свойством в тени. Он просто отражает состояние того, должна ли проекция существовать или нет. Поэтому использование слабых сопоставлений несколько отличается от других частей IDM. Целевое свойство виртуально, и оно фактически никогда не существует - даже если тень уже существует. Поэтому слабые сопоставления применяются даже тогда, когда тень существует, что может показаться довольно контрпродуктивным. Но есть преимущество. Слабые сопоставления не будут применяться, если есть другие не слабые сопоставления. Таким образом, такое слабое сопоставление можно использовать для определения нормального состояния учетной записи. Например, учетная запись обычно должна существовать все время, даже если она не законна. А затем другое сопоставление может использоваться для управления другими или необычными ситуациями. Например, мы действительно хотим удалить учетную запись, если она находится в незаконном состоянии слишком долго.

Например:

<activation>
    <!-- Explicit existence mapping. Unassigned accounts are disabled, not deleted.
              The accounts are deleted after 1 month -->
    <existence>
        <outbound>
            <name>default existence</name>
            <strength>weak</strength>
            <expression>
                <path>$focusExists</path>
            </expression>
        </outbound>
        <outbound>
            <name>delayed delete</name>
            <timeFrom>
                <referenceTime>
                    <path>$shadow/activation/disableTimestamp</path>
                </referenceTime>
                <offset>P1M</offset>
            </timeFrom>
            <source>
                <path>$shadow/activation/administrativeStatus</path>
            </source>
            <source>
                <path>$shadow/activation/disableReason</path>
            </source>
            <expression>
                <value>false</value>
            </expression>
            <condition>
                <script>
                    <code>
                        import com.evolveum.midpoint.xml.ns._public.common.common_3.ActivationStatusType
                        import com.evolveum.midpoint.schema.constants.SchemaConstants
                        administrativeStatus == ActivationStatusType.DISABLED &amp;&amp;
                        // do not delete explicitly disabled accounts
                        (disableReason == SchemaConstants.MODEL_DISABLE_REASON_DEPROVISION ||
                        disableReason == SchemaConstants.MODEL_DISABLE_REASON_MAPPED)
                    </code>
                </script>
            </condition>
        </outbound>
    </existence>
    <administrativeStatus>
        <outbound>
            <strength>strong</strength>
            <expression>
                <script>
                    <code>
                        import com.evolveum.midpoint.xml.ns._public.common.common_3.ActivationStatusType
                        if (legal) {
                        input
                        } else {
                        ActivationStatusType.DISABLED
                        }
                    </code>
                </script>
            </expression>
        </outbound>
    </administrativeStatus>
</activation>

В этом случае слабое сопоставление «существование по умолчанию» применяется в нормальных обстоятельствах. Это означает, что учетная запись будет существовать при нормальных обстоятельствах. Но если ограничение по времени и условие в сопоставлении «отложенное удаление» оцениваются как значение true, то вместо него применяется сопоставление «отложенное удаление», а «существование по умолчанию» игнорируется. Что означает, что учетная запись удаляется.

Хотя сопоставление существования технически может иметь часть inbound , такая часть никогда не используется.

Административное сопоставление статусов#

Административное сопоставление статусов отображает административный статус активации от фокусного объекта (пользователь) к административному статусу ресурсного объекта.

Сопоставление административного статуса

<administrativeStatus>
     <outbound>
              <expression>
                           <asIs/>
              </expression>
     </outbound>
</administrativeStatus>

Переменная	Тип	Описание
`input`	Тип состояния активации	«Магический» вычисляемый статус, который наиболее подходит для учетной записи. Это либо `administrativeStatus`, если ресурс поддерживает ограничения по времени действия (validFrom, validTo), либо это `effectiveStatus`, если нет. В последнем случае это эффективно имитирует ограничения по времени действия, используя только статус активации. Обратите внимание, что начиная с версии 4.8, значение `archived` здесь отсутствует. Он автоматически изменяется на `disabled`.
`administrativeStatus`	Тип состояния активации	`$focus/activation/administrativeStatus` Это может использоваться для предотвращения «магического» вычисления в переменной `input` и вычисления вывода нестандартным способом.
`legal`	логическое	Законность: установить на `true`, если объект является законным (на основе оценки назначения).
`assigned`	логический	Истина, если существует допустимое назначение для этого объекта.
`focusExists`	логический	Указывает, существует ли фокусный объект (например, пользователь), к которому привязан ресурсный объект. Установите значение `true`, если ресурсный объект связан с существующим фокусным объектом.
`focus`	Тип фокуса	Содержит полный фокусный объект (например, пользователя).

Соответствие действительности#

Аналогично administrativeStatus, мы можем написать сопоставления для validFrom и validTo - при условии, что ресурс поддерживает их.

Пример, который распространяет все эти три свойства на ресурс:

<activation>
    <administrativeStatus>
        <outbound>
            <strength>weak</strength>
            <expression>
                <asIs/>
            </expression>
        </outbound>
    </administrativeStatus>
    <validFrom>
        <outbound>
            <strength>weak</strength>
            <expression>
                <asIs/>
            </expression>
        </outbound>
    </validFrom>
    <validTo>
        <outbound>
            <strength>weak</strength>
            <expression>
                <asIs/>
            </expression>
        </outbound>
    </validTo>
</activation>

Предварительно определенные сопоставления активации#

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

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

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

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <administrativeStatus>
                    <outbound>
                        <strength>strong</strength>
                        <expression>
                            <asIs/>
                        </expression>
                    </outbound>
                </administrativeStatus>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

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

Отключение вместо удаления#

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

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <administrativeStatus>...</administrativeStatus>
                <disableInsteadOfDelete/>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

Задержка удаления#

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

Мы используем activation/disableTimestamp из объекта теней в качестве ссылочного атрибута для времени, когда учетная запись была отключена. В качестве причины отключения мы используем де-привязку, что означает, что назначение ресурса было удалено из фокуса (например, пользователя).

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <administrativeStatus>...</administrativeStatus>
                <delayedDelete>
                    <deleteAfter>P1M</deleteAfter>
                </delayedDelete>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

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

Предварительная подготовка#

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

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <administrativeStatus>...</administrativeStatus>
                <preProvision>
                    <createBefore>-P5D</createBefore>
                </preProvision>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

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

Примеры#

Удалить при отмене назначения#

Это конфигурация по умолчанию. Он использует только asIs сопоставления.

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <existence>
                    <outbound>
                        <expression>
                            <asIs/>
                        </expression>
                    </outbound>
                </existence>
                <administrativeStatus>
                    <outbound>
                        <expression>
                            <asIs/>
                        </expression>
                    </outbound>
                </administrativeStatus>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

Отключить при отмене назначения#

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

Использование переменной focusExists в сопоставлении существования вызывает удаление учетной записи при удалении связанного пользователя. Его можно изменить на фиксированное значение true, если учетная запись должна оставаться там даже после удаления пользователя.

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <existence>
                    <outbound>
                        <expression>
                            <path>$focusExists</path>
                        </expression>
                    </outbound>
                </existence>
                <administrativeStatus>
                    <outbound>
                        <expression>
                            <script>
                                <code>
                                    import com.evolveum.midpoint.xml.ns._public.common.common_3.ActivationStatusType
                                    if (legal &amp;&amp; assigned) {
                                    input
                                    } else {
                                    ActivationStatusType.DISABLED
                                    }
                                </code>
                            </script>
                        </expression>
                    </outbound>
                </administrativeStatus>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

Ограничения времени маппинга#

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

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

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <existence>
                    <outbound>
                        <name>Default existence</name>
                        <description>
                            Default existence mapping needs to specified explicitly here.
                            It is also set to be weak therefore the other mapping will take precedence.
                        </description>
                        <strength>weak</strength>
                        <expression>
                            <asIs/>
                        </expression>
                    </outbound>
                    <outbound>
                        <name>Delayed delete</name>
                        <description>
                            This mapping will be used only one month after the account is disabled.
                            It result is constant "false" which causes the account to stop existing.
                        </description>
                        <timeFrom>
                            <referenceTime>
                                <path>$shadow/activation/disableTimestamp</path>
                            </referenceTime>
                            <offset>P1M</offset>
                        </timeFrom>
                        <source>
                            <path>$shadow/activation/administrativeStatus</path>
                        </source>
                        <expression>
                            <value>false</value>
                        </expression>
                        <condition>
                            <script>
                                <code>
                                    import com.evolveum.midpoint.xml.ns._public.common.common_3.ActivationStatusType
                                    administrativeStatus == ActivationStatusType.DISABLED
                                </code>
                            </script>
                        </condition>
                    </outbound>
                </existence>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

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

<resource>
    <schemaHandling>
        <objectType>
            
            <activation>
                <existence>
                    <outbound>
                        <name>Basic existence</name>
                        <description>
                            The default for account existence in this case is the existence of focus object (user).
                            Is user exists, account should exist too. Also note that this mapping is weak which
                            lets the other mapping to take precedence.
                        </description>
                        <strength>weak</strength>
                        <expression>
                            <path>$focusExists</path>
                        </expression>
                    </outbound>
                    <outbound>
                        <name>Pre-create</name>
                        <description>
                            The mapping above would cause the account to exist as soon as user appears.
                            But we want to override that and prohibit account existence all the way up to
                            5 days before user's validFrom. This mapping does right that.
                        </description>
                        <timeTo>
                            <referenceTime>
                                <path>$focus/activation/validFrom</path>
                            </referenceTime>
                            <offset>-P5D</offset>
                        </timeTo>
                        <source>
                            <path>$focus/activation/validFrom</path>
                        </source>
                        <expression>
                            <value>false</value>
                        </expression>
                        <condition>
                            <description>
                                This condition is not really necessary if all the uses will have a validFrom timestamp.
                                But if there is a user without validFrom then this mapping will be applied
                                indefinitely and the account will never be created. We want to avoid that.
                            </description>
                            <script>
                                <code>validFrom != null</code>
                            </script>
                        </condition>
                    </outbound>
                </existence>
                <administrativeStatus>
                    <outbound>
                        <description>
                            This mapping will make sure that if an account is created without a valid assignment
                            (legal=false) then such account will be disabled. We need that because we are pre-provisioning
                            accounts and we want them disabled when they are pre-provisioned.
                        </description>
                        <strength>strong</strength>
                        <expression>
                            <script>
                                <code>
                                    import com.evolveum.midpoint.xml.ns._public.common.common_3.ActivationStatusType
                                    if (legal &amp;&amp; assigned) {
                                    input
                                    } else {
                                    ActivationStatusType.DISABLED
                                    }
                                </code>
                            </script>
                        </expression>
                    </outbound>
                </administrativeStatus>
            </activation>
            
        </objectType>
    </schemaHandling>
</resource>

Входящие маппинги#

Состояние активации может быть синхронизировано в противоположном направлении (из ресурса в IDM). Для этого используются входящий маппинги…

В следующем примере

состояние пользователя из IDM синхронизируется со состоянием учетной записи ресурса (исходящей) без изменений;
состояние учетной записи ресурса синхронизируется с пользователем IDM (входящим), но только если состояние пользователя IDM пусто (например, при первом создании пользователя IDM из учетной записи ресурса).

Учетная запись ресурса не будет иметь полномочий для состояния учетной записи, кроме первой синхронизации.

<activation>
    <administrativeStatus>
        <outbound>
            <expression>
                <asIs/>
            </expression>
        </outbound>
        <inbound>
            <strength>weak</strength>
            <expression>
                <asIs/>
            </expression>
        </inbound>
    </administrativeStatus>
</activation>

Параметры source и target отображений опущены, потому что применяются значения по умолчанию:

Исходное отображение имеет источник свойства пользователя activation/administrativeStatus, а целью является то же свойство учетной записи ресурса.
Входные сопоставления имеют те же самые, но в обратном порядке: источником является свойство учетной записи ресурса, а целью - свойство пользователя.

asIs expression также является необязательным и может быть опущен, что приводит к следующему результату:

<activation>
    <administrativeStatus>
        <outbound/>
        <inbound>
            <strength>weak</strength>
        </inbound>
    </administrativeStatus>
</activation>