-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Grant access to 2FA APIs for default read-only and support roles #10273
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grant access to 2FA APIs for default read-only and support roles #10273
Conversation
Guys, should the changes in this PR also be applied to versions 4.19 and 4.20? If so, I think it would be necessary to open a new PR targeting each version branch, right? |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #10273 +/- ##
=========================================
Coverage 16.19% 16.20%
- Complexity 13051 13061 +10
=========================================
Files 5645 5645
Lines 494567 494634 +67
Branches 59955 59963 +8
=========================================
+ Hits 80088 80144 +56
- Misses 405642 405653 +11
Partials 8837 8837
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@blueorangutan package |
@bernardodemarco a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 12208 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks for the PR.
Is it not better to handle this in upgrade java class as a generic method, so that we can use that method for multiple APIs and in future also ?
or may be a procedure something like
DELIMITER $$
CREATE PROCEDURE `IDEMPOTENT_UPDATE_SINGLE_API_PERMISSION`(
IN role_name VARCHAR(255),
IN api_rule VARCHAR(255),
IN api_permission VARCHAR(10)
)
BEGIN
DECLARE roleId BIGINT;
DECLARE maxSortOrder INT;
SELECT `id`
INTO roleId
FROM `cloud`.`roles`
WHERE `name` = role_name
AND `is_default` = 1;
UPDATE `cloud`.`role_permissions`
SET `sort_order` = `sort_order` + 1
WHERE `rule` = '*'
AND `role_id` = roleId;
SELECT MAX(`sort_order`)
INTO maxSortOrder
FROM `cloud`.`role_permissions`
WHERE `role_id` = roleId;
IF NOT EXISTS (
SELECT 1
FROM `cloud`.`role_permissions`
WHERE `role_id` = roleId
AND `rule` = api_rule
) THEN
INSERT INTO `cloud`.`role_permissions`
(uuid, role_id, rule, permission, sort_order)
VALUES
(uuid(), roleId, api_rule, api_permission, maxSortOrder + 1);
END IF;
END$$
DELIMITER ;
Note: I've not testes this procedure, but a pseudo code.
@harikrishna-patnala, thanks for your review. I believe that it would be better to create the SQL procedure to abstract this operation. I'll be working on it and, in the meantime, I'll put the PR in draft. |
@blueorangutan package |
@bernardodemarco a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
Okay, it seems there are some syntax errors in the SQL script. I'll take a closer look at it tomorrow. |
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 12247 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
clgtm
@bernardodemarco , this is marked for release 21 now, would you consider moving it to an earlier release? |
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Yes, no problem. Should I target it to 4.19 or 4.20? |
4.19 is fine but a bit late and as this needs adjustment of the sql file , you could choose to go for 4.20. On the other hand the current implementation is suitable to be in more than one upgrade path, so if you are adventurous ... ;) |
bdb4d98
to
0375303
Compare
@DaanHoogland @harikrishna-patnala, I've just fixed the SQL syntax errors and targeted it to 4.19 |
@blueorangutan package |
@harikrishna-patnala a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress. |
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ debian ✔️ suse15. SL-JID 12268 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. tested with admin and readonly user accounts on a new environment.
@DaanHoogland, should I open another PR targeting the |
those are two half statements @bernardodemarco , and the answer to both is "maybe yes", but... |
Description
Accounts created with the
Read-Only User - Default
andSupport User - Default
roles do not have access tosetupUserTwoFactorAuthentication
,validateUserTwoFactorAuthenticationCode
andlistUserTwoFactorAuthenticatorProviders
APIs. Additionally, accounts created with theRead-Only Admin - Default
andSupport Admin - Default
roles only have access to thelistUserTwoFactorAuthenticatorProviders
API.As a consequence, when 2FA is required for authentication, accounts with these roles cannot login into CloudStack. Thus, this PR proposes to grant access to the 2FA-related APIs for the previously mentioned roles.
Fixes #10269
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Screenshots (if appropriate):
How Has This Been Tested?
Read-Only User - Default
Role permissions before changes
Role permissions after changes
Support User - Default
Role permissions before changes
Role permissions after changes
Read-Only Admin - Default
Role permissions before changes
Role permissions after changes
Support Admin - Default
Role permissions before changes
Role permissions after changes