Login policy and behavior

The Bravura Security Fabric Front-end supports multiple, configurable methods of authentication.

Users can prove their identities by validating their passwords against:

In order to set up password authentication for users whose passwords are not stored in Bravura Security Fabric , configure the following:

Login process with password authentication

The following example login process illustrates how the above settings affect the Front-end :

The process for the administrative consoles is similar; however, Step 2 does not apply. In all cases Bravura Security Fabric uses information from the user’s profile to determine the correct login ID for each target system that it validates the password against.

See also

You can use multiple Bravura Security Fabric question sets to authenticate users. You can require users to have a set that is user defined, in which the user defines both the questions and the answers, and a pre-defined set, in which users define only the answers.

Users can define the questions and answers in their profile in one of two ways:

In order to set up security question authentication, configure the following:

See also

An authentication method must be enabled to make it available to users. By default, password authentication and security question authentication are enabled. You can enable or disable methods by configuring the Front-end.

Alternatively, you can enable more complex authentication methods by configuring authentication chains.

To enable authentication methods via Front-end configuration:

Adding options to the authentication menu

When more than one authentication method is enabled, the Front-end displays a menu of available authentication methods to users after they have been identified.

When password or security question authentication is enabled in PSFEXT VALUES, the option is automatically included in the menu.

If you enable a custom authentication method by including it in PSFEXT VALUES, you must edit the Bravura Security Fabric skin files to include the option in the authentication menu. See Adding to the authentication menu to learn how to do this.

Alternatively, you can add a custom authentication method to an authentication chain and make that available in the default authentication chain.

Click below to view a demonstration of an authentication chain being altered. In this example, a product administrator corrects an undesirable authentication chain to one using unique authentication methods. Currently, users are prompted with a choice of password or security questions as a first authentication factor, and then required to use security questions again as a second factor. This authentication chain is not best practice, as each method should be unique. Therefore, the product administrator removes the selectable security-questions option for the first authentication factor. As a result, the user is only prompted to provide password authentication as the first factor, followed by security questions as the second factor.

The following identification and authentication options can be accessed via Manage the system > Policies > Login options .

"" "" = {
  "address" = "https://mercury/default"
  "module" = "psa"
  "sessionid" = "S6542aa5d-ab83-422a-bda4-870a5376dd15"
  "userid" = "superuser"
}

"" "" = {
  "redirect_url" = "https://mercury/default/cgi/psa.exe"
  "parameters" "" = {
    "USERID" = "superuser"
  }
  "retval" = "0"
}

This section describes the general authentication options on the Manage the system > Policies > Options menu.

You can use a plugin to retrieve a pre-defined password value when the help desk performs a password change.

The plugin point is set by the GET PASSWORD EXT plugin point on the Manage the system > Maintenance > System variables configuration page.

To keep the user’s password secure, the help desk user sees only the description of the new password on the Change passwords page. The help desk user can then provide this password description to the caller. The actual password is kept secret from the help desk user , but is known to the caller from its description. For example, “the new password is the first 6 characters of the user’s social security number.”

The caller should be instructed to change their password to a different value as soon as possible, using one of the Bravura Pass self-service modules, or transparent password synchronization.

There are no shipped programs for this plugin point.

"" "" = {
  "sessionid" = "<session ID>" # The session ID of the logged in viewer/requester
  "recipient" "user" = {} # The user being assisted
         
  "viewer" "user" = {} # The help desk user providing assistance
}

"" "" = {
  "password" = "<the new password>" # The password used in the password reset
  "description" = "<description>" # The notice to display to the help desk user
}

In some cases it may be easier to prevent certain users from accessing specific objects, rather than trying to find a way to grant limited user access. Use the ACL DENY ENABLE setting on the Manage the system > Policies > Options page to allow product administrators to deny read and write permissions to objects by selecting appropriate checkboxes under the Access control tab.

It is possible for users to belong to more than one group with configured access controls for the same object. Set ACL DENY ENABLE to:

For example, a user belongs to group A with permission to read object C, and also belongs to group B which is denied all access to object C. The Allow permissions to take precedence setting means the user does have read permission for object C.

You can use the ADMIN PASSWORD EXPIRE setting (Manage the system > Policies > Options) to configure a global value for the number of days until product administrator s’ passwords expire. If this setting is not configured, then the product administrator ’s password uses the default password policy’s expiry interval. You can override both of these settings for individual product administrators by setting the Password never expires option on the user’s configuration page.

ADMIN PASSWORD EXPIRE only applies to product administrators whose passwords are stored in the Bravura Security Fabric database. It does not apply to product administrators whose passwords are verified against a target system.

Normally, when an invalid user or account ID is entered in the login screen Bravura Security Fabric displays a message informing the user that the account could not be found.

This behavior can be modified to make it more difficult for an attacker to deduce valid IDs from the login process, by enabling the GENERIC LOGINFAILURE option (Manage the system > Policies > Options). If enabled, users are allowed to proceed to the Verify password screen and enter a password, despite having entered an invalid ID. Bravura Security Fabric simulates an attempt to verify the password, waiting 10 seconds before returning with the message:

"Please verify that you entered your password correctly, otherwise contact your administrator."

You can configure a lockout of an IP address for authentication attempts using the IP LOCKOUT DURATION , IP LOCKOUT INTERVAL , and MAX IP FAILURE system variables at Manage the system > Policies > Options.

The IP lockout applies to all failed authentication attempts.

To set up an IP lockout, you must set a value for MAX IP FAILURE to indicate the maximum number of failed login attempts.

You can enter a custom value for the IP LOCKOUT DURATION to determine the number of seconds for which the IP will be locked out. The default value is 60 seconds. After the configured amount of time has elapsed, authentication attempts can resume once again for any account from this IP address.

You can also use the ipunlock program to immediately unlock an IP address.

You can set IP LOCKOUT INTERVAL to change the number of seconds to wait between a failed login attempt and the next login attempt. The default value is 5 seconds. The lockout counter is increased for each failed authentication attempt during this interval period and then reset once the configured number of seconds has been reached.

When disabling the IP lockout functionality, disabling MAX IP FAILURE alone does not automatically clear any outstanding IP locks. The configured IP lockout duration as defined by IP LOCKOUT DURATION must be reached, or you must run ipunlock to allow authentication attempts once again for an IP address.

See usage information for ipunlock .

See Event Actions for more information about event configuration.

You can restrict which source IP addresses are allowed to set the ’X-Forwarded-For’ HTTP request header. The GLF ALLOWED PROXIES variable (Manage the system > Policies > Options) uses a comma-delimited list of CIDR bitmasks of connection source IP addresses and ranges from which an ’X-Forwarded-For’ HTTP request header is to be trusted. This prevents any HTTP client from avoiding IP lockout by pretending to forward to random IP addresses.

If a connecting peer does not specify the HTTP request header, its IP address is considered the true source address for IP-lockout considerations.

If a connecting peer specifies the HTTP request header, and its IP address is specified in GLF ALLOWED PROXIES , then the HTTP request header value is considered the true source IP address, rather than the connecting peer’s IP address.

If a connecting peer specifies the HTTP request header, but its IP address is not specified in GLF ALLOWED PROXIES , then the connecting peer’s IP address is considered the true source address for IP-based lockout policy, and a warning is written to the Logging Service regarding a possible spoofing attack.

This option is only used when authentication chains are enabled.

The LOCKOUT INTERVAL variable (Manage the system > Policies > Options) allows you to specify a number of minutes between failed login attempts that would affect the lockout counter.

If the number of minutes between failed login attempts is greater than the lockout interval, then the lockout counter is reset.

If the number of minutes between failed login attempts is less than the lockout interval, then the lockout counter increases.

If the lockout interval is unspecified, then the lockout counter increases with each authentication failure and is not reset until authentication is successful, or the user’s profile has been re-enabled after a lockout.

By default, when attempting to authenticate a user, there is a maximum number of authentication failures allowed before the user is locked-out from Bravura Security Fabric . This is controlled by the the MAX USERAUTH FAILURE setting (Manage the system > Policies > Options).

To enable a user profile, locked-out users can contact the help desk and request re-activation, or if the LOCKOUT DURATION has been set, Bravura Security Fabric automatically re-enables the account after N minutes.