user_enabled_attribute string support is poor

Bug #1415271 reported by Steve Martinelli
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Medium
Steve Martinelli
Juno
Fix Released
Medium
Steve Martinelli

Bug Description

When attempting to authenticate with our ldap, we were running into trouble getting the right value to show up for the user's enabled attribute.

The result from ldap was:
[('uid=123456789,c=us,ou=our_ldap,o=ibm.com', {'mail': ['<email address hidden>'], 'passwordisexpired': ['false'], 'uid': ['123456789']})]

which is turned into:
[(u'uid=123456789,c=us,ou=our_ldap,o=ibm.com', {'mail': [<email address hidden>'], 'passwordisexpired': [u'false'], 'uid': [123456789]})]

the _ldap_res_to_model function in ldap/core.py seems to be OK, but the same one at the identity backend for ldap seems to have a few bugs:

the object before:
{'email': <email address hidden>', 'enabled': u'false', 'id': 123456789, 'name': <email address hidden>'}

the object after:
{'dn': u'uid=123456789,c=us,ou=our_ldap,o=ibm.com', 'email': <email address hidden>', 'enabled': False, 'id': 123456789, 'name': <email address hidden>'}

Note that the enabled field is still False, just a boolean now instead of string.

Looks like at: https://github.com/openstack/keystone/blob/stable/juno/keystone/identity/backends/ldap.py#L223-L227

The check for if type(str) is insufficient, and calling lower, without the parentheses is pointless.

tags: added: juno-backport-potential
tags: added: icehouse-backport-potential
Changed in keystone:
assignee: nobody → Steve Martinelli (stevemar)
status: New → In Progress
tags: removed: icehouse-backport-potential
Revision history for this message
Lance Bragstad (lbragstad) wrote :

Nice catch!

tags: added: ldap
Changed in keystone:
importance: Undecided → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (stable/juno)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

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

commit ad9ecdbab9ab4243477aeac8a92214cb1ac830c6
Author: Steve Martinelli <email address hidden>
Date: Tue Jan 27 19:06:37 2015 -0500

    Fix up _ldap_res_to_model for ldap identity backend

    If a user specifies a user enabled attribute, then conditional
    for checking if it's a string is insufficient, and will always
    come back as False, since it's referencing the method, and not
    actually calling it.

    Closes-Bug: #1415271

    Change-Id: I4ea48929bc175b40ddb706e7750661a57882ed6b

Changed in keystone:
status: In Progress → Fix Committed
Changed in keystone:
milestone: none → kilo-2
Thierry Carrez (ttx)
Changed in keystone:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (stable/juno)

Reviewed: https://review.openstack.org/151411
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=0c7535b233f14fb6788c79b739d7d3b737191904
Submitter: Jenkins
Branch: stable/juno

commit 0c7535b233f14fb6788c79b739d7d3b737191904
Author: Steve Martinelli <email address hidden>
Date: Tue Jan 27 19:06:37 2015 -0500

    Fix up _ldap_res_to_model for ldap identity backend

    If a user specifies a user enabled attribute, then conditional
    for checking if it's a string is insufficient, and will always
    come back as False, since it's referencing the method, and not
    actually calling it.

    Closes-Bug: #1415271
      (cherry picked from commit ad9ecdbab9ab4243477aeac8a92214cb1ac830c6)

    Change-Id: I4ea48929bc175b40ddb706e7750661a57882ed6b

Thierry Carrez (ttx)
Changed in keystone:
milestone: kilo-2 → 2015.1.0
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.