Login and Session Configuration - Documentation topics on: backend login,security,.

This documentation is a static copy for this version. For current documentation, see: http://dotcms.com/docs/latest

Login and Session Configuration

The login process and user session behavior in dotCMS may be modified to modify security and change dotCMS behavior for user logins and sessions.

Login Process Configuration

The following properties may be found in the Authorization section of the portal.properties file (/dotserver/tomcat-X.x/webapps/ROOT/WEB-INF/classes/portal.properties).

Note: It is strongly recommended that all changes to the portal.properties file be made through a properties file extension.

Repeated Login Failures

The following properties control how dotCMS handles repeated user login failures:

auth.failure=com.liferay.portal.auth.LoginFailure
auth.max.failures=com.liferay.portal.auth.LoginMaxFailures
auth.max.failures.limit=5
auth.failedattempts.delay.enabled=true
auth.failedattempts.delay.strategy=pow

By default:

  • dotCMS uses the Liferay authorization classes to handle failed logins.
    • You may override this with the auth.failure and auth.max.failures properties.
  • Users will be locked out of the system (requiring Administrators to reset their account) after 5 consecutive failed logins.
    • To change this, set the auth.max.failures.limit property to the desired number of failed logins before user lockout.

Delay Strategy

When a user login fails, dotCMS can be configured to automatically implement a delay before a new login attempt will be allowed. The auth.failedattempts.delay.enabled property enables or disables the failed login delay, and the auth.failedattempts.delay.strategy property specifies the strategy used to implement the delay.

| Strategy | Description | | pow (default) | The delay time is determined by raising the number of failed attempts (after the first) to the power of two. Please see below for more information. | | time_mills:{number} | The delay time equals a number of milliseconds equal to the {number} portion of the parameter. | | time_sec:{number} | The delay time equals a number of seconds equal to the {number} portion of the parameter. | | time_min:{number} | The delay time equals a number of minues equal to the {number} portion of the parameter. |

pow Strategy

When using any of the time_* strategies, the time delay is always fixed, regardless of how many unsuccessful login attempts have been made. However when using the pow strategy (the default strategy), the first time a user fails to log does not cause a delay in login attempts, as it's considered a mistake, not an attack. All unsuccessful login attempts after the first will cause a delay in seconds equal to the (number of unsusscessful attempts-1) squared. For example:

  • 1 failed attempt: Delay = 0 seconds (no delay).
  • 2 failed attempts: Delay = 1 second.
  • 3 failed attempts: Delay = 4 seconds.
  • 4 failed attempts: Delay = 9 seconds.
  • etc.

The pow strategy provides greater delay “penalties” for unsuccessful login attempts, ensuring that automated attempts to compromise a user account suffer greater and greater penalties, greatly reducing the possibility of brute force password attacks.

Simultaneous Logins

dotCMS can detect if a user account attempts to log into the dotCMS backend more than once at the same time. By default, dotCMS allows the same user account to login simultaneously, but you may prevent simultaneous logins by changing the auth.simultaneous.logins property to false.

auth.simultaneous.logins=false

Note:

  • If you disable simultaneous logins, all of your backend users should have unique user accounts.
    • Otherwise, if you have multiple users sharing the same login account, only one of those users will be able to login at a time.

Users' Starting Page

By default, when users log in they are redirected to the last page they were viewing before their last logout. You can change this behavior, instead automatically redirecting users to the Workflow Tasks page in the Home tab by setting the auth.forward.by.last.path property to false.

auth.forward.by.last.path=true

Hide Forgot Password Link

By default, dotCMS displays a Forgot Password link that users can click to request support for recovering their password. You may disable this feature by changing the password.forgot.show property to false.

password.forgot.show=true

Auto-Login

The auto.login.hooks property specifies the class used to handle automatic logins. You may change this property to override the default value with a different class.

auto.login.hooks=com.liferay.portal.auth.BasicAutoLogin

User Session Configuration

The following properties can be set to change how dotCMS handles user sessions.

Session Expiration

The session timeout specifies the number of minutes before an inactive user session expires and is automatically logged out. The default value is 30 minutes.

Important:

  • Although there is a session.timeout property in the portal.properties file, this value is always overridden by the value set in the web.xml file.
    • Therefore, you should always set the session timeout value via the web.xml file ().
  • It is strongly recommended that all changes to the web.xml file be made through a ROOT folder plugin.
<session-config>
    <session-timeout>30</session-timeout>
</session-config>

Session Expiration Warning

The session.timout.warning property specifies the number of minutes before a warning is sent to an inactive user session about impending session expiration. This property may be changed by editing the Session section of the portal.properties file (/dotserver/tomcat-X.x/webapps/ROOT/WEB-INF/classes/portal.properties). Note: It is strongly recommended that all changes to the portal.properties file be made through a ROOT folder plugin.

Values:

  • Set this value to 0 to disable any warnings (this is the default value).
  • Set this value to a value less than the Session Expiration timeout to give users a warning before their session expires.
    • For example, if the Session Expiration timeout is set to 30, if you set session.timout.warning to 25 then users will be given a session expiration warning 5 minutes before being automatically logged off.
session.timeout.warning=0