After digging into this, I think I figured out why this is happening.
In the example, I configured keystone to have an external authentication method. This allows users to use x509 certificates to authenticate, offloading the validation of the certificate to apache plugins. The data is then passed into keystone in the form of a request context.
Keystone process the request context using middleware, which executes before the actual code in keystone's authentication API. The middleware determines if the request was authenticated using tokenless authentication methods and fires off a call to the tokenless authentication helper class, which handles its own mapping logic[0][1][2][3][4][5]. The tokenless helper class doesn't reuse the Mapped plugin that gets used for other protocols, like SAML. The Mapped plugin is what actually has support for auto-provisioning [6].
The auto-provisioning feature was implemented after the x509 authentication plugin. So this was likely due to the fact that there were two mapping implementations, and one wasn't as well known.
We could try and get all protocols using the same mapping implementation moving forward. This would make it so we're less susceptible to these kinds of issues moving forward and makes using x509 more useful.
After digging into this, I think I figured out why this is happening.
In the example, I configured keystone to have an external authentication method. This allows users to use x509 certificates to authenticate, offloading the validation of the certificate to apache plugins. The data is then passed into keystone in the form of a request context.
Keystone process the request context using middleware, which executes before the actual code in keystone's authentication API. The middleware determines if the request was authenticated using tokenless authentication methods and fires off a call to the tokenless authentication helper class, which handles its own mapping logic[0] [1][2][ 3][4][5] . The tokenless helper class doesn't reuse the Mapped plugin that gets used for other protocols, like SAML. The Mapped plugin is what actually has support for auto-provisioning [6].
The auto-provisioning feature was implemented after the x509 authentication plugin. So this was likely due to the fact that there were two mapping implementations, and one wasn't as well known.
We could try and get all protocols using the same mapping implementation moving forward. This would make it so we're less susceptible to these kinds of issues moving forward and makes using x509 more useful.
[0] http:// git.openstack. org/cgit/ openstack/ keystone/ tree/keystone/ server/ flask/request_ processing/ middleware/ auth_context. py?id=e647d6f69 762523d0dfa2813 7a9f11010b550e7 2#n330 git.openstack. org/cgit/ openstack/ keystone/ tree/keystone/ server/ flask/request_ processing/ middleware/ auth_context. py?id=e647d6f69 762523d0dfa2813 7a9f11010b550e7 2#n360 git.openstack. org/cgit/ openstack/ keystone/ tree/keystone/ server/ flask/request_ processing/ middleware/ auth_context. py?id=e647d6f69 762523d0dfa2813 7a9f11010b550e7 2#n436 git.openstack. org/cgit/ openstack/ keystone/ tree/keystone/ server/ flask/request_ processing/ middleware/ auth_context. py?id=e647d6f69 762523d0dfa2813 7a9f11010b550e7 2#n248 git.openstack. org/cgit/ openstack/ keystone/ tree/keystone/ server/ flask/request_ processing/ middleware/ auth_context. py?id=e647d6f69 762523d0dfa2813 7a9f11010b550e7 2#n258 git.openstack. org/cgit/ openstack/ keystone/ tree/keystone/ common/ tokenless_ auth.py? id=e647d6f69762 523d0dfa28137a9 f11010b550e72# n96 git.openstack. org/cgit/ openstack/ keystone/ tree/keystone/ auth/plugins/ mapped. py?id=e647d6f69 762523d0dfa2813 7a9f11010b550e7 2#n109
[1] http://
[2] http://
[3] http://
[4] http://
[5] http://
[6] http://