Allow LDAP account lock attributes to be used as enable attributes

[Nathan Kinder]

Some LDAP servers support disabling accounts via a boolean "lock" attribute. For these servers, a value in LDAP of "True" means that the account is locked, while a value of "False" means the account is active. Keystone currently expects a boolean "enabled" attribute where "True" means the account is enabled and "False" means the account is disabled.

To support LDAP account lock attributes, we need a way to tell Keystone that the boolean values from LDAP are inverted. This will avoid the need for an admin to create custom schema for a new "enabled" attribute or to use the emulated enabled group feature (which adds significant LDAP operation overhead as seen by packet capture).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/104408

[John Edrington (jedrington)]

Hi Nathan,

I really like the proposed change to support a lock attribute. I do have one suggestion: instead of just inverting the evaluation of True / False, perhaps another solution would be to allow the admin to define the string value of the specified enabled attribute which should be interpreted as "enabled" and any other value would represent disabled .

This logic would support cases where the attribute is neither a boolean nor bitmask integer, but rather an arbitrary string value. (Like "UserDisabled = no" or "UserEnabled = yes").

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/104408
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=25ec22d281619db25556ed1c8271ae3ee5b45914
Submitter: Jenkins
Branch: master

commit 25ec22d281619db25556ed1c8271ae3ee5b45914
Author: Nathan Kinder <email address hidden>
Date: Wed Jul 2 18:36:40 2014 -0700

    Allow LDAP lock attributes to be used as enable attributes

    Some LDAP servers support disabling accounts via a boolean "lock"
    attribute. For these servers, a value in LDAP of "True" means that
    the account is locked, while a value of "False" means the account
    is active. When the "user_enabled_mask" and "user_enabled_emulation"
    options are not in use, Keystone currently expects a boolean
    "enabled" attribute where "True" means the account is enabled and
    "False" means the account is disabled.

    To support LDAP account lock attributes, we need a way to tell
    Keystone that the boolean values from LDAP are inverted. This
    adds a new "user_enabled_invert" setting that allows the enabled
    boolean logic to be inverted in the resource (LDAP), while leaving
    the logic as-is in the model (Keystone user object). The existing
    default behavior remains as-is.

    DocImpact
    Change-Id: I2a89d4b98c854e68e1bb10f53b8b29d92f945f60
    Closes-bug: #1337029