| 2019-05-07 09:42:21 |
Dmitrii Shcherbakov |
description |
'mapped' is an authentication plugin name which is also used as a protocol name in OpenStack documentation. Protocol names need to be added as "methods" into keystone.conf and the charm currently hard-codes 'mapped' as if it was the only protocol to be supported (the confusion comes from the fact that authentication plugins are usually listed there).
https://docs.openstack.org/keystone/queens/admin/federated-identity.html#configuring-federation-in-keystone
"Configure authentication drivers in keystone.conf by adding the authentication methods to the [auth] section in keystone.conf. Ensure the names are the same as to the protocol names added via Identity API v3."
"saml2 and openid are instances of the mapped plugin. These must match the name of the of the federation protocol created via the Identity API. The other names in the example are not related to federation."
Usage examples in unit tests:
https://opendev.org/openstack/keystone/src/branch/stable/queens/keystone/tests/unit/test_auth_plugin.py#L213-L217
There is nothing preventing us from supporting other names and specifying something like this:
methods = external,password,token,oauth1,totp{% for m in fid_methods -%},{{ m }}{% endfor -%}
Besides use-cases like SAML or OIDC the "mapped" authentication plugin is also used for tokenless x509 auth which relies on a section that specifies the protocol as well:
[tokenless_auth]
# ...
protocol = x509
So, changing the current code to avoid hardcoding 'mapped' and 'oidc' and only adding protocol names if charm-keystone is related to other charms like keystone-saml-mellon will not break compatibility for existing deployments. |
'mapped' is an authentication plugin name which is also used as a protocol name in OpenStack documentation. Protocol names need to be added as "methods" into keystone.conf and the charm currently hard-codes 'mapped' as if it was the only protocol to be supported (the confusion comes from the fact that authentication plugins are usually listed there).
https://docs.openstack.org/keystone/queens/admin/federated-identity.html#configuring-federation-in-keystone
"Configure authentication drivers in keystone.conf by adding the authentication methods to the [auth] section in keystone.conf. Ensure the names are the same as to the protocol names added via Identity API v3."
"saml2 and openid are instances of the mapped plugin. These must match the name of the of the federation protocol created via the Identity API. The other names in the example are not related to federation."
Usage examples in unit tests:
https://opendev.org/openstack/keystone/src/branch/stable/queens/keystone/tests/unit/test_auth_plugin.py#L213-L217
There is nothing preventing us from supporting other names and specifying something like this:
methods = external,password,token,oauth1,totp{% for m in fid_methods -%},{{ m }}{% endfor -%}
Besides use-cases like SAML or OIDC the "mapped" authentication plugin is also used for tokenless x509 auth which relies on a section that specifies the protocol as well:
[tokenless_auth]
# ...
protocol = x509
So, changing the current code to avoid hardcoding 'mapped' and 'openid' and only adding protocol names if charm-keystone is related to other charms like keystone-saml-mellon will not break compatibility for existing deployments. |
|
