There are several parameters that can be configured to optimize security in Setup > System > Security. Configure each setting as needed to provide optimal security for your system.
The General tab has most of the security options necessary to secure your system. You might use some or all of these features in various combinations to suit your needs.
Restrict Standard Login / Password based access to Agiloft users authenticated by SSO
This option determines whether to restrict standard login/password-based access to only those users who have been authenticated by SSO. With this set to Yes, users who log in with a valid login and password must still be authenticated by SSO in order to access the system.
SSO Endpoint allows an encrypted email hotlink to connect to a custom web SSO application. If you enter an endpoint value here, hotlinks included in emails do not include the login and password for authentication. Instead, hotlinks redirect to the specified endpoint and allow the user to be authenticated and logged in.
Security: Trusted Zones
Use the Trusted Zones option to limit external net resources to a specified list of source addresses. For example, if you add trusted zones here, users are only able to add hyperlinks and embedded images that point to locations inside these trusted zones. You can use this to help protect user data from malicious attacks, such as XSS or XSRF attacks. To use trusted zones, enter a comma- or CR character-separated list of addresses. HTML references outside these addresses aren't allowed.
For optimal security, this global variable should generally be set to /, *.YOUR_COMPANY.COM.
Users can refer to agiloft.com domain, its subdomains and the server host, without defining its name.
Users can refer to any domain in the net and the server host.
References to net resources are disabled.
Only references to the current host are enabled (e.g. /home.jsp).
Security: Allowed Referrers
This option restricts the host names that are allowed as referrers to your server. Enter a comma separated list of host names to use this feature. A value of “*” allows any host name to act as referrers to this server.
Security: Hotlink Master Password
This defines the master password used for checking cookies for those users who selected to save login credentials for generated hotlinks.
Security: Allow scripts in dashboard widgets
This determines whether the system allows scripting in widgets on the dashboard. Select No to disable scripting and help protect users from malicious attacks (XSS, XSRF, etc). This ensures that only safe HTML is allowed.
Security: Allowed External Hosts
Use this option to restrict the host URLs the system is allowed to redirect to. This helps guard against XLS attacks. Specify as many hosts as necessary, delimited by spaces, commas, or semi-colons. To allow any host, enter *. This global variable should generally be set to a value such as *.YOUR_COMPANY_NAME.COM, *.SERVER_URL.COM. For example, *.widget.com, *.widget.enterprisewizard.com *.widget.agiloft.com.
Security: Check Session Match
This determines whether the system requires that the session ID matches the cookie associated with it. If you select Yes and the session ID does not match the cookie associated to that session when the user first logged in, the connection is rejected. This guards against a hacker who can see the user's browser from manually entering the URL.
Security: Check client IP
Determines whether the system checks that all requests are made from the same IP address as the IP address used when the session first started. This helps prevent a hacker who can see the URL or session ID on your computer from initiating a session on another machine.
Note that this feature causes the user to be logged out if they access the system from an ISP or through a gateway that assigns a dynamically changing IP address.
Additionally, this method is not as secure as using Security: Check Session Match because if both PC's are accessing the server through the same NAT or Proxy servers, their IP addresses will seem to be the same.
Security: Informative Password Messages
This determines whether diagnostic messages in password-related functions can contain the account name. If you set this to Yes, you can use the Security: Custom message for “Reset Password” error global variable to define a custom error message.
For optimal security, this variable should generally be set to No.
Security: Custom message for "Reset Password" error
If you set Informative Password Messages to Yes, use this field to define the custom message that appears when an error occurs during password reset. It's best to leave this variable unset or use a message that does not provide any security information, such as "Invalid login/password combination, please contact your administrator."
Security: Show Stack Trace on SoD
This determines whether the stack trace button appears on the SoD screen. Select No to prevent users from seeing the stack trace information. This feature is generally only used when testing a knowledgebase to troubleshoot errors.
Security: Web Services Anti SQL Injection
This determines whether anti SQL injection features are enabled. Select No to disable these features.
Security: Web Services Verbose Errors
This determines whether SOAP and REST calls produce more detailed error messages for debugging purposes. This feature is usually only set to Yes in testing environments, and should be set to No in production environments.
Security: Days to continue support of old key
This defines the number of days to continue the support of old keys. The default value is 31.
Web Services Tab
This tab contains settings related specifically to web services.
Select the groups whose users are allowed to use SOAP.
Security: SOAP IP Blacklist
Any IP address defined in this global variable is unable to access the system via the SOAP interface. If a blacklist is defined, IP addresses on the blacklist are not accepted, and IP addresses outside the blacklist are subject to any other relevant security checks. You may enter IPv4, IPv6, and IP address ranges in a comma-delimited list, such as 10.168.6.102, 10.169.7.132-10.169.7.150. Server-wide settings take precedence over specific KB settings.
If you use the SOAP IP Whitelist, it is generally not necessary to set values in the Blacklist as well. However, the Blacklist is useful if you allow API access from a constantly changing set of IP addresses that do not live within well-defined ranges, but you also want to block access from certain ranges, such as those of foreign countries.
Security: SOAP IP Whitelist
The system allows any IP addresses defined in this global variable to access the system via the SOAP interface. If a whitelist is defined, all other IP addresses are automatically blocked. You may enter IPv4, IPv6, and IP address ranges in a comma-delimited list, such as 10.168.6.102, 10.169.7.132-10.169.7.150. KB-specific settings take precedence over server-wide settings.
For optimal security, set this global variable to the value of the machines from which your SOAP scripts are running. You may also enter 127.0.0.1 to block external access entirely.
Select the groups whose users are allowed to use REST.
Security: REST IP Blacklist
Any IP address defined in this global variable is unable to access the system via the REST interface. If a blacklist is defined, IP addresses on the blacklist are not accepted, and IP addresses outside the blacklist are subject to any other relevant security checks. You may enter IPv4, IPv6, and IP address ranges in a comma-delimited list, such as 10.168.6.102, 10.169.7.132-10.169.7.150. Server-wide settings take precedence over specific KB settings.
If you use the REST IP Whitelist, it is generally not necessary to set values in the Blacklist as well. However, the Blacklist is useful if you allow API access from a constantly changing set of IP addresses that do not live within well-defined ranges, but you also want to block access from certain ranges, such as those of foreign countries.
Security: REST IP Whitelist
The system allows any IP address defined in this global variable to access the system via the REST interface. If a whitelist is defined, all other IP's are automatically blocked. You may enter IPv4, IPv6, and IP address ranges in a comma-delimited list, such as 10.168.6.102, 10.169.7.132-10.169.7.150. KB-specific settings take precedence over server-wide settings.
For optimal security, set this global variable to the value of the machines from which your REST scripts are running. You may also enter 127.0.0.1 to block external access entirely. Be careful when configuring this variable. You can potentially lock yourself entirely out of a knowledgebase if it's configured improperly.
WDC Editor Groups
Users who are part of a group selected in this field have permission to set a saved search to be available in Tableau. This generates a WDC URL that can be used as a Web Data Connector in Tableau.
IP Restrictions Tab
This tab allows general IP restrictions for system access. These settings work together to determine whether a user can successfully access the system, so choose your configuration carefully. These settings are useful if some groups should only have access to the system when they are at a specific location or using a specific workstation or network.
- In the Groups to be Restricted field, select the groups whose access you want to limit based on IP.
- In the Whitelisted IP Ranges field, enter the IP ranges you expect from these users when accessing the system. Users in the groups you selected above will only be granted system access if they log in from a whitelisted IP address. You can enter IPv4, IPv6, and IP address ranges in a comma-delimited list.
- In the Whitelisted Users field, you can select individual users who might be part of a restricted group, but who should always have access to the system, regardless of IP address.
Additional Security Global Variables
In addition to the settings in the Security wizard, there are a few security-related global variables you might want to set. For details on how to access and set global variables, see Global Variables.
Security: Check iframe origin
Description: Determines whether the system requires that KB usage occurs only in an iframe, or an embedded web page, that has the same origin as the KB. If this global variable is set to No, any origin is allowed. If you are using a third-party or external API that displays information in the End User Interface, this variable should be set to Yes.
Default Value: No
Location: Admin Console
Security: Collect System Data on Error
Description: Determines whether to collect and include system information, such as the OS version and IP address, in the data that appears on the automatic bug report screen (SoD). Select Yes to collect and include this information.
Default Value: No
Recommended Values: For optimum security, the recommended value is No.
Location: Admin Console
Security: Show KB Names
Description: Determines whether the generic login page shows a drop-down list of KB names. If set to No, the KB list on the /gui2 login page is hidden, and users need to manually enter the desired KB name.
Default Value: No
Recommended Values: For optimal security, this variable should generally be set to No.
Location: Admin Console