Create user with LDAP enabled_mask, enabled not boolean

Bug #1220945 reported by Brant Knudson on 2013-09-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Medium
Brant Knudson

Bug Description

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.

Brant Knudson (blk-u) on 2013-09-04
Changed in keystone:
assignee: nobody → Brant Knudson (blk-u)

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

Changed in keystone:
status: New → In Progress

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

Dolph Mathews (dolph) wrote :

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

That's certainly a bug.

Changed in keystone:
milestone: none → havana-rc1
importance: Undecided → Medium

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

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

Changed in keystone:
status: In Progress → Fix Committed
Thierry Carrez (ttx) on 2013-10-02
Changed in keystone:
status: Fix Committed → Fix Released
Thierry Carrez (ttx) on 2013-10-17
Changed in keystone:
milestone: havana-rc1 → 2013.2
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers