Free cookie consent management tool by TermsFeed

Appian Authentication

On This Page

Purpose

The Appian Authentication page in the Admin Console allows you to control password strength requirements and password expiration policies.

Access

To access the Appian Authentication page, go to the Admin Console. Then, in the left navigation menu, under Authentication, click Appian Authentication.

Settings

Tip:  If you want to hide the user menu for a site, keep in mind that users who sign in via Appian authentication will always see the user menu, regardless of the Hide user menu setting.

The Appian Authentication page contains the following settings.

Password format

Note:  Appian hashes passwords using an industry standard hashing algorithm and only stores the hashed values of passwords. When passwords are entered, they are similarly hashed using the same algorithm, and the result is compared against the stored value.

The Password Format section allows you to set the following:

Setting Description Default
Minimum Password Length Specifies the minimum number of characters allowed in a password. 1
Minimum Number of Alphabetic Characters Specifies the minimum number of characters from the English alphabet (A-Z and a-z) allowed in a password. 0
Minimum Number of Lowercase Characters Specifies the minimum number of lowercase characters from the English alphabet (a-z) allowed in a password. 0
Minimum Number of Uppercase Characters Specifies the minimum number of uppercase characters from the English alphabet (A-Z) allowed in a password. 0
Minimum Number of Numeric Characters Specifies the minimum number of numerals (0-9) allowed in a password. 0
Minimum Number of Special Characters Specifies the minimum number of special characters allowed in a password. Special characters include: ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~ 0
Minimum Password Age Specifies the number of days a user must wait between password changes, where one day is defined as a 24-hour period and not a calendar day. This setting does not affect temporary passwords or the ability for an administrator to reset a user's password. 0
Prevent Reuse of Previous Passwords Specifies how many previous passwords a user cannot reuse. Valid values are between 0 and 24, inclusive. The current password cannot be reused, but other previous passwords can be. 1
Passwords cannot contain usernames Controls whether the user's password can contain their username. Disabled

The settings in this section apply only to passwords managed by Appian and do not apply to accounts that authenticate with LDAP or SAML.

Appian Cloud environments have different default settings than self-managed environments. The following default password policies are in place for Appian Cloud users:

  • Passwords must be at least 7 characters long.
  • Passwords must contain at least 1 numeric character.
  • Passwords must contain at least 1 letter.
  • Passwords must be different from the previous 4 passwords used.

Remember me

Tip:  This setting only applies to users who authenticate via Appian authentication or LDAP. To enable remember me for SAML, see SAML for Single Sign-On.

The Remember Me section allows you to set whether the Remember me checkbox displays on the Appian sign-in page.

If this setting is toggled on, you can use the Maximum Remember Me Time setting to configure the length of time that a user will remain signed in without having to enter their username and password. The maxiumum amount of time is 90 days.

If you disable this setting, users must provide their username and password once every two weeks for each browser on which they access Appian.

This setting does not apply to system administrators. System administrators are automatically signed out when their session expires based on the Session Timeout period.

Session timeout

Session timeout values can be configured differently for basic users and system administrators in your Appian environment. For both types of user, the minimum valid value is 10 minutes, and the maximum valid value is 480 minutes (8 hours).

The session timeout values apply to all applications in your Appian environment.

Setting Description Default
Basic User Idle Session Timeout (Minutes) Specifies the number of minutes that a basic user can remain inactive before the system signs them out. 65
System Administrator User Idle Session Timeout (Minutes) Specifies the number of minutes that an administrator can remain inactive before the system signs them out. 65

Note:  This setting also applies to the sessions of users authenticating through SAML or OpenID Connect.

How session timeout works

Five minutes before the session expires, the system displays a default warning message to the user:

Session expiration warning dialog

You cannot customize this warning message.

After five more minutes of inactivity, the system signs the user out. The user is automatically redirected to the sign-in page or single sign-on page, depending on your configuration.

