Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

EN | ES

Info

Since From Platform Version 1.6.2.

Capabilities

To provide greater security to users, new functionalities, restrictions and validations have been added to the platform:

These can be modified and configured by environment (a new Central Configuration managed by administrator will appear from the Control Panel):

See /wiki/spaces/PT/pages/214401056, the . The input is called EXPIRATIONUSERS, this . This is the default setting (Since version 1.6.2-Empire).

ExpirationUsersPass:

cron: "0 0 0? * * *"

In this parameter, we are indicating that it check checks at 00:00:00 am 00am every day if whether the passwords are expired , or not – that is to say, we are indicating how often the password verification checking task should be executed.

timeLifePass: 180

Here

it is indicated

we indicate how many days the password is valid

in

. In this case

by default they are marked

, the default value is 180 days.

noticesDaysBefore: 10

With this parameter, we indicate the number of days before the password expires that expiration when a message will be sent daily as a reminder, to inform that this is going to happen . (From Available since 1.6.2-Empire).

maxInactiveDays: 30

This parameter sets to 30, establishes the number of days that, if a user has not accessed the platform, the user will remain in inactive status and will then have to contact the administrator to be reactivated. The default value is 30 days.

password.pattern:

Supported passwords are based on this pattern:

password.pattern: (?=^.{10,255}$)((?=.*\d)|(?=.*\W+))(?![.\n])(?=.*[A-Z])(?=.*[a-z]).*$

This requires a password between 10 and 255 characters that contains uppercase, lowercase, numbers, and special characters such as !

Authentication:

limitFailedAttemp: 3

Here, the number of attempts to access the platform with a user is set to three, if 3.

It can be configured from the Centralized Configuration:

Image Added

If the access failure occurs three times due to incorrectly entering the password, the user remains inactive, an email is sent to inform the user that it has been this fact has occurred and to indicate that you have to contact the administrator to activate the account (From 1.6.2-Empire).

numberLastEntriesToCheck: 5

This parameter is used when changing the password, the . The new password cannot coincide with any of the last (N) last passwords used by that the user , has used (in this case with the last 5), with the platform controlling a history of the used passwords used is controlled from the platform.

ResetUserPass:

hours: 7

When a password is reset, here we indicate the number of hours that the password sent by mail will be valid.

cron: "0 0 *? * * *"

We are indicating how often the task that validates for checks the users the validity time of the password that has been sent by mail must to the users should be launched, to . To exit this state the user must change the password.

Summary

  • These functionalities are parameterized in the EXPIRATIONUSERS section accessible from configuration management.

  • For the changes in EXPIRATIONUSERS to take effect, the controlpanel and rtdb-maintainer services must be restarted from the rancherRancher, so that the tasks that validate the user accounts are restarted.

  • The password will expire after (N) days of being establishedset. Also, when the expiration is close near (M days before), an email will be sent every day as a reminder to the user: M and N are configurable by environment (From Since 1.6.2-Empire).

  • When a user has not accessed the platform in N days, it will be deactivated, and only an administrator can activate it again (From Since 1.6.2-Empire).

  • When a password reset event occurs, either by an administrator or a user, an email will be sent to the user with the temporary random password, or when it is used for the first time to access the console, the user will be forced a to reset the password. change of password. o If you try to access any REST service with that random temporary password, you will be denied access. o You can reset the password from the ControlPanel or from API REST (Since 2.1.0-gradius)

  • The user will be forced to change the password when first used to access the console after a password reset event occurs (either by an administrator or by the user), during which an email will be sent to the user. user with a temporary random password.

    • If the user tries to access any REST service with that random temporary password, access will be denied.

    • The user can reset the password from the ControlPanel or from API REST (

    From
    • Since 2.1.0-gradius).

  • A random temporary password (product of the reset event) will expire at after N hours, being N configurable (From Since 2.1.0-gradius).

  • For the administrator, an option for resetting to reset passwords has been added in to the user management list to have a more agile management of users (From Since 2.1.0-gradius).

  • As of version 2.2.0-hyperblast it is allowed to set , some certain parameters with can be set to the value -1 so that they do not take effect.

Password format with basic identity manager

The passwords that are allowed by default in the basic identity manager must meet a pattern which validates that they must contain uppercase letters, lowercase letters, numbers and special characters such as ! For example, the minimum length is 10 and the maximum is 255 characters.