<capabilities>
<cachingMetadata>...</cachingMetadata>
<native>
<cap:script>
<cap:host>
<cap:type>connector</cap:type>
</cap:host>
</cap:script>
<cap:credentials>
<cap:password/>
</cap:credentials>
<cap:testConnection/>
<cap:liveSync/>
</native>
<configured>
<cap:activation>
<cap:status>
<cap:attribute>ri:ds-pwp-account-disabled</cap:attribute>
<cap:enableValue/>
<cap:disableValue>true</cap:disableValue>
</cap:status>
</cap:activation>
<cap:liveSync>
<cap:enabled>false</cap:enabled>
</cap:liveSync>
</configured>
</capabilities>Resource Capabilities
Capabilities are definitions of a specific things that a resource can do.
There is plethora of various resource types and configuration.
Some resources can enable/disable an account, while others cannot.
Some resource can provide live feed of changes, some cannot.
The capabilities section lists the features that the resource has.
There are two sections of capabilities definition:
-
Native capabilities are native to the resource. There are the things that resource can do all by itself without any help from midPoint. The list of native capabilities is provided by the connector and does not need to be configured. It is stored in the resource object for performance reasons. If this section is not present in the resource configuration it will be automatically fetched from the resource before its first use.
-
Configured capabilities are decision of an administrator how to use native capabilities. This section can be used to disable native capabilities or add capabilities. Some capabilities can be simulated by midPoint. E.g., a resource does not support account enable/disable directly. But administrator know that the enable/disable may be done by flipping a boolean value of a specific attribute. Such simulated capability can be configured in this section. MidPoint will then pretend that the resource has the enable/disable ability. But each time the ability us used it will transparently convert the operation to modification of the special attribute. That’s how midPoint simulates some capabilities.
These two sections are added together to form presented capabilities (or just "capabilities"). These are all the features that the resource can do by itself (native capabilities), minus the capabilities that were disabled, plus the capabilities that are simulated. GUI, IDM model and business logic will all work only with presented capabilities, whether the capability is native or simulated does not matter for such upper system layers.
The following example shows a configuration for a simulated activation capability using OpenDJ ri:ds-pwp-account-disabled attribute (the value true means, the OpenDJ account is disabled; empty value means, the OpenDJ account is enabled) and a configuration for disabling liveSync capability.
The resource would ignore tha liveSync capability as if it would not be supported by the connector.
LDAP Resource Capabilities Example
The capabilities can be used also to disable provisioning operations on the resource, e.g. during imports, reconciliation etc.
The following example shows a configuration for a resource, where no create or delete operations are possible, only update.
Attempt to create or delete any object on the resource would fail with an error.
<capabilities xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3">
<configured>
<cap:create>
<cap:enabled>false</cap:enabled>
</cap:create>
<cap:update>
<cap:enabled>true</cap:enabled>
</cap:update>
<cap:delete>
<cap:enabled>false</cap:enabled>
</cap:delete>
</configured>
</capabilities>Keep in mind the capabilities section works as override.
For example if you explicitly override update and set enabled to true, you are explicitly setting the capability to read/replace mode.
In case you would like to enable advanced logic for delta or addRemoveAttributeValues you have to set them explicitly to true.
<configured xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3">
<cap:update>
<cap:enabled>true</cap:enabled>
<cap:delta>true</cap:delta>
<cap:addRemoveAttributeValues>true</cap:addRemoveAttributeValues>
</cap:update>
</configured>Another example: Precise token value in Live synchronization
As another example let’s consider preciseTokenValue property in cap:liveSync capability:
<capabilities xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3">
<configured>
<cap:liveSync>
<cap:preciseTokenValue>true</cap:preciseTokenValue>
</cap:liveSync>
</configured>
</capabilities>This tells midPoint that the resource provides live synchronization capability with the additional assurance that token values that are attached to each change emitted by the resource are precise enough to guarantee correct restart of live synchronization process after processing of each given change. If this information is not present, midPoint restarts live synchronization (in case of suspension or failure) at the same place where it was started, instead where it was stopped.
Some resources are known to provide precise token values, others are known of not doing so (e.g. for performance reasons). Others - e.g. those served by ScriptedSQL connector - depend on particular configuration of the connector. It is the responsibility of the connector user (that configures the resource) to know the behavior of the connector, and to correctly specify this capability in the resource definition.
See also Live Synchronization.
Supported capabilities
The following tables summarize the capabilities that are supported as native or configured ones.
| Subtype | Description |
|---|---|
AbstractWriteCapabilityType |
Base type for all write capabilities. |
ActivationCapabilityType |
Describes capability to process activation data, which means enable/disable of accounts, dates for scheduled enable/disable and similar things related to make the account active. |
ActivationLockoutStatusCapabilityType |
Describes capability to provide lockout status (e. |
ActivationStatusCapabilityType |
Describes capability to provide activation status (e. |
ActivationValidityCapabilityType |
Describes capability to provide activation validity dates (validFrom, validTo) |
AddRemoveAttributeValuesCapabilityType |
Indication that ADD and REMOVE of attribute values is reliably supported. |
AsyncUpdateCapabilityType |
Describes capability to process asynchronous updates. |
AuxiliaryObjectClassesCapabilityType |
Describes capability to specify additional (auxiliary) object classes in addition to the primary object class. |
BehaviorCapabilityType |
Container for various behavior-related capabilities. |
CountObjectsCapabilityType |
Ability to efficiently count objects. |
CredentialsCapabilityType |
Describes capability to present credentials in a structured way. |
DiscoverConfigurationCapabilityType |
Describes capability to do configuration discovery, check and recommendation
( |
LastLoginTimestampCapabilityType |
Describes capability of resource to provide last login timestamp. |
LiveSyncCapabilityType |
Describes capability to detect changes in almost real time (live synchronization). |
PagedSearchCapabilityType |
How to handle paged searches. |
PasswordCapabilityType |
Describes capability to present password in a structured way. |
ReadCapabilityType |
Describes read capability. |
ReferencesCapabilityType |
|
RunAsCapabilityType |
Describes capability to execute operations with specified identity. |
SchemaCapabilityType |
Describes capability to discover resource schema. |
ScriptCapabilityType |
Describes capability to execute scripts (short pieces of program) on the connector or resource. |
TestConnectionCapabilityType |
Describes capability to test connection to the resource once the connector is configured. |
Behavior Capability
The BehaviorCapabilityType is a container for various behavior-related capabilities.
Currently, it contains only one capability lastLoginTimestamp.
Last Login Timestamp Capability
As name suggest, last login timestamp provides timestamp of last login for specific object on resource, most often account.
This capability is natively recognized by midPoint if the resource object has attribute with name _LAST_LOGIN_DATE_ attribute (long).
Last login timestamp capability can be also manually configured to point to different attribute using attribute element.
If attribute is string type, then format element can be used to specify format of the timestamp.
It also allows to specify whether such attribute should be listed or omitted in attributes via ignoreAttribute flag.
Example of configured last login timestamp capability
<capabilities xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-3"
xmlns:ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3">
<configured>
<cap:behavior>
<cap:lastLoginTimestamp>
<cap:attribute>ri:myLastLoginTimestampAttributeName</cap:attribute>
<cap:format>yyyy-MM-dd'T'HH:mm:ss.SSSXXX</cap:format>
<cap:ignoreAttribute>true</cap:ignoreAttribute>
</cap:lastLoginTimestamp>
</cap:behavior>
</configured>
</capabilities>Was this page helpful?
YES
NO
Thanks for your feedback