Once the user signs back in, the user start page displays. The system does not return the user to the page they were using when their session expired.

Password expiration

The settings in the Password Expiration section apply only to passwords managed by Appian and do not apply to accounts that authenticate with LDAP or SAML.

The Password Expiration section allows you to configure the following:

Setting Description Default
Expire Passwords Controls whether passwords should no longer be valid after a certain amount of time. When a password expires, the user must change the password before they are allowed to proceed past the Appian sign-in page. Disabled
Maximum Password Age Specifies the number of days after which a password expires and must be reset. --
Warn Users Before Password Expiration Controls whether users see a warning if they sign in when their password is about to expire. The value must be lower than the number you set for Maximum Password Age. Disabled
Password Expiration Warning Period Specifies the number of days before a user's password expires where they will be warned about their impending password expiration. --
Expire Temporary Passwords Controls whether auto-generated passwords should expire. Auto-generated passwords include the temporary password generated when a new user account is created or when an administrator resets a user's password. Enabled
Maximum Temporary Password Age Specifies the number of minutes after which a temporary password expires. When a temporary password expires, the user cannot sign in and must request that an administrator reset the password. 10,080 (one week)

Appian Cloud installations have different default settings than self-managed installations. The following default password policies are in place for Appian Cloud users:

  • Passwords expire every 90 days.
  • Users are notified regarding password expiration 7 days before it happens.

Initial passwords for Appian Cloud are temporary passwords. The system prompts users to reset their password immediately after signing in to Appian Cloud.

Forgot password

The Forgot Password section allows you to set the following:

Setting Description
Enable Forgot Password from Sign-In Page Controls whether the Forgot your password? link appears on the sign-in page, allowing users to reset their passwords.
Password Reset Link Duration (Minutes) Specifies the number of minutes a password reset link remains valid. If a user clicks an expired link, they must request a new one. Changes to this value apply retroactively to existing links.

When this feature is enabled, only users that meet the following requirements will be able to reset their passwords:

  • The user does not authenticate through LDAP or SAML.
  • The user is not deactivated.
  • The user's password is older than the minimum password age.
  • The user has a valid e-mail address.

If SAML or LDAP is enabled for all users, the Enable Forgot Password from Sign-In Page checkbox is disabled because Appian does not manage those users' credentials. If only some users authenticate through LDAP or SAML, you can enable the feature and the Forgot your password? link appears on the sign-in page for all users.

Use import customization files to change the value between environments with different authentication configurations.

Use of this feature can be audited through the Forgot Password Requests and Password Resets audit logs.

Email templates

The Email Templates section of the Forgot Password section allows you to customize the email messages that users receive when they request a password reset.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeimages/admin-console-email-templates.png

Appian sends two types of password reset emails:

  • Password Reset Email: Sent to users who successfully request a password reset. The email contains the reset link.
  • Password Reset Rejection Email: Sent to users when their password reset request cannot be fulfilled.

Each email template has a customizable Subject and Body. The body editor supports rich text formatting, including bold, italic, underline, strikethrough, text color, highlight color, subscript, superscript, links, alignment, lists, and tables.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeimages/admin-console-edit-email-templates.png

Templates are organized by locale. If you have enabled additional locales on the Internationalization page, a tab appears for each enabled locale so you can provide localized versions of the email templates.

Available variables

Use variables in the subject and body fields to insert dynamic content into the email. Appian replaces the variable with the corresponding value when the email is sent.

The following variables are available for the Password Reset Email template:

Variable Description
{FIRST_NAME} The first name of the user requesting the password reset.
{LAST_NAME} The last name of the user requesting the password reset.
{RESET_LINK} The link the user must follow to reset their password.
{LINK_DURATION} The number of minutes the reset link remains valid, as configured in the Password Reset Link Duration setting.
{SITE_NAME} The name of the site as shown in the Environment Name field.

The following variables are available for the Password Reset Rejection Email template:

