Create user with LDAP enabled_mask, enabled not boolean

[Brant Knudson]

When set up Keystone to use the LDAP identity backend and set user_enabled_mask to non-zero and then create a user with "enabled" set to 'false', the "enabled" value comes back as a number rather than a boolean. This is unexpected because the SQL backend always returns a boolean.

Here's an example:

$ curl -s \
  -H "X-Auth-Token: $TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"user": {"name": "blk-test1", "enabled": false}}' \
  http://localhost:35357/v3/users | python -mjson.tool
{
    "user": {
        "domain_id": "default",
        "enabled": 514,
        "id": "e5d09e0ff7944b28b151865ed6b300ba",
        "links": {
            "self": "http://192.168.122.176:5000/v3/users/e5d09e0ff7944b28b151865ed6b300ba"
        },
        "name": "blk-test1"
    }
}

-- enabled should be false and not 514.

Here's the output when use the SQL identity backend:

{
    "user": {
        "domain_id": "default",
        "enabled": false,
        "id": "73734048e27545f185e2a37eda08f593",
        "links": {
            "self": "http://192.168.122.176:5000/v3/users/73734048e27545f185e2a37eda08f593"
        },
        "name": "blk-test1"
    }
}

To recreate, set in keystone.conf.sample:
user_enabled_attribute = employeeType
user_enabled_mask = 2
user_enabled_default = 512

Next,
change devstack to not set enabled in lib/keystone,
configure localrc to use LDAP,
start devstack,
and then run the curl command above.

Note that when do an update, the enabled value is a Boolean and the "enabled_nomask" value is returned:

curl -s \
 -X PATCH \
 -H "X-Auth-Token: $TOKEN" \
 -H "Content-Type: application/json" \
 --data '{"user": {"enabled": false}}' \
 http://localhost:35357/v3/users/$USER_ID | python -mjson.tool
{
    "user": {
        "domain_id": "default",
        "enabled": true,
        "enabled_nomask": 512,
        "id": "4c6aebecf60e441dbbdb678405d4f5ab",
        "links": {
            "self": "http://192.168.122.176:5000/v3/users/4c6aebecf60e441dbbdb678405d4f5ab"
        },
        "name": "demo"
    }
}

Creating a user should probably work similarly to this, although I don't see how the enabled_nomask value is useful to anyone.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[Dolph Mathews (dolph)]

> the "enabled_nomask" value is returned
> I don't see how the enabled_nomask value is useful to anyone

That's certainly a bug.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/45320
Committed: http://github.com/openstack/keystone/commit/507dfd48074457333d9519060b965a47c66946fc
Submitter: Jenkins
Branch: master

commit 507dfd48074457333d9519060b965a47c66946fc
Author: Brant Knudson <email address hidden>
Date: Wed Sep 4 17:58:47 2013 -0500

    Fixes for user response with LDAP user_enabled_mask

    This fixes a couple of problems with the returned user object
    when the Keystone server when the LDAP Identity backend is
    configured and the user_enabled_mask setting is not zero.

    First, the returned user had the masked value (e.g., 512) when
    a user was created rather than the actual enabled value (true
    or false).

    Second, the Keystone server was returning the enabled_nomask
    attribute in the user entry when users were listed or updated.

    This change makes it so that the server returns the enabled
    value as a Boolean when a user is created. Also, the
    enabled_nomask attribute is not returned when users are
    listed or updated.

    Change-Id: I8a22aec3377ffd335095e645c1b3d65008dd0cf2
    Closes-bug: #1220945