Any attribute that is equal to 'TRUE' or 'FALSE' is treated as boolean by LDAP drivers

[Henry Nash]

Our core LDAP driver makes a dangerous assumption that any attribute that is equal to the string 'TRUE' or 'FALSE' must be a boolean and will covert the value accordingly. For instance the following test:

    def test_hn1(self):
        ref = {
            'name': 'TRUE',
            'domain_id': CONF.identity.default_domain_id}
        ref = self.identity_api.create_user(ref)
        ref1 = self.identity_api.get_user(ref['id'])
        self.assertEqual(ref ,ref1)

will fail (on an LDAP backend) with:

MismatchError: !=:
reference = {'domain_id': 'default', 'enabled': True, 'id': 'd4202d8717104d2bb2ab49fec5e7fe70', 'name': 'TRUE'}
actual = {'domain_id': 'default', 'enabled': True, 'id': u'd4202d8717104d2bb2ab49fec5e7fe70', 'name': True}

Ouch!

Now that we have a schema for our models, perhaps we should use that to determine whether something is a boolean or not? e.g. for projects, we have:

_project_properties = {
    'description': validation.nullable(parameter_types.description),
    # NOTE(lbragstad): domain_id isn't nullable according to some backends.
    # The identity-api should be updated to be consistent with the
    # implementation.
    'domain_id': parameter_types.id_string,
    'enabled': parameter_types.boolean,
    'parent_id': validation.nullable(parameter_types.id_string),
    'name': {
        'type': 'string',
        'minLength': 1,
        'maxLength': 64
    }
}

For some reason the user/group ones don't exist yet, but we can fix that.

[Lin Hua Cheng (lin-hua-cheng)]

Seems two separate bugs are mentioned here:

1. adding user/group schema
2. how the object from LDAP backend are converted to python objects

I opened a separate bug for #1: https://bugs.launchpad.net/keystone/+bug/1415694

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/154722
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=5b82b8ab6fd181124b9fb0fdb5f8ab76ff715435
Submitter: Jenkins
Branch: master

commit 5b82b8ab6fd181124b9fb0fdb5f8ab76ff715435
Author: lin-hua-cheng <email address hidden>
Date: Tue Feb 10 17:27:55 2015 -0800

    Don't try to convert LDAP attributes to boolean

    Currently, in the ldap2py function, attribute values are attempted
    to be converted to python friendly types.

    It attempts to convert an attribute to boolean first, then fallback
    as string. Any attribute value that is equal to 'TRUE' or 'FALSE'
    are converted to boolean value.

    Only 'enabled' attribute require this type of handling, and it is
    already by enabled2py function. The additional handling on ldap2py
    function should be removed.

    Change-Id: Ifd1e91f98ae22a5e5f7b9b2ddbfddba156e16a6d
    Closes-Bug: #1411478

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/156006

[Dolph Mathews (dolph)]

Before we backport this to stable/juno, are there any legitimate use cases where people would be depending on the old behavior? Just want to ensure there's no risk to backporting.

[Morgan Fainberg (mdrnstm)]

I think that we have odd behavior on either side: with or without the fix.

Either the deployer has mapped an attribute assuming it gets converted to a Boolean or they have not used a "Boolean" strong anywhere in name or description because of this issue

It is likely the more correct route is to be explicit about where things are converted to Boolean vs always assuming "true" or "false" strings are meant o be booleans

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/156006
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=027236c5815f45a65f92be5e5dfa543bff1ae935
Submitter: Jenkins
Branch: stable/juno

commit 027236c5815f45a65f92be5e5dfa543bff1ae935
Author: lin-hua-cheng <email address hidden>
Date: Tue Feb 10 17:27:55 2015 -0800

    Don't try to convert LDAP attributes to boolean

    Currently, in the ldap2py function, attribute values are attempted
    to be converted to python friendly types.

    It attempts to convert an attribute to boolean first, then fallback
    as string. Any attribute value that is equal to 'TRUE' or 'FALSE'
    are converted to boolean value.

    Only 'enabled' attribute require this type of handling, and it is
    already by enabled2py function. The additional handling on ldap2py
    function should be removed.

    Change-Id: Ifd1e91f98ae22a5e5f7b9b2ddbfddba156e16a6d
    Closes-Bug: #1411478
    (cherry picked from commit 5b82b8ab6fd181124b9fb0fdb5f8ab76ff715435)