Comment 2 for bug 1760843

This was brought up in office hours this week [0] and I think the discussion sheds an important point about this constraint.

While the existing implementation doesn't map identity providers to domains 1:1, I'm not sure that's a bad thing. The main purpose behind Ron's patch to add the domain requirement for identity providers was so that shadow users would belong to a domain, instead of just being mapped into the Federated domain. One way to do that was to associate a domain to each identity provider.

Further enforcing the mapping from 1:many (domains -> identity providers) to 1:1 (domains -> identity providers) appears really strict. Also, the current domain requirement within the federation API doesn't have any overlap with authorization. It simply serves as a container for the shadow user, just like how users in SQL get a 'domain' attribute set when they are created, but they aren't actually entitled any authorization on that domain without an explicit role assignment.

Also, even if we make domains and identity providers a 1:1 mapping, that doesn't prevent a user from assuming a role assignment on another domain, or a project within another domain. So, from an authorization perspective, the perception of a 1 identity provider to many domains concept still exists.

Since it's possible to have multiple identity providers point to the same domain, it's going to be a long and tough migration, forcing deployments to reorganize their domain/identity provider structure.

Is there a requirement for a 1:1 mapping that I'm missing? Otherwise, I do agree that the commit message in the original change [1] is inaccurate from a 1:1 perspective, since that's not true, but we could document this relationship in our administrator documentation.

[0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2018-04-10.log.html#t2018-04-10T17:49:54
[1] https://review.openstack.org/#/c/399684/