-
Notifications
You must be signed in to change notification settings - Fork 181
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
25124 enforcing password requirements #9423
base: master
Are you sure you want to change the base?
25124 enforcing password requirements #9423
Conversation
…o flow as before. split functions and custom exception.
…e after spark api and model integration)
…requirements' into 25124-enforcing-password-requirements
👋 Hello! Thanks for contributing to our project. If you are unsure the failing tests are related to your code, you can check the "reference jobs". These are jobs that run on a scheduled time with code from master. If they fail for the same reason as your build, it means the tests or the infrastructure are broken. If they do not fail, but yours do, it means it is related to your code. Reference tests: KNOWN ISSUES Sometimes the build can fail when pulling new jar files from download.opensuse.org . This is a known limitation. Given this happens rarely, when it does, all you need to do is rerun the test. Sorry for the inconvenience. For more tips on troubleshooting, see the troubleshooting guide. Happy hacking! |
Suggested tests to cover this Pull Request
|
The frontend parts that are currently there look good. 👍 I assume there will be followup work to fix the build etc. |
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.
Some small notes
java/code/src/com/redhat/rhn/common/util/validation/password/PasswordPolicy.java
Show resolved
Hide resolved
java/code/src/com/redhat/rhn/common/util/validation/password/PasswordPolicyCheckFail.java
Show resolved
Hide resolved
java/code/src/com/redhat/rhn/common/util/validation/password/PasswordValidationException.java
Show resolved
Hide resolved
PasswordPolicyProperties passwordPolicyProperties = GSON.fromJson(request.body(), | ||
PasswordPolicyProperties.class); | ||
try { | ||
SatConfigFactory.setSatConfigValue(SatConfigFactory.PSW_CHECK_LENGTH_MIN, |
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.
Should we validate if the user enters something crazy in here? Like a negative max length? Or a min length bigger then max length?
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.
yeah we should, i didn't think about that. Also for better ux we should enforce this rules in the frontend.
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.
We can check that in the front-end, but all validations must also be done in the backend also.
java/code/src/com/suse/manager/webui/controllers/admin/beans/PasswordPolicyProperties.java
Outdated
Show resolved
Hide resolved
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_length_min', 'Minimum number of characters in local user passwords', 4, 4); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_length_max', 'Maximum number of characters in local user passwords', 32, 32); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_lower_char_flag', 'Password has to have at least one lower alpha character', TRUE, TRUE); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_upper_char_flag', 'Password has to have at least one upper alpha character', TRUE, TRUE); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_digit_flag', 'Password has to have at least one digit', TRUE, TRUE); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_consecutive_char_flag', 'Password has to have no consecutive characters', FALSE, FALSE); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_special_char_flag', 'Password has to have at least a special character', FALSE, FALSE); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_restricted_occurrence_flag', 'Password has to have no repeating characters', FALSE, FALSE); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_max_occurrence', 'Maximum number of valid occurrence of a character', 2, 2); | ||
INSERT INTO rhnConfiguration (key, description, value, default_value) | ||
VALUES ('password_check_special_characters', 'List of special characters to check in a password', null, '!$%&()*+,./:;<=>?[\\]^_{|}~'); |
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.
We need to think about the defaults. What policy do we want to configure as default?
Maybe something what NIST, BSI & Co suggest?
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.
I think we should keep the old defaults, as agreed with @admd, so that we don't break the old tests and the automations already in place
@Serp1co You need to implement DB schema migration and also think about how to migrate from current configuration file values to DB. We have at least min and max password length. If they are changed, we should set it the DB configuration |
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.
Once the default values are decided, we need a button in the UI to reset everything to default. If you want to go one step further for convenience, we can decide on a few sensible presets with varying levels of restriction, and add buttons for each, which set all the fields accordingly.
Ideally, all those individual fields must be filled only if the user has some specific rules in mind. Otherwise, we should offer shortcuts like I mentioned above.
* @param user | ||
* @return an OK string | ||
*/ | ||
public String postPasswordPolicy(Request request, Response response, User user) { |
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.
We also need an API for the user (XMLRCP/JSON over HTTP) to get and modify the policy
@cbbayburt what about showing the default value in front, maybe in gray, so customers know what was the default value, and if they want come back to that value for a few fields? |
I'm not sure. Especially the "special chars" field is not so convenient to type in manually. Maybe @bisht-richa or @Etheryte has some ideas? |
Some rough idea |
What does this PR change?
Enforce password requirement for server users, comes with a new admin panel to manage local users password policy.
GUI diff
Before:
After:
Documentation
Documentation issue was created: Link for SUSE Manager contributors, Link for community contributors.
API documentation added: please review the Wiki page Writing Documentation for the API if you have any changes to API documentation.
(OPTIONAL) Documentation PR
DONE
Test coverage
Unit tests were added
DONE
Links
Issue(s): #
Port(s): # add downstream PR(s), if any
Changelogs
Make sure the changelogs entries you are adding are compliant with https://github.com/uyuni-project/uyuni/wiki/Contributing#changelogs and https://github.com/uyuni-project/uyuni/wiki/Contributing#uyuni-projectuyuni-repository
If you don't need a changelog check, please mark this checkbox:
If you uncheck the checkbox after the PR is created, you will need to re-run
changelog_test
(see below)Re-run a test
If you need to re-run a test, please mark the related checkbox, it will be unchecked automatically once it has re-run:
Before you merge
Check How to branch and merge properly!