
Federation protocols in keystone are very confusing due to the way they have evolved since the original service provider implementation where the auth plugin was defined in saml2.py. We renamed saml2.py to mapped.py[1] and now we can effectively support any federation protocol as long as there is some kind of Apache module that can understand it and pass certain IdP and user attributes through to keystone. So we started recommending not using the 'saml2' auth plugin and instead using the 'mapped' plugin, eventually removing the the notice when we removed the plugin[2]. Since the name of the federation protocol resource created in keystone must match one of the [auth]/methods, we also changed the documentation to start creating the 'mapped' protocol and use 'mapped' in the Apache settings[3]. This was really the wrong course. 'mapped' is not a protocol. Using only 'mapped' prevents us from defining multiple remote_id_attributes for different protocols. This patch changes references to the 'mapped' protocol and 'mapped' plugin back to 'saml2' (we never changed the openid ones). While the saml2 plugin does not itself exist, it is defined as an entrypoint to the mapped plugin, so it all works out. This doesn't solve the problem for if we want to define different remote_id_attributes for different SAML2.0 implementations, but there is a workaround for that[4]. Using 'saml2' as the protocol name is just much more intuitive than 'mapped'. [1] https://git.openstack.org/cgit/openstack/keystone-specs/tree/specs/keystone/juno/generic-mapping-federation.rst [2] https://review.openstack.org/#/c/397456/ [3] https://review.openstack.org/#/c/371210/ [4] https://bugs.launchpad.net/keystone/+bug/1724645/comments/1 Change-Id: I23fc3f1f651c12c4e3c1987dc71008e6e97b4ed8 Related-bug: #1724645
Team and repository tags
OpenStack Keystone
Keystone provides authentication, authorization and service discovery mechanisms via HTTP primarily for use by projects in the OpenStack family. It is most commonly deployed as an HTTP interface to existing identity systems, such as LDAP.
Developer documentation, the source of which is in
doc/source/
, is published at:
The API specification and documentation are available at:
The canonical client library is available at:
https://git.openstack.org/cgit/openstack/python-keystoneclient
Documentation for cloud administrators is available at:
The source of documentation for cloud administrators is available at:
Information about our team meeting is available at:
Bugs and feature requests are tracked on Launchpad at:
Future design work is tracked at:
https://specs.openstack.org/openstack/keystone-specs/#identity-program-specifications
Contributors are encouraged to join IRC
(#openstack-keystone
on freenode):
For information on contributing to Keystone, see
CONTRIBUTING.rst
.