Admin UI - Security Settings

Security Channel

securityChannel

This should be set to http if users should access your site with URLs starting in http. If you want users to access your site over secure HTTP and have a certificate, you should set this to https. Users would then access your site at URLs starting with https.

Any

Restrict User List to Site Administrators

restrictUserListAccessToAdmins

This determines whether users other than those with site administrator permissions should be able to view the list of all users who have used the XNAT instance. 

If set to Restricted, only site administrators will be able to see the list of site users. This is more secure, but this can make it harder for users to add other users to their projects. If set to Not Restricted, then any user of the site can see the list of all the users of the site.

Not Restricted

Allow Non-administrators to Create Projects?

uiAllowNonAdminProjectCreation

This determines whether all users are able to create projects, or only site administrators. If set to Allow, any user can create a project. If set to Do Not Allow, then only site administrators can create new projects.

Do Not Allow is more appropriate for situations in which the XNAT instance is intended for distributing a limited set of data, while the Allow option makes more sense for XNAT instances which are intended to give large numbers of users a place to manage their data.

Allow

Allow non-administrators to find and claim unassigned sessions?

allowNonAdminsToClaimUnassignedSessions

Should this site allow non-administrator users to search the prearchive for unassigned sessions and claim any sessions matching the patient name, patient ID, or study date they provide?

Disabling this removes the "Find my study" feature and can help prevent users from stealing another user's data. But it can also make it harder for users to get their data into XNAT and increase the burden on site administrators.

Allow

Display Host Name in Footer

displayHostName

• When set to Always the host name is always displayed even in a single-server deployment.

• When set to Multinode, the host name is only displayed when XNAT nodes detect a multi-server configuration.

• When set to Never, the host name is not displayed

When Multinode

Resource Rendering

allowHtmlResourceRendering

Setting this to "Allow" will mean that resources specified in the whitelist below will be rendered by your web browser. Rendering includes execution of any code that might be present. See: How To Restrict Rendering of XNAT Resources

Do Not Allow

Resource Rendering Whitelist

htmlResourceRenderingWhitelist

List all allowed resource file extensions, separated by commas (ex: "png, jpg, gif"). You can use a single * item to allow all file extensions. Note: do not include the “.” character.

See: How To Restrict Rendering of XNAT Resources

bmp,gif,jpeg,jpg,png,tiff,txt,xml

IPs that can send emails via REST

ipsThatCanSendEmailsThroughRest

This must be a regular expression (do not include bounding '/' characters) which matches trusted IPs from which users or pipelines should be able to send emails via an XNAT REST call. By default this is set to allow all IPs but should be changed so that malicious users cannot use this to send phishing emails.

Multiple IPs should be separated by pipe ("|") characters.

^.*$

Require User Login

requireLogin

If required, then only registered users will be able to access your site. If not required, anyone visiting your site will automatically be logged in as 'guest' with access to public data.

Required

Enabled Authentication Providers

enabledProviders

Specifies the authentication providers that are currently enabled on the XNAT server. "localdb" refers to the default XNAT provider.

localdb

Hide User Registration Options

securityNewUserRegistrationDisabled

If set to TRUE, this setting will disable new user localdb registration and conceal all links to the registration page. This will not block external users users from registering for the site via project access request email

False

(Registration enabled on home page)

Disable Local DB Project Access Requests

securityExternalUserParDisabled

If set to TRUE, this setting will disable the ability to send project access requests to non-registered emails

False

(Project Access Requests enabled for localdb)

Disable External Project Access Requests

securityLocalDbParRegistrationDisabled

If set to TRUE, this setting will prevent localdb registration of un-registered users via project access request email.  The project access request email will redirect users to the LDAP/External Login registration page instead of the localdb registration page.

False

(Project Access Requests enabled for external auth)

Session Timeout

sessionTimeout

This controls how quickly user sessions should time out without user activity on a page.

When users go to new pages in XNAT, their auto-logout timer in the upper right corner or the screen resets to whatever the session timeout is set to. Entering text into a text box is not sufficient to reset the timer, but submitting it is. Users can always click 'renew' in the upper right to reset this timer and when a user is getting close to being timed out, there will be a warning modal and they will have a chance to then renew their session.

When the session timeout is changed, it will take effect for all future users who log in (a Tomcat restart is not necessary for this to take effect). But users who are already logged in will still have the old auto-logout interval until they log out and log back in.

This setting uses PostgreSQL interval notation (e.g. '1 day', '3 hours', '5 weeks', '1 year').

15 minutes

Alias Token Timeout

aliasTokenTimeout

This controls how quickly alias tokens should time out. Long time intervals pose greater security risks, but short time intervals could pose problems if you are trying to do processing using an alias token and do not have enough time to complete it before the alias token times out.

This takes effect immediately, and existing alias tokens will be invalidated if they were created more than the interval amount of time ago (e.g. setting this to '1 hour' will invalidate alias tokens created more than an hour ago). However, all alias tokens are not checked every second to see whether they have expired.

