There are resources that natively support
administrativeStatus activation property. These resources can natively do enable/disable of accounts. There is nothing to do for these resources except for setting up activation mappings.
But there are also resources that do not support the activation at all. Or at least not directly. Typical case is is a resource connected by DatabaseTable connector. The DatabaseTable connector is very generic. And even if the table exposed by the connector does include a status column the connector does not know about it. Therefore it cannot provide this capability. But even though the connector does not provide this capability midPoint can. MidPoint can simulate the capability.
MidPoint can pretend that the connector in fact has an
administrativeStatus activation capability. If midPoint gets a command to disable an account it can convert that operation to a modification of a specific resource attribute. This is called configured capability and it is set up in Resource Capabilities section.
Let's illustrate that using an example. Let's have a database table that looks like this:
All the three columns will be presented as an ordinary account attributes by the DatabaseTable connector (except pehaps for
ID which is an identifier and therefore is slightly extraordinary). Therefore also
STATUS will normally be presented just as a simple string attribute. Like this:
But that's not what we want. The meaning of
STATUS column is like this: if there is value
1 the account is enabled, if there is value
0 the account is disabled. So we actually do not want to present attribute
STATUS. We want to present special activation property
administrativeStatus so all midPoint code will know how to enabled and disable an account. We want this:
Fortunately this is very easy to do in midPoint. Just add this section to Resource Capabilities section:
Once this is configured midPoint will convert any enable/disable operations to the appropriate modification of
STATUS table column. It also works in reverse: when midPoint reads the account it will check the
STATUS column and convert it to the value of
Therefore all that needs to be done is setting up activation mappings for
administrativeStatus property - exactly the same way as if the resource supported the capability in a native way. There is no difference between native and simulated capability for midPoint mapping logic.
LDAP is a standard. That's cool. But the way how to enabled or disable an account is shamefully not standardized. Each and every LDAP server implements its own way. Therefore the LDAP connector cannot support this capability natively. And it needs to be simulated.
Let's have OpenDJ as an example. OpenDJ has an operational attribute
ds-pwp-account-disabled. Account is enabled if this attribute is not present at all. Account is disabled if it is set to
true. This can be achieved with the following configuration:
The strange looking clause
<cap:enableValue/> does the trick. This means that the ds-pwp-account-disabled attribute will have no value at all when the account is enabled. The rest is the same as in previous example.