Using LDAP with enabled ignored, no error when attempt to change

Bug #1241134 reported by Brant Knudson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Fix Released
Medium
Brant Knudson
Juno
Fix Released
Undecided
Unassigned

Bug Description

When the Keystone server is configured to use LDAP as the identity backend and 'enabled' is in user_attribute_ignore and then the user is disabled (for example with keystone user-update --enabled false), the server returns successful and the command doesn't report an error even though the user remains enabled.

The server should report an error like 403 Forbidden or 501 Not Implemented if the user tries to change the enabled attribute and it's ignored.

This would improve security since the way it is now Keystone gives the impression that the user has been disabled even when they have not been.

Revision history for this message
Dolph Mathews (dolph) wrote :
tags: added: ldap
Changed in keystone:
importance: Undecided → Medium
status: New → Triaged
tags: added: user-experience
Changed in keystone:
assignee: nobody → Scott W Jewloszewicz-Clarke (scottwjclarke)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to keystone (master)

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

Changed in keystone:
assignee: Scott W Jewloszewicz-Clarke (scottwjclarke) → Brant Knudson (blk-u)
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Dolph Mathews (dolph)
tags: added: icehouse-backport-potential juno-backport-potential
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to keystone (master)

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

commit b62a445af84c6053629132f2e726450658f62c87
Author: Brant Knudson <email address hidden>
Date: Thu Dec 11 15:27:11 2014 -0600

    Add test for update role without name

    There was no test that showed what happens when a role update is done
    without a name. The test shows that when using the LDAP assignment
    backend a role update without a name raises an exception.

    Change-Id: I9ca7d1af432cec2f0dcc5833e196f5e1e18a8013
    Partial-Bug: #1241134

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

commit 93ab08a46bbf5d466b1a12fe9691565ec10b1179
Author: Brant Knudson <email address hidden>
Date: Thu Dec 11 15:40:36 2014 -0600

    Fix update role without name using LDAP

    When the keystone server was configured to use the LDAP assignment
    backend and a role was updated and no name was included in the update
    dict the operation would fail with a 500 Internal Server Error.

    With this fix, an update without a name works.

    Change-Id: I234a36301a54ad4796cd421c42e85b15e9415902
    Closes-Bug: #1241134

Changed in keystone:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

commit 4442671ffc2cad9b7d688a13aefb266873dfec0d
Author: Brant Knudson <email address hidden>
Date: Wed Dec 10 19:46:48 2014 -0600

    Add tests for enabled attribute ignored

    There were no tests that showed what happened when the enabled
    attribute is ignored for the LDAP backend for various entities.

    The tests show that if the client tries to disable the entity the
    entity actually remains enabled.

    Change-Id: I48608f772456ade05318170d3615920d664d7dd2
    Partial-Bug: #1241134

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

commit e62de2c91b5755149146a47e84e61d3642095998
Author: Brant Knudson <email address hidden>
Date: Thu Dec 11 10:40:16 2014 -0600

    Fix disabling entities when enabled is ignored

    When LDAP is configured so that the `enabled` attribute was ignored
    for an entity (user, group, role, project) and a client attempts to
    disable the entity, it remains enabled, so a user might think that the
    entity was disabled when it's not.

    With this change, attempting to disable an entity where `enabled` is
    ignored will return a 403 Forbidden error.

    Since entities are always enabled when the `enabled` attribute is
    ignored, there's no change to reject changes that attempt to enable
    the entity.

    Closes-Bug: #1241134

    SecurityImpact
    This is for security hardening.

    Change-Id: I8cb3326952d6e379a457c19d7f8f5f9ee4b29eb0

Thierry Carrez (ttx)
Changed in keystone:
milestone: none → kilo-1
status: Fix Committed → Fix Released
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/142551

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

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

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

commit d6ded70f2a66a1e1eb2a7ee0cc18f864bd0e99e5
Author: Brant Knudson <email address hidden>
Date: Thu Dec 11 15:27:11 2014 -0600

    Add test for update role without name

    There was no test that showed what happens when a role update is done
    without a name. The test shows that when using the LDAP assignment
    backend a role update without a name raises an exception.

    (cherry picked from commit b62a445af84c6053629132f2e726450658f62c87)

    Backport note: Test override was added to test_backend_kvs.KVSIdentity
    because the KVS backend doesn't exist in Juno and it fails the same way as LDAP.

    Change-Id: I9ca7d1af432cec2f0dcc5833e196f5e1e18a8013
    Partial-Bug: #1241134

tags: added: in-stable-juno
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/142552
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=1594c845497ee27a596ad324343e503cc4f0595c
Submitter: Jenkins
Branch: stable/juno

commit 1594c845497ee27a596ad324343e503cc4f0595c
Author: Brant Knudson <email address hidden>
Date: Thu Dec 11 15:40:36 2014 -0600

    Fix update role without name using LDAP

    When the keystone server was configured to use the LDAP assignment
    backend and a role was updated and no name was included in the update
    dict the operation would fail with a 500 Internal Server Error.

    With this fix, an update without a name works.

    (cherry picked from commit 93ab08a46bbf5d466b1a12fe9691565ec10b1179)

    Change-Id: I234a36301a54ad4796cd421c42e85b15e9415902
    Closes-Bug: #1241134

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/142553
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=85c658f21fdab80ab6390f81574ca861bc4b51eb
Submitter: Jenkins
Branch: stable/juno

commit 85c658f21fdab80ab6390f81574ca861bc4b51eb
Author: Brant Knudson <email address hidden>
Date: Wed Dec 10 19:46:48 2014 -0600

    Add tests for enabled attribute ignored

    There were no tests that showed what happened when the enabled
    attribute is ignored for the LDAP backend for various entities.

    The tests show that if the client tries to disable the entity the
    entity actually remains enabled.

    (cherry picked from commit 4442671ffc2cad9b7d688a13aefb266873dfec0d)

    Change-Id: I48608f772456ade05318170d3615920d664d7dd2
    Partial-Bug: #1241134

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

commit fc6e9e8d2c07f35d995af20fa112f19b47c22bdb
Author: Brant Knudson <email address hidden>
Date: Thu Dec 11 10:40:16 2014 -0600

    Fix disabling entities when enabled is ignored

    When LDAP is configured so that the `enabled` attribute was ignored
    for an entity (user, group, role, project) and a client attempts to
    disable the entity, it remains enabled, so a user might think that the
    entity was disabled when it's not.

    With this change, attempting to disable an entity where `enabled` is
    ignored will return a 403 Forbidden error.

    Since entities are always enabled when the `enabled` attribute is
    ignored, there's no change to reject changes that attempt to enable
    the entity.

    Closes-Bug: #1241134

    SecurityImpact
    This is for security hardening.

    (cherry picked from commit e62de2c91b5755149146a47e84e61d3642095998)

    Change-Id: I8cb3326952d6e379a457c19d7f8f5f9ee4b29eb0

Thierry Carrez (ttx)
Changed in keystone:
milestone: kilo-1 → 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.