[Bug 1827120] Fix included in openstack/horizon 23.0.1
OpenStack Infra
1827120 at bugs.launchpad.net
Tue Mar 5 09:45:31 UTC 2024
This issue was fixed in the openstack/horizon 23.0.1 release.
--
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to horizon in Ubuntu.
https://bugs.launchpad.net/bugs/1827120
Title:
[SRU] application credentials created via Horizon with the admin
project scope have project_id == None
Status in Ubuntu Cloud Archive:
Fix Released
Status in Ubuntu Cloud Archive ussuri series:
Fix Released
Status in Ubuntu Cloud Archive victoria series:
Fix Released
Status in Ubuntu Cloud Archive wallaby series:
Fix Released
Status in Ubuntu Cloud Archive xena series:
Fix Released
Status in Ubuntu Cloud Archive yoga series:
Fix Released
Status in Ubuntu Cloud Archive zed series:
Fix Released
Status in OpenStack Dashboard (Horizon):
Fix Committed
Status in horizon package in Ubuntu:
Fix Released
Status in horizon source package in Focal:
Fix Released
Status in horizon source package in Jammy:
Fix Released
Status in horizon source package in Kinetic:
Fix Released
Bug description:
=====================================================================================================
SRU template below:
[Impact]
Users with SAML WEBSSO authentication may be unable to use the
OpenStack CLI due to a combination of 2 reasons:
1) Inability to use an existing Keystone authentication protocol if their AD provider does not a SOAP endpoint
2) Inability to create proper application credentials through Horizon when they have domain+project admin roles, because the scopeless domain token is used when authenticating with Keystone
Due to being unable to use the CLI, many Cloud management operations
are out of reach, as they are not available in Horizon. This SRU
addresses cause (2) listed above by forcing a scoped token ONLY in the
application credential create request.
The problem, however, also affects regular keystone users when they
have domain+project admin roles, but Keystone users have no issues
using the CLI to avoid the issue.
[Test case]
1. Setting up env
1a. Deploy environment
1b. Create a new domain d1
openstack domain create d1
1c. Create a new project p1 in domain d1
openstack project create p1 --domain d1
1d. Create a new user u1 in domain d1 and project p1
openstack user create u1 --domain d1 --project p1 --password pw
1e. Add domain + project Admin roles to user u1
openstack role add Admin --user u1 --user-domain d1 --project p1 --project-domain d1
openstack role add Admin --user u1 --user-domain d1 --domain d1
2. Reproducing the bug
2a. Login to horizon as user u1
2b. Navigate to Identity > application credentials page
2c. Create a new application credential named ac1 with default values
2d. Observe in the Horizon page list that the application credential was created without a project_id
2e. Confirm through the CLI (as user u1) that the application credential project_id is not shown in the list
openstack application credential list
3. Cleanup not necessary
4. Install the package that contains the fixed code
5. Repeat steps 2a-2e and confirm the project_id is now shown
alongside the created application credential
[Regression Potential]
Given that the code adds an optional new parameter, and it is only
being used when creating application credentials, only this
functionality would be affected in case of a problem. Additionally, a
potential problem would be in scope detection according to policy: the
value is a boolean, so it is either a scoped or scopeless token
forced. In case the detection fails and a scopeless token is used, the
behavior is the same as the existing bug, otherwise, the behavior is
the correct one.
[Other Info]
None
=====================================================================================================
Original bug description below:
Environment: tested with Stein from UCA (deployed via 19.04 charms).
1) login to horizon into the "admin" project;
keystone.conf:
[resource]
admin_project_domain_name = admin_domain
admin_project_name = admin
2) go to the "Application Credentials" tab;
3) create a credential with a unique name without specifying other
parameters besides Admin and/or Member roles (auto-filled secret, no
expiration);
note: project_id is retrieved from the token, it is not a field in the
form
4) observe that project_id is set to None
5) encounter the following error during authentication using the
application credential
TypeError: one of the hex, bytes, bytes_le, fields, or int arguments
must be given
see the text file attached with a pdb log.
6) do the same via CLI and observe that project_id is specified and it
is possible to log in
CLI workflow (project_id is present):
openstack application credential create --role Member --role Admin testcred
+--------------+----------------------------------------------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------------------------------------------+
| description | None |
| expires_at | None |
| id | bb845e9e18634e7c8cfc36d80179ab05 |
| name | testcred |
| project_id | ebfc7e0457f048aa960d633141115cd1 |
| roles | Member Admin |
| secret | zCka3asrEouKqCnJlfRdk-Qg3gDM0WSbjTqxlYaBO_ygyQCpZY8NPnSQhm6o802O-r22eHWv79-iHJ5sJQ_kUw |
| system | None |
| unrestricted | False |
| user_id | 95067aae3e634a29830f91a53dd0d80a |
+--------------+----------------------------------------------------------------------------------------+
Note the difference:
openstack application credential list
+----------------------------------+----------------+----------------------------------+-------------+------------+
| ID | Name | Project ID | Description | Expires At |
+----------------------------------+----------------+----------------------------------+-------------+------------+
| 344ddd90249645608b625131f82d056b | clicred | ebfc7e0457f048aa960d633141115cd1 | None | None |
| d681d11d4744421f81dd32ca0459d54d | dashboard_cred | None | None | None |
+----------------------------------+----------------+----------------------------------+-------------+------------+
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1827120/+subscriptions
More information about the Ubuntu-openstack-bugs
mailing list