Identity Provider domain is not unique

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

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/

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

Reviewed: https://review.openstack.org/559676
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=b6da8a1b8976579e4bf4025b58a69a9be539c847
Submitter: Zuul
Branch: master

commit b6da8a1b8976579e4bf4025b58a69a9be539c847
Author: wangxiyuan <email address hidden>
Date: Mon Apr 9 17:25:14 2018 +0800

    Update IdP sql model

    Base on the database schema, the domain_id column in identity_provider
    is not unique and has the ForeignKey for project.id. But the IdP sql
    model is different. It marks the domain_id is unique and the ForeignKey
    is lost.

    This patch removes the unique restriction and adds the FK back, ultimately
    making the relationship between domains and identity provider 1:many.

    Change-Id: I13ecb0ab0434f5614f31d151e708f299cf8e8adb
    Partial-bug: #1760843

Reviewed: https://review.openstack.org/563812
Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=a7437cae731c0914c4df78590b155f8a272f4139
Submitter: Zuul
Branch: master

commit a7437cae731c0914c4df78590b155f8a272f4139
Author: wangxiyuan <email address hidden>
Date: Tue Apr 24 12:04:16 2018 +0800

    Fix the test for unique IdP

    The test that IdP and domain is unique constraint is wrong.
    Keystone never support Idp:domain is 1:1.

    This patch fixed the error in the test to make sure
    Idp:domain is n:1.

    Change-Id: I90a0ed677aa9d666a220bd2456dac336378cd3ba
    Closes-bug: #1760843

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