[keystone] "identity_provider failed validation" getting scoped token, on Rocky/Python3
Marek Szuba
scriptkiddie at wp.pl
Thu Jun 24 12:27:27 UTC 2021
Dear everyone,
I run a small OpenStack cloud on Debian Buster, using standard distro
packages - i.e. Rocky. My Keystone is configured as a federated-identity
Service Provider, with the IdP accessed using OpenID.
Having got things working successfully using local users I went on to
testing federation - and found out that using the OpenStack CLI to get a
scoped token from an unscoped one reports a server error 500, and
logging in to Horizon shows usage and event data couldn't be retrieved.
On the server side, in both cases Keystone log shows the following:
INFO keystone.common.wsgi [req-foo bar baz - Federated default] POST
https://osc.example.com:5000/v3/auth/tokens
ERROR keystone.common.wsgi [req-foo bar baz - Federated default]
identity_provider failed validation: <function
FederatedCredential.<lambda> at 0xdeadbeef>: ValueError:
identity_provider failed validation: <function
FederatedCredential.<lambda> at 0xdeadbeef>
ERROR keystone.common.wsgi Traceback (most recent call last):
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/keystone/common/wsgi.py", line 148, in
__call__
ERROR keystone.common.wsgi result = method(req, **params)
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/keystone/auth/controllers.py", line 67,
in authenticate_for_token
ERROR keystone.common.wsgi self.authenticate(request, auth_info,
auth_context)
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/keystone/auth/controllers.py", line 236,
in authenticate
ERROR keystone.common.wsgi auth_info.get_method_data(method_name))
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/keystone/auth/plugins/token.py", line
46, in authenticate
ERROR keystone.common.wsgi PROVIDERS.identity_api
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/keystone/auth/plugins/mapped.py", line
101, in handle_scoped_token
ERROR keystone.common.wsgi send_notification(taxonomy.OUTCOME_SUCCESS)
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/keystone/notifications.py", line 685, in
send_saml_audit_notification
ERROR keystone.common.wsgi user=user_id, groups=group_ids)
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/pycadf/credential.py", line 84, in __init__
ERROR keystone.common.wsgi setattr(self,
FED_CRED_KEYNAME_IDENTITY_PROVIDER, identity_provider)
ERROR keystone.common.wsgi File
"/usr/lib/python3/dist-packages/pycadf/cadftype.py", line 66, in __set__
ERROR keystone.common.wsgi (self.name, self.func))
ERROR keystone.common.wsgi ValueError: identity_provider failed
validation: <function FederatedCredential.<lambda> at 0xdeadbeef>
i.e. the request has succeeded but then things fall over when an audit
notification is to be sent.
Having poked around the sources of
keystone.notifications.send_saml_audit_notifications() and the code it
references, I found out the following:
- the lambda function which triggers the error checks if
'identity_provider' is a six string type;
- when this error occurs the value of 'identity_provider' is indeed
the name of my IdP - but as *bytes* rather than str!
- this doesn't happen every time this IdP name is used - if I add a simple
identity_provider = identity_provider.decode('utf-8') to the relevant
function
I start getting errors suggesting that under some circumstances,
'identity_provider' is str as it should be.
All in all, it seems like this particular bit of Keystone code in Rocky
does not properly support Python3. Unfortunately an upgrade to a newer
OpenStack version is non-trivial for me for several reasons, only some
of which are under my control - and the stop-gap measure of having
patched the relevant function with "if identity_provider is bytes,
decode it to str" means I've had to put the relevant Debian package on
hold, thus blocking potential updates. Therefore, I look forward to
hearing from you any and all ideas which might help address this problem
in less radical fashion.
Thank you in advance!
--
MS
More information about the openstack-discuss
mailing list