Openstack API unautorized when creating a token

Bug #2065061 reported by Natalia Litvinova
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Keystone Charm
Triaged
High
Unassigned

Bug Description

Hi team,

While running Tempest, I'm running to the following problem with Openstack API when using service-port config set to 443:
'code': 401, 'message': 'The request you have made requires authentication.', 'title': 'Unauthorized'

Here is a traceback:
Traceback (most recent call last):
  File "/snap/fcbtest/50/lib/python3.10/site-packages/keystone_tempest_plugin/tests/api/identity/v3/test_oauth1_tokens.py", line 154, in test_create_access_token
    access_token = self._create_access_token(consumer)
  File "/snap/fcbtest/50/lib/python3.10/site-packages/keystone_tempest_plugin/tests/api/identity/v3/test_oauth1_tokens.py", line 60, in _create_access_token
    request_token = self._create_request_token(consumer)
  File "/snap/fcbtest/50/lib/python3.10/site-packages/keystone_tempest_plugin/tests/api/identity/v3/test_oauth1_tokens.py", line 41, in _create_request_token
    request_token = self.oauth_token_client.create_request_token(
  File "/home/ubuntu/snap/fcbtest/50/.rally/verification/verifier-7d8b303d-87c8-4f78-ac43-a509b47019b1/repo/tempest/lib/services/identity/v3/oauth_token_client.py", line 130, in create_request_token
    resp, body = self.post(endpoint,
  File "/home/ubuntu/snap/fcbtest/50/.rally/verification/verifier-7d8b303d-87c8-4f78-ac43-a509b47019b1/repo/tempest/lib/common/rest_client.py", line 300, in post
    return self.request('POST', url, extra_headers, headers, body, chunked)
  File "/home/ubuntu/snap/fcbtest/50/.rally/verification/verifier-7d8b303d-87c8-4f78-ac43-a509b47019b1/repo/tempest/lib/common/rest_client.py", line 742, in request
    self._error_checker(resp, resp_body)
  File "/home/ubuntu/snap/fcbtest/50/.rally/verification/verifier-7d8b303d-87c8-4f78-ac43-a509b47019b1/repo/tempest/lib/common/rest_client.py", line 842, in _error_checker
    raise exceptions.Unauthorized(resp_body, resp=resp)
tempest.lib.exceptions.Unauthorized: Unauthorized
Details: {'code': 401, 'message': 'The request you have made requires authentication.', 'title': 'Unauthorized'}

Tempest tests that fail with this problem are:
keystone_tempest_plugin.tests.api.identity.v3.test_oauth1_tokens.OAUTH1TokensTest.test_authorize_request_token
keystone_tempest_plugin.tests.api.identity.v3.test_oauth1_tokens.OAUTH1TokensTest.test_create_access_token
keystone_tempest_plugin.tests.api.identity.v3.test_oauth1_tokens.OAUTH1TokensTest.test_create_request_token
keystone_tempest_plugin.tests.api.identity.v3.test_oauth1_tokens.OAUTH1TokensTest.test_list_access_tokens
keystone_tempest_plugin.tests.api.identity.v3.test_oauth1_tokens.OAUTH1TokensTest.test_list_roles_for_access_token
keystone_tempest_plugin.tests.api.identity.v3.test_oauth1_tokens.OAUTH1TokensTest.test_revoke_access_token
keystone_tempest_plugin.tests.api.identity.v3.test_oauth1_tokens.OAUTH1TokensTest.test_show_role_for_access_token

When checking the keystone debug logs, I found:

(py.warnings): 2024-04-25 11:14:20,011 WARNING /usr/lib/python3/dist-packages/oslo_policy/policy.py:1119: UserWarning: Policy "identity:get_consumer": "role:reader and system_scope:all" failed scope check. The token used to make the request was project scoped but the policy requires ['system'] scope. This behavior may change in the future where using the intended scope is required
 warnings.warn(msg)

Running the commands with openstack cli is successfull:
openstack token issue
openstack token revoke

Reconfiguring the charm to use the default port 5000 fixes the Tempest problem.

Vesrions:
Openstack Yoga
Juju 3.4.2
Keystone charm yoga/stable rev 686

description: updated
description: updated
Revision history for this message
Przemyslaw Hausman (phausman) wrote :
Download full text (5.4 KiB)

Confirmed. The issue is only present if `service-port` is set to 443. I have tested it with different ports, such as 442, 444, 500, 5433 and each time tempest is successful. It fails only when `service-port` is set to be 443.

The entries in keystone.log suggest that the URL without :443 is being used for validation:

```
(keystone.server.flask.request_processing.req_logging): 2024-05-08 12:54:35,496 DEBUG REQUEST_METHOD: `POST`
(keystone.server.flask.request_processing.req_logging): 2024-05-08 12:54:35,496 DEBUG SCRIPT_NAME: ``
(keystone.server.flask.request_processing.req_logging): 2024-05-08 12:54:35,496 DEBUG PATH_INFO: `/v3/OS-OAUTH1/request_token`
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,498 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> checked out from pool
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,499 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2e260> being returned to pool
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,499 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2e260> rollback-on-return
(sqlalchemy.orm.path_registry): 2024-05-08 12:54:35,500 DEBUG set 'memoized_setups' on path 'CachingEntityRegistry((<Mapper at 0x7ff09ff81fc0; Consumer>,))' to '{}'
(sqlalchemy.orm.path_registry): 2024-05-08 12:54:35,502 DEBUG set '('getters', <Mapper at 0x7ff09ff81fc0; Consumer>)' on path 'CachingEntityRegistry((<Mapper at 0x7ff09ff81fc0; Consumer>,))' to '{'cached_populators': {'new': [], 'quick': [('description', operator.itemgetter(1)), ('id', operator.itemgetter(0)), ('extra', operator.itemgetter(3)), ('secret', operator.itemgetter(2))], 'deferred': [], 'expire': [], 'delayed': [], 'existing': [], 'eager': []}, 'todo': [], 'primary_key_getter': sqlalchemy.engine.util.tuplegetter((0,))}'
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,503 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> being returned to pool
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,504 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> rollback-on-return
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,507 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> checked out from pool
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,511 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> being returned to pool
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,511 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> rollback-on-return
(keystone.server.flask.request_processing.middleware.auth_context): 2024-05-08 12:54:35,511 DEBUG Authenticating user token
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,512 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> checked out from pool
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,514 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc26290> checked out from pool
(sqlalchemy.pool.impl.QueuePool): 2024-05-08 12:54:35,516 DEBUG Connection <pymysql.connections.Connection object at 0x7ff09fc2a2c0> being returned to pool
(sqlalchemy.p...

Read more...

Revision history for this message
Przemyslaw Hausman (phausman) wrote :

https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/signature.py#L179C11-L180C61

> The port MUST be included if it is not the default port for the scheme, and MUST be excluded if it is the default.

Then, the port 443 is removed here:

https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth1/rfc5849/signature.py#L203

```
203 if (scheme, port) in (('http', 80), ('https', 443)):
204 netloc = hostname # default port for scheme: exclude port num
```

Revision history for this message
Alex Kavanagh (ajkavanagh) wrote :

@phausman good find; thanks for the additional information. @natalytvinova thanks for doing the investigation and confirming that removing the 443 for https (and also probably, removing :80 for http) gets it to work again.

I've had a look at the keystone code, and unfortunately, it just passes through urls as created by the api service charms.

I think what will need to happen is for the keystone code to 'fix-up' any urls with :443 for https (or :80 for http) before getting keystone to write the endpoint to the database. It's a bit of a kludge but will workaround charms that 'do the wrong thing', and enables the fix to be in one place.

Changed in charm-keystone:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Natalia Litvinova (natalytvinova) wrote :

Thanks Alex, I'm going to remove field-critical since we have a workaround

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.