It's possible to disable the default domain through domain update API

[Lance Bragstad]

We currently forbid the ability of deleting the default domain [0] (or at least make it really hard to do so). There is nothing in the update domain flow that protects against disabling the default domain.

We should add the same check to prevent someone from accidentally disabling the default domain. Otherwise it just exposes the same behavior that we wanted to prevent in the first place.

I was able to recreate this with these steps - http://cdn.pasteraw.com/38uku7bb83dt4prj6f66hc9ccuft0ew

[0] https://github.com/openstack/keystone/blob/45c19fcd8c4cc382a7471432cd9f72b809e1d5b1/keystone/resource/core.py#L526-L532

[Steve Martinelli (stevemar)]

makes sense to fix this, we can easily check that the domain being disabled isn't the same as the default domain option in the config file.

[OpenStack Infra (hudson-openstack)]

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

[Brant Knudson (blk-u)]

why shouldn't I be able to disable the default domain?

[Boris Bobrov (bbobrov)]

++, I don't see any reason to forbid disabling the default domain

[Guang Yee (guang-yee)]

Yes agreed. You should be able to disable the default domain if you want to. Its just another domain. Nothing special about it.

[Dolph Mathews (dolph)]

We currently have code that forbids deleting the default domain.

[Dolph Mathews (dolph)]

And the only thing special about the default domain is that if you were to disable or delete it, the entire v2.0 API would be non-functional.

[Lance Bragstad (lbragstad)]

We discussed this a bit in the #openstack-keystone channel [0].

We can do one of two things, as a result of that conversation.

1.) We can continue with a way to make sure the default domain specified in the configuration file can't be disabled.

2.) We allow the disablement of the default domain, knowing and advertising that this will break the entire v2.0 api. The work-around can be added to re-enable the default domain, and this would have to live within the keystone-manage functionality. Something like `keystone-manage enable_default_domain` or whatever. This wouldn't be tied to authentication, because at the point where the default domain has been disabled, you won't be able to re-enable it operating within that domain.

Thoughts on these two options?

[0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2016-01-06.log.html#t2016-01-06T21:08:57

[OpenStack Infra (hudson-openstack)]

Change abandoned by Dolph Mathews (<email address hidden>) on branch: master
Review: https://review.openstack.org/260067
Reason: Abandoning in favor of https://review.openstack.org/#/c/264342/

[OpenStack Infra (hudson-openstack)]

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

commit 0354fe00db11984da3ce2ae4b4113a1043e6c86d
Author: Navid Pustchi <email address hidden>
Date: Wed Jan 6 20:31:28 2016 +0000

    Delete checks for default domain delete

    Currently defualt can not be deleted through update API.
    There are checks in update_domain to prevent this.

    This change deletes all checks and related tests for deleting
    the default domain, including new default domain and old
    default domain tests.

    Change-Id: I31a9cd7ac8c394b38038343f85f405080ca5f915
    Closes-Bug: 1522616

[Thierry Carrez (ttx)]

This issue was fixed in the openstack/keystone 9.0.0.0b2 development milestone.