Logging in using login and password#

To use the username and password login, the following matching rules must be specified - to determine how the given username relates to the users in the data store.

To create a rule, a wildcard string is used: ${login} is the string entered by the user in the “login” field. As a result, for example, the rule email=${login} means that the string entered by the user will be compared to the email attribute in the data store;

../_images/image010_en.png

In the log-in settings, it is possible to enable the password policy check. The password entered by a user will be checked against the password policy at log-in time. If the password does not meet the policy requirements, the user can set a new password or skip this step.

To configure password validation against the password policy at login, you must:

  • select the Always check the user's current password against the password policy option or enter the name of some header in the Check if HTTP header is present field (in this case, if the HTTP request contains the specified header with the true value, the current user password will be checked against the password policy);

  • the option Allow the user to skip changing a password that does not comply with password policies allows the user to refuse to change the password when logging in;

  • specify the number of failed attempts for temporary blocking. After the specified number of failed attempts, the user will be temporarily blocked from using this authentication method;

  • duration of the temporary blocking (in minutes).

../_images/auth_02_en.png

You can control the password protection in the login settings. When the protection is enabled, the password verification is slowed down. After entering the password, the user will wait for the verification for the specified period Delay time (in seconds).

Administrator can select the following protection modes in the Protection setting:

  • Automatic mode at system and user level - protection will be enabled for all users if the percentage of unsuccessful authentications exceeds the Enable system protection at threshold, and disabled if the percentage of unsuccessful authentications falls below the Disable system protection at threshold;

  • Automatic mode at user level - the protection will be triggered for users for whom the number of unsuccessful password checks exceeds the number specified by the Enable user protection at threshold setting;

  • Authentication delay for all users - protection will be enabled for all users;

  • Disabled - the protection will be disabled.

System protection activation threshold and System Protection Disable Threshold parameters are set in percentages corresponding to the percentage of unsuccessful authentications in the total number of authentication attempts.

An example of how to configure password protection is shown below.

../_images/auth_03_en.png

To complicate automatic password mining, you can enable the Proof of work performance setting in Blitz Identity Provider. Then each time a user logs in with a username and password, the user’s browser will have to perform a computationally complex task. If you fail to provide a solution, provide an incorrect solution, or provide a solution at the wrong time, Blitz Identity Provider will return an error. As a result, it will be impossible to know if the username and password are correct.

../_images/image024_n_en.png

The following can be configured in the Proof of work performance settings block:

  • enable the Request proof of completion of work setting.

  • if necessary, set the Request only if HTTP header is present setting - this is useful if you want to allow autotests to log in by password without having to pass the check. In this case, on the web server it is necessary to set the header from this setting for user requests, and not to set the header for requests coming from autotests.

  • set Work complexity index - the coefficient value from 1 to 160 bits is set. Each bit increases the complexity by 2 times. The recommended value is 15 bits.

  • Maximum decision time - time in seconds, in which the browser should send the result of the work. If the value is not specified, the task is expected to be solved in 1800 seconds. The time is counted from the moment the server generates the task at the moment of displaying the login page.

After setting the setting, it is recommended to press the Test calculation button before saving to get a rough idea of the run time on the current unit.

In the Rules for selecting an attribute repository block you can configure the rules, when executing which the user will be searched only in the specified store. By default, users for authentication are searched in all active attribute storages. You can specify several alternative storage selection rules. This will allow authenticating some users through one repository and others through another. Substitution strings are used to create a rule.

For example, in the screenshot below, it is configured that when a login is requested by an application with the test_app identifier, the user’s login and password will be checked against the test_db repository. Login to all other applications will be performed through the main repository.

../_images/201_en.png