Variable Description
{FIRST_NAME} The first name of the user who requested the password reset.
{LAST_NAME} The last name of the user who requested the password reset.
{REJECTION_REASON} The reason the password reset request could not be fulfilled.
{SITE_NAME} The name of the site as shown in the Environment Name field.
Customize email templates

To customize the email templates:

  1. In the Email Templates section, click CUSTOMIZE TEMPLATES.
  2. Select the tab for the template you want to edit: Password Reset Email or Password Reset Rejection Email.
  3. Edit the Subject and Body fields as needed. Use the available variables to insert dynamic content.
  4. Click DONE.
Reset email templates to defaults

To reset both email templates to their default content:

  1. In the Email Templates section, click CUSTOMIZE TEMPLATES.
  2. Click RESET TEMPLATES.
  3. On the confirmation dialog, click YES to restore the default templates.

Note:  Resetting templates reverts both the Password Reset Email and Password Reset Rejection Email templates to their default content. The reset applies only to the locale you are currently editing.

Account locking

User accounts that have difficulty supplying the proper credentials are temporarily locked (prevented from making a sign-in attempt) when the user (or someone attempting to sign in as the user) tries too many incorrect passwords. The system does this by keeping track of the number of failed sign-in attempts for each account. The failed sign-in count is reset automatically after some time has passed from the last failed attempt. This prevents the user from accumulating a large number of failed sign-in attempts over a long period of time.

The Account Locking section allows you to set the following:

Setting Description Default
Lock Accounts After Failed Logins Controls whether accounts are locked after repeated failed sign-in attempts. Enabled
Maximum Password Attempts Specifies the number of failed sign-in attempts it takes for an account to be locked. 6
Password Attempt Reset Duration Specifies the number of minutes after a failed sign-in attempt before the failed attempt counter resets. Set this value high enough to capture repeated failed attempts from someone guessing passwords. 30
Unlock Accounts Automatically Controls whether an account locked due to failed sign-in attempts is automatically unlocked after a certain time period. If automatic unlocking is disabled, accounts remain locked until an administrator manually unlocks them. Enabled
Lock Duration Specifies the number of minutes an account is locked after being locked due to failed sign-in attempts. 30
Limit Number of Concurrent Sessions Per User Account Controls whether users are only allowed a certain number of sessions active at the same time. Disabled
Maximum Concurrent Sessions Specifies the number of sessions a user can have open at the same time before they are no longer allowed to sign in again. --
Deactivate Users Who Have Not Logged In Recently Controls whether users who have not signed in recently are deactivated. Disabled
Idle User Deactivation Duration Specifies the number of days after a user's last successful sign-in before the user account is deactivated. This setting also applies to sessions of users authenticating through SAML. --

The failed sign-in count is reset if the account is unlocked by an administrator.

When you specify a deactivation interval, that same interval must elapse before user accounts begin to be deactivated. For example, if you specify an inactivity deactivation interval of 90 (90 days) on April 1st, a user account that does not successfully sign in between April 1st and June 30th is deactivated. In this scenario, a user account that has not signed in since January 1st also remains active until June 30th, as you did not activate the policy until 90 days after the user account became inactive.

User accounts that are deactivated due to inactivity are listed at the INFO level in db_PE_yyyy-mm-dd_hhmm.log in the <APPIAN_HOME>/logs/ directory.

The system user Administrator is never automatically deactivated.

Appian Cloud installations have different default settings than self-managed installations. The following default password policies are in place for Appian Cloud users:

  • Users who have not signed in are considered inactive after a period of 90 days.

Activity from the Appian Mobile applications does not count towards the number of active sessions a user has and the number of requests from the mobile applications.

See also:

Multi-factor authentication

Appian is automatically configured to require multi-factor authentication (MFA) for users that sign in with Appian authentication. This adds an extra layer of security to the sign-in process since users must provide their Appian username and password, and a custom verification code.

Note:  When you upgrade to version 26.1 or above, you can opt in to have MFA enabled by default. Contact Appian Support if you want to enable MFA in an existing environment.

