<resource> ... <schemaHandling> ... <objectType> ... <protected> <filter> <q:equal> <q:matching>stringIgnoreCase</q:matching> <q:path> declare namespace ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"; attributes/ri:carLicense </q:path> <q:value>ignoreme</q:value> </q:equal> </filter> </protected> ... </objectType> </schemaHandling> </resource>
MidPoint can protect specific accounts against any change. Such accounts cannot be modified or deleted from midPoint, they will not appear in searches (imports), they will not be reconciled or otherwise synchronized and midPoint will even not be able to read them.
This feature is used to make sure that midPoint will not destroy vital accounts such as
administrator. MidPoint is very flexible, using expressions and complex policies for provisioning.
It may be easy to make a mistake and e.g. unintentionally disable such accounts.
This may happen especially while the policies are constructed during midPoint deployment.
Therefore midPoint provides a mechanism that limits possible impact of misconfiguration.
This mechanism is called protected accounts.
Protected accounts may be specified per-resource.
The definition is part of account definition in the
Following code provides an example of such definition:
The above example will protect accounts with
carLicense attribute equal to "ignoreme" string.
<resource> ... <schemaHandling> ... <objectType> ... <protected> <filter> <q:substring> <q:matching>stringIgnoreCase</q:matching> <q:path> declare namespace icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"; attributes/icfs:name </q:path> <q:value>ou=SUPERSECRET,dc=example,dc=com</q:value> <q:anchorEnd>true</q:anchorEnd> </q:substring> </filter> </protected> ... </objectType> </schemaHandling> </resource>
The final example will protect all accounts under "OU=SUPERSECRET,dc=example,dc=com" subtree.
Protected accounts will be shown in midPoint, but such accounts will be clearly marked as protected. Any operation that attempts to modify or delete them will fail. Protected accounts will be ignored in import, live sync, reconciliation or any other synchronization mechanism.
Why we need shadows for protected accounts?
Protected accounts are fetched into midpoint and there is a shadow for each protected account. MidPoint needs to be aware about protected accounts to know that the identifier belonging to the protected account is already taken. While the protected accounts are currently explicitly enumerated the method of protected account specification may be extended in the future (e.g. specifying a filter). In such a case the midPoint will not be able to handle identifier allocation correctly without having shadows for protected accounts. There are also other reasons e.g. to correctly display account lists in GUI, auditing and overall this is better for visibility into the IDM solution.
Prior to midPoint 4.0 the following notation was possible:
<resource> ... <schemaHandling> ... <objectType> ... <protected> <icfs:name>root</icfs:name> </protected> <protected> <icfs:name>daemon</icfs:name> </protected> ... </objectType> </schemaHandling> </resource>
Support for this notation was removed in midPoint 4.0.