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.
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 /review. openstack. org/#/c/ 399684/
[1] https:/