The Outbound Email Toggle is enabled by default so Appian can send verification codes to users. Also note that when MFA is enabled, users cannot reset their own password unless they have configured an authenticator app. Otherwise, they will need to request that a system administrator do it for them.

The Multi-Factor Authentication section displays different configuration options depending on whether default MFA enforcement is enabled for your environment.

When default MFA enforcement is enabled, you can configure the following settings:

Setting Description
Email Verification Users receive an email with a verification code that must be entered to complete the sign-in process. This setting cannot be disabled when MFA is enabled because email is required as the fallback method for users who have not yet configured an authenticator app.
Authenticator App If enabled, users enter a verification code from an app to complete the sign-in process.

When default MFA enforcement is not enabled, you can configure the following settings:

Setting Description
Enable Multi-Factor Authentication Select this checkbox to require a group of users to sign in using MFA. By default, this checkbox is deselected.
Authentication Group Select the group that is required to sign in using MFA. These users must be configured to use Appian authentication. MFA does not apply to users configured to use SAML, OpenID Connect, PIEE, or LDAP.
Email Verification Users receive an email with a verification code that must be entered to complete the sign-in process. This setting cannot be disabled when MFA is enabled because email is required as the fallback method for users who have not yet configured an authenticator app.
Authenticator App If enabled, users enter a verification code from an app to complete the sign-in process.

When both email verification and authenticator app verification are enabled, users can select their preferred verification method when they sign in.

Scroll or drag to pan · ⌘+/⌘− to zoom · Esc to closeimages/user-signin-mfa.png

Note:  Email verification cannot be disabled when MFA is enabled. It is required as the fallback method for users who have not yet configured an authenticator app. During a user’s first sign in with MFA, email is used as the second authentication factor. Once the authenticator app is set up, subsequent sign-in attempts let the user choose between email and the authenticator app as the second factor.

Email verification

If MFA is enabled, users are required to enter their Appian username and password. Then, the user will receive an email with a verification code that must be entered to complete the sign-in process. This code is valid for 5 minutes, after which a new code must be requested.

If the user requests a new verification code, the existing verification code will be invalidated.

Users only have three chances to enter a verification code before the code is invalidated. Each incorrect entry of the code counts towards Account Locking.

Users are also limited to three verification code requests per fifteen-minute window to maintain sign-in performance and security.

Authenticator apps

Users are required to configure an authenticator app during their first sign-in after this feature is enabled. After initial setup, users can modify their authenticator app configuration in their user settings, which generates a new secret key and invalidates the previous setup.

Users can configure any authenticator app that generates verification codes using the time-based one-time password (TOTP) protocol. This includes popular apps like Authy, Google Authenticator, and Microsoft Authenticator.

Use import customization files to change the value between environments with different authentication configurations.

Reset authenticator app

If your site has MFA enabled by default, system administrators can reset a user's authenticator app configuration from the Users page. Use this option only when the user has previously enrolled an authenticator app and now needs to reset it, such as if the device is lost or replaced. This action will invalidate the current authenticator configuration and require the user to re-register at their next sign-in.

This control is only enabled when the selected user has MFA enabled and has an existing authenticator app configuration.

To reset a user's authenticator app:

  1. On the Users page, select the checkbox of the user you want to reset.
  2. Click RESET AUTHENTICATOR APP.
  3. On the confirmation dialog, click YES.

The user's authenticator app configuration is removed. This action is recorded in the admin audit log.

Terms of service

The Terms of Service Agreement section allows you to set a message on the sign-in page that users must click to accept before entering the system.

Setting Description
Require Users to Accept Terms of Service Before Logging In Controls whether users must accept terms of service before accessing the site.
Terms of Service Specifies the message that appears on the sign-in page.

When you change the terms of service, all remember me authentication sessions will be invalidated and users will need to input their username and password the next time they sign-in to Appian.

Feedback