Simulated Disable
Last modified 15 Nov 2021 11:25 +01:00

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 it 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.

DatabaseTable Example

Let’s illustrate that using an example. Let’s have a database table that looks like this:

ID FULL_NAME STATUS

jack

Jack Sparrow

1

will

Will Turner

1

barbossa

Hector Barbossa

0

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:

<account>
    ...
    <attributes>
        <icfs:uid>jack</icfs:uid>
        ...
        <ri:FULL_NAME>Jack Sparrow</ri:FULL_NAME>
        <ri:STATUS>1</ri:STATUS>
    </attributes>
</account>

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:

<account>
    ...
    <attributes>
        <icfs:uid>jack</icfs:uid>
        ...
        <ri:FULL_NAME>Jack Sparrow</ri:FULL_NAME>
    </attributes>
    <activation>
      <administrativeStatus>enabled</administrativeStatus>
    </activation>
</account>

Fortunately this is very easy to do in midPoint. Just add this section to Resource Capabilities section:

   <capabilities xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-2">
        <configured>
            <cap:activation>
                <cap:status>
                    <cap:attribute>ri:STATUS</cap:attribute>
                    <cap:enableValue>1</cap:enableValue>
                    <cap:disableValue>0</cap:disableValue>
                </cap:status>
            </cap:activation>
        </configured>
    </capabilities>

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 administrativeStatus property.

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 Example

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:

    <capabilities xmlns:cap="http://midpoint.evolveum.com/xml/ns/public/resource/capabilities-2">
        <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>
        </configured>
    </capabilities>

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.

See Also

Was this page helpful?
YES NO
Thanks for your feedback