Public bug reported: In order to set up x509 authentication, operators need to specify trusted issuers in their keystone configuration [0] and they need to specify a REMOTE_DOMAIN attribute through their chosen SSL library [1]. The REMOTE_DOMAIN is then passed into keystone via the request environment and optionally used to namespace the user from REMOTE_USER.
Several releases ago, keystone merged support for auto-generating a domain for each identity provider resource [2]. There is also support for specifying a domain for an identity provider when creating it. The purpose of this very similar to the REMOTE_DOMAIN from SSL, in that federated users coming from a specific identity provider have a domain for their user to be namespaced to. If keystone can use the domain from the configured x509 identity provider, then we might not need to have operators specify REMOTE_DOMAIN in their apache configuration. This also means that users presenting certificates from different trusted_issuers can be mapped into different domains, instead of all being lumped into the REMOTE_DOMAIN. [0] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/conf/tokenless_auth.py?id=e647d6f69762523d0dfa28137a9f11010b550e72#n18 [1] https://docs.openstack.org/keystone/latest/admin/external-authentication.html#configuration [2] https://review.openstack.org/#/c/399684/ ** Affects: keystone Importance: Low Status: Triaged ** Tags: x509 ** Tags added: x509 ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Medium ** Changed in: keystone Importance: Medium => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1813335 Title: x509 configured domains are redundant with auto-generated identity provider domains Status in OpenStack Identity (keystone): Triaged Bug description: In order to set up x509 authentication, operators need to specify trusted issuers in their keystone configuration [0] and they need to specify a REMOTE_DOMAIN attribute through their chosen SSL library [1]. The REMOTE_DOMAIN is then passed into keystone via the request environment and optionally used to namespace the user from REMOTE_USER. Several releases ago, keystone merged support for auto-generating a domain for each identity provider resource [2]. There is also support for specifying a domain for an identity provider when creating it. The purpose of this very similar to the REMOTE_DOMAIN from SSL, in that federated users coming from a specific identity provider have a domain for their user to be namespaced to. If keystone can use the domain from the configured x509 identity provider, then we might not need to have operators specify REMOTE_DOMAIN in their apache configuration. This also means that users presenting certificates from different trusted_issuers can be mapped into different domains, instead of all being lumped into the REMOTE_DOMAIN. [0] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/conf/tokenless_auth.py?id=e647d6f69762523d0dfa28137a9f11010b550e72#n18 [1] https://docs.openstack.org/keystone/latest/admin/external-authentication.html#configuration [2] https://review.openstack.org/#/c/399684/ To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1813335/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
