commit cbdc84ac7fc88e891968116db4866dc719337b16
Author: Colleen Murphy <email address hidden>
Date: Sat Oct 21 20:38:34 2017 +0200
Partially clarify federation auth plugins
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'.
Reviewed: https:/ /review. openstack. org/513960 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=cbdc84ac7fc 88e891968116db4 866dc719337b16
Committed: https:/
Submitter: Zuul
Branch: master
commit cbdc84ac7fc88e8 91968116db4866d c719337b16
Author: Colleen Murphy <email address hidden>
Date: Sat Oct 21 20:38:34 2017 +0200
Partially clarify federation auth plugins
Federation protocols in keystone are very confusing due to the way they id_attributes for different protocols.
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_
This patch changes references to the 'mapped' protocol and 'mapped' id_attributes for different
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_
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 /review. openstack. org/#/c/ 397456/ /review. openstack. org/#/c/ 371210/ /bugs.launchpad .net/keystone/ +bug/1724645/ comments/ 1
[2] https:/
[3] https:/
[4] https:/
Change-Id: I23fc3f1f651c12 c4e3c1987dc7100 8e6e97b4ed8
Related-bug: #1724645