-
Notifications
You must be signed in to change notification settings - Fork 282
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
[BUG] Fix roles verification for roles mapping and internal users #3278
[BUG] Fix roles verification for roles mapping and internal users #3278
Conversation
cca9eca
to
6c0523a
Compare
Codecov Report
@@ Coverage Diff @@
## main #3278 +/- ##
============================================
+ Coverage 63.15% 63.18% +0.02%
Complexity 3448 3448
============================================
Files 263 263
Lines 20024 20038 +14
Branches 3341 3346 +5
============================================
+ Hits 12647 12661 +14
+ Misses 5748 5747 -1
- Partials 1629 1630 +1
|
6c0523a
to
46b3b34
Compare
So the logic was like this: protected boolean isValidRolesMapping(final RestChannel channel, final String role) {
final SecurityDynamicConfiguration<?> rolesConfiguration = load(CType.ROLES, false);
final SecurityDynamicConfiguration<?> rolesMappingConfiguration = load(CType.ROLESMAPPING, false);
if (!rolesConfiguration.exists(role)) {
notFound(channel, "Role '" + role + "' is not available for role-mapping.");
return false;
}
if (isHidden(rolesConfiguration, role)) {
notFound(channel, "Role '" + role + "' is not available for role-mapping.");
return false;
}
return isWriteable(channel, rolesMappingConfiguration, role);
} |
fb956de
to
4708582
Compare
import static org.opensearch.security.dlic.rest.api.Responses.forbiddenMessage; | ||
import static org.opensearch.security.dlic.rest.api.Responses.notFoundMessage; | ||
import static org.opensearch.security.dlic.rest.support.Utils.withIOException; | ||
import static org.opensearch.security.dlic.rest.api.Responses.*; |
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.
Looks like this star import crept in. There's an open issue to add enforcement to forbid * imports: #3260
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.
yeap looks like that. fixed manually
…al users Signed-off-by: Andrey Pleskach <[email protected]>
4708582
to
17c9e2e
Compare
} | ||
|
||
@Test | ||
public void validateSecurityRolesWithImmutableRolesMappingConfig() throws Exception { |
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.
Its really confusing me that there are 2 ways that roles mapping can be done to map a user directly to a role.
- Modify the
opendistro_security_roles
attribute of a user - this modifies theinternaluser
config entry and not theroles_mapping
config entry - Update the
roles_mapping
and add theusername
in the list ofusers
.
I had to spend a little time digesting that this is simulating the behavior of a PUT _plugins/_security/api/internalusers/<username>
call where the config entries for the role and roles_mapping already exist. In this case in the test setup it creates 4 roles where the mapping will fail:
some_hidden_role
- The role is hiddensome_role_with_hidden_mapping
- The role is fine, but the roles mapping is hiddensome_role_with_reserved_mapping
- The role is fine, but the roles mapping is reservedsome_role_with_static_mapping
- The role is fine, but the roles mapping is static
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.
Not exactly but closer. In any case a tests on PATCH should be added.
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.
Thank you @willyborankin. This PR looks good to me.
Overall feedback is that it uses var
a lot instead of the datatype. I recommend to minimize the usage of var
. It may be clear to the compiler what the datatype is, but sometimes var
makes it hard to glean the datatype at a glance.
@cwperks Want to make an issue / checkstyle rule? IMO I don't mind var when locals have understandable names, but I'd be curious about your thoughts |
) The resent refactoring of the REST APIs: #3123 introduce a regression in how roles-mapping verification has worked before. The old solution verified only hidden roles both for internal users and roles mapping, while new was too strict and forbid to do it for both. This PR fixes the problem and uses the same logic as it was before. - In case of roles-mapping it verifies only a role associated with it that the role is not hidden. - In case of internal users it verifies that a role is not hidden and roles-mapping associated with the role is mutable So verification was split and added to the corresponding ActionApi class which is more convenient as it was before. Signed-off-by: Andrey Pleskach <[email protected]> (cherry picked from commit 53f64b9) Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
…ernal users (#3282) Backport 53f64b9 from #3278. Signed-off-by: Andrey Pleskach <[email protected]> Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Sure, I plan to check if core has any restrictions and will file an issue shortly for discussion. |
Description
The resent refactoring of the REST APIs: #3123 introduce a regression in how roles-mapping verification has worked before.
The old solution verified only hidden roles both for internal users and roles mapping, while new was too strict and forbid to do it for both.
This PR fixes the problem and uses the same logic as it was before.
So verification was split and added to the corresponding ActionApi class which is more convenient as it was before.
Tests for such functionality were added as well.
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.