Domain name update breaks IDP configuration

[Prateek Jassal]

The configuration file for an identity provider eg. LDAP is generally named as keystone.<domain_name>.conf.
Since Keystone allows a user to update a domain name, any domain name update makes this file for that domain name irrelevant. This file is not automatically renamed via Keystone and I tried to look around in the documentation and this seems to be the only way to configure an LDAP IDP. Manual renaming of all such config files for domains seems like an overhead.

[Dolph Mathews (dolph)]

I completely agree, the current design directly results in the fragility you described (I pushed for naming domain-specific configuration files using their immutable, system-defined domain IDs instead, but lost that argument... I think on the basis of deployer experience? I'll let Henry Nash comment further).

As a workaround, you could set the "identity:update_domain" to be more restrictive (to users that understand the impact of such a change), or disallow it completely.

I'm leaving this as Won't Fix, as the only alternative solution I can think of is introducing a new configuration option that determines whether configuration files are named using domain names or IDs, which doesn't quite seem worth it (just to provide backwards compatibility... unless someone has a better idea? if so, please change the status accordingly).

[Brant Knudson (blk-u)]

Another option is to change keystone so that if you try to rename a domain and it's got a config file then the config file is automatically renamed, too. Or we disallow changing the name of a domain that's got a config file.

We've got domain config in SQL now so if you don't like how it works with config files then put your domain config in SQL instead.

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

I think disallowing changing the name of a domain that's got a config file is better. Automatically renaming may not work or is not easy if the deployer have a copy of the config file per keystone node instead of storing one file in the network file (this is all depending how their deployment tool is setup).

[Prateek Jassal (prateek-jassal)]

@Dolph: Thanks for confirming the issue. In our environment, we do not want to ideally restrict the user operations.

@Lin Hua Cheng: I agree. Renaming would need to happen at all instances. That would be the best way only if Keystone itself would have managed that.

@Brant: I got the first part where you talked about renaming the config file automatically when a domain is renamed by changing the core Keystone code. I didn't however get what you meant by having the domain config in SQL, how does Keystone detect the domain config files in SQL automatically ? Did you tweak something within Keystone or is that possible without modifying Keystone itself.