You can control how frequently this is checked by changing the Alias Token Timeout Schedule preference. The length of time between checking for alias token expiration should be less than the length of time after which alias tokens expire. For example, if you set the alias token timeout to '2 hours', but set the alias token timeout schedule to run once a day, some alias tokens will remain valid for up to 26 hours (2 + 24), while others will be invalidated after two hours (if the daily check happens right after an alias token completes its second hour of existence).

This setting uses PostgreSQL interval notation (e.g. '1 day', '3 hours', '5 weeks', '1 year').

2 days

Alias Token Timeout Schedule

aliasTokenTimeoutSchedule

This controls how often alias tokens should be checked to see whether they have expired (invalidating those that have). This preference is explained someone in the previous Alias Token Timeout section, which is heavily related.

This setting uses basic Cron notation (lists and ranges aren't supported). 0 0 * * * * translates to “every hour”

0 0 * * * *

Session Timeout Message

sessionTimeoutMessage

This controls what the message will be when a user's session times out. After being logged out, they will be redirected to the login page and this message will show up.

Shortcode: TIMEOUT_TIME will be replaced by the actual timeout time (e.g. Wed Oct 26 21:21:05 UTC 2016).

Session timed out at TIMEOUT_TIME.

Maximum Concurrent Sessions

concurrentMaxSessions

This controls how many sessions a single user can have open at one time. If you want to run a large number of pipelines at the same time as a single user, you may need to increase this. Or if you want to prevent users from opening a lot of sessions, you might want to use a much smaller number.

A Tomcat restart is required for changes to take effect.

1000

Login Failure Message

uiLoginFailureMessage

This is the message that will show up whenever a user tries to log in to the site and the login fails. This will usually be because the username/password combination was incorrect. This could also be because they had previously entered so many incorrect passwords that they are locked out of their account. If the site has multiple authentication providers, then it may also be the case that the user entered a valid username/password combination but selected the wrong provider. Another possibility is that the user trying to log in has already hit the maximum number of concurrent sessions they are allowed to have.

If the login failure message contains %d, then the %d will be replaced with the value for the maximum failed logins preference. You are able to use HTML tags in your message, though we have not tested messages with very complicated HTML.

By default, the login failure message is set to:

Your login attempt failed because the username and password combination you provided was invalid or the site is currently at the maximum number of user sessions. After %d failed login attempts, your user account will be locked. If you believe your account is currently locked, you can:
<ul>
  <li>Unlock it by resetting your password</li>
  <li>Wait one hour for it to unlock automatically</li>
</ul>

Maximum Failed Logins

maxFailedLogins

This is the number of consecutive times that a user can fail to log in before they get locked out. This count resets after every successful login.

If this is set as 5, a user that incorrectly enters their password 5 times but then gets it right on their sixth try will not be logged in because they their account will have been locked after their fifth attempt.

If you do not want users to ever be locked out for failed logins, you should set this to -1.

Changes to this setting take effect immediately. If you raise the number of maximum failed logins, users who had hit the old maximum number of failed logins, but who had fewer failed logins than the new maximum should be able to log in again.

20

Failed Logins Lockout Duration

maxFailedLoginsLockoutDuration

This is the time period users should be locked out if they hit the maximum number of failed logins.

This setting uses PostgreSQL interval notation (e.g. '1 day', '3 hours', '5 weeks', '1 year').

1 hour

Reset Failed Logins Schedule

resetFailedLoginsSchedule

This controls how frequently users whose lockout has expired are re-enabled. A task will run and reset the failed login counts of all users who have already been locked out for the Failed Logins Lockout Duration. This will only re-enable users that have been locked out due to failed logins, not those who have been locked out due to inactivity, or users who have explicitly been disabled by an admin. 

This schedule should be expressed in Cron notation.

0 0 * * * *

Reset failed login count on forgot password?

canResetFailedLoginsWithForgotPassword

Indicates whether a user should be able to click the link from a forgot password email to reset their count of failed logins. If enabled, a locked out user will be able to request a forgot password email and click the link from that email to change their password and unlock their account.

Enabled

User Inactivity Lockout

inactivityBeforeLockout

This is the amount of time a user can be inactive before they get locked out of the site and have to re-enable their account. Users who have not logged in for this period of time will be locked out the next time the scheduled task that locks out inactive users runs (the frequency of this task running is controlled by the Inactivity Lockout Schedule).

This setting uses PostgreSQL interval notation (e.g. '1 day', '3 hours', '5 weeks', '1 year').

1 year

Inactivity Lockout Schedule

inactivityBeforeLockoutSchedule

How often to check user accounts for inactivity (0 0 1 * * ? means it runs at 1AM every day).

This schedule should be expressed in Cron notation.

0 0 1 * * ?

Interactive Agent IDs

interactiveAgentIds

Regular-expression patterns that define user-agent header values that indicate whether a particular request comes from an interactive agent (e.g. a browser) or some other kind of tool, such as curl or other scriptable or automatable client. Separate multiple agent IDs with commas.

The default setting is:

.*MSIE*., .*Mozilla*., .*AppleWebKit*., .*Opera*.

Data Paths

dataPaths

Ant patterns that define URL patterns that represent data paths (e.g. REST API calls). XNAT uses these paths in conjunction with the interactive agent IDs above to determine the response to certain calls. For example, instead of simply returning a "404 Not Found" error when an inaccessible resource is indicated, a call to a data path by a browser may be redirected to the login page. Separate multiple data paths with commas.

The default setting is:

/xapi/**, /data/**, /REST/**, /fs/**

Password Complexity

passwordComplexity

This is a regular expression that controls what passwords will be considered sufficiently complex. When users register or change their password, they are required to choose a password that matches this regular expression. If their new password does not match the regular expression, they will be prompted to choose a new one.

By default this regular expression is set to ^.*$, which will match any password string. If you want to require that users choose more complicated passwords, you can change this to whatever Java regular expression you like. 

For example, this regex requires a password of at least 8 characters, with upper and lower case, a number, and a non-numeric symbol: 

^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.[\W]).{8,}$

^.*$

Password Complexity Message

passwordComplexityMessage

This is the message that users will receive if they try to choose a new password that does not match the Password Complexity regular expression.

As a best practice, change this to include a description of what is needed to satisfy the regular expression. For example, you may want this message to be 'Passwords must be at least 8 characters long and contain at least one digit'.

Password is not sufficiently complex

Password Expiration

passwordExpirationType

This set of radio buttons controls password expiration. This setting can be set to:

• Disabled: Passwords will never expire and users can continue to use the same passwords for as long as the site exists

• Interval: Passwords expire after a specified interval of time

• Date: Any passwords that were last changed before the specified date will be considered expired

This setting exposes related settings, as defined below

Interval

Password Expiration (Interval)

passwordExpirationInterval

This setting is only used if Password Expiration is set to "Interval". It represents the interval of time after which unchanged passwords expire and users have to change them.

Having a short expiration interval can help protect against people who find someone's old password (e.g. if a user's password is included in requests which get written to a log file that a malicious user gets access to) by making it less likely that their old password is still valid. However, the risk of a short interval is that it can lead to people writing down their passwords or choosing new passwords that are nearly identical to their old passwords.

This setting uses PostgreSQL interval notation (e.g. '1 day', '3 hours', '5 weeks', '1 year').

1 year

Password Expiration (Date)

passwordExpirationDate

This setting is only used if Password Expiration is set to "Date". It represents the interval of time after which unchanged passwords expire and users have to change them.

This can be useful when upgrading from an old version of XNAT to ensure that user passwords are stored with the latest security improvements. It can also be useful to expire by date if there is concern that malicious users might have been able to get access to passwords before that date (e.g. if  before a certain date you had been writing user passwords to log files which were archived in an unsecure place).

Password Reuse Restriction

passwordReuseRestriction

This is what determines whether users are able to reuse old passwords.

• If set to 'None', then users will be able to reuse passwords they have used previously without any restrictions.

• If set to 'Historical', then users will be unable to change their password to a password that had been used within the time period specified in the Password History preference.

None

Password History

passwordHistoryDuration

This setting is only used if Password History is set to "Historical".

This is the period of time for which users cannot reuse passwords. By default the Interval is set to '1 year', so users cannot change their password to any password they used in the last year. Once it has been a year since they used a given password, they can use it again.

This setting uses PostgreSQL interval notation (e.g. '1 day', '3 hours', '5 weeks', '1 year').

Require Passwords To Be Salted

requireSaltedPasswords

This setting is only settable via the Site Config API

This controls whether users whose passwords are not currently salted in the database will need to change their password.

Whenever users register or change their password, their passwords will be salted and then hashed before being stored in the database.

However, when migrating users from earlier versions of XNAT, there may be some users who have not changed their password since XNAT started salting all passwords. If this setting is set to 'Required', these users will be required to change their password when they first log in.

In addition, the default XNAT admin user, 'admin', does not have a salted password, so if this is set to 'Required', the admin will have to change their password (which they should be doing anyway). Having all user passwords be salted makes it harder for a user to discover what a user's password is, even if they have access to the users database table.

Require CSRF Token?

enableCsrfToken

This controls whether the site should require CSRF tokens. CSRF tokens are important for preventing Cross-Site Request Forgery attacks on your site. By default this is set to 'Required', which means that CSRF tokens will be used, and forged requests from malicious users will be ignored since they will not have the necessary CSRF token.

If this is set to required, CSRF attacks on POST, PUT, and DELETE REST calls will be prevented. If set to 'Not Required', then your site will likely be vulnerable to Cross-Site Request Forgery attacks.

Required

CSRF Email Alert

csrfEmailAlert

This controls whether the site admin should receive an email every time a possible CSRF attack is taking place. By default, this is set to 'Disabled' (meaning the site admin is not alerted of possible CSRF attacks), but should be enabled if the site admin is particularly concerned about Cross-Site Request Forgery attacks.

Disabled