5 – Server parameters

Server parameters relate to the location and environment of the server on which you are running RefTracker.
5.1 Instance type: This parameter is set to either “in-house” for instances of RefTracker that are run on customer’s own hardware, or “hosted” for instances run on Altarama’s hosted network. The parameter allows the system to respond to a small number of technical differences in how these two environments are handled.
5.2 Allow background processing: This parameter is normally set to “Yes”. Setting this parameter to “No” will stop all defined Background processes defined under System>Batch process menu>Background processing, until this parameter is reset to “Yes”. Such a change would generally be done at the request of Altarama or your IT department. As housekeeping is done via a background process it is not a good idea to leave this parameter turned off for any length of time.
5.4, 5, and 6 LDAP parameters : These parameters all relate to the Dynamic Lookups Web service. See the Dynamic Lookups manual for more information about these parameters.
More details about these Network login options are provided in the Auto logon option setup section of this manual. Changes to these parameters do not come into effect until after a system restart.
5.10 Network ID scope: This parameter determines whether you want staff to be able to log into RefTracker automatically based on their Microsoft network login or IP address without having to enter their id and password, and how the autologon signon should operate to control access. If Authentication is chosen, you can use auto logon for some users and not for others based on whether network signon information has been included in their individual RefTracker signon. Auto logon can also be used to ensure all users log in through a signon management system such as Siteminder.
Using Auto logon can save a lot of time for staff who always use RefTracker from their usual work station, especially those staff who regularly move in and out of RefTracker as they receive RefTracker emails, however it is not always able to be used by all RefTracker systems, and even when it can be used, is not always applicable to all staff members.
None – Network logon is not used. Staff log in is through the RefTracker reft998 page.
Authentication – Network log is used but manual login is also allowed.
The network variable is checked to determine who the user is. When redirected back to the RefTracker staff interface, an attempt is made to match the discovered user with a RefTracker staff user. If a match is made then the user is logged in, if there is no match then the user is presented with the option of logging in manually using the reft998 login page as per normal.
Authorisation – Only access through Network logon is allowed.
Same as above BUT if there is no match the user is not given the option to login using reft998. In other words, the user has to be known to the Network AND there must be a match against a RefTracker staff record.
5.11 Auto login variable: This parameter is used to choose the network variable that will be used to authenticate users for network logon.
- IP Address (REMOTE_ADDR): if your library uses fixed IP addresses
- Authentication user name (AUTH_USER), Windows user name (LOGON_USER), or Remote user name (REMOTE_USER): if your library uses Windows authentication in relation to your RefTracker system. These three variables are made available to RefTracker and you can choose to use the one most appropriate to your network. Unless your IT department specifies otherwise, the most usual choice is AUTH_USER. By choosing one of these variables, and having that value for that user in the ‘Staff number’ field’, you can interface to network control products such as SiteMinder.
- IV_USER for Tivoli WebSeal (HTTP_IV_USER): allows authenticated users from an IBM Tivoli Access Manager WebSEAL Single-Sign-On system to have their authentication passed through to RefTracker. This means that authenticated staff are automatically logged in via an association between their TAM credential and their RefTracker sign-on in the staff ‘Staff number’ field.
Parameters 5.12, 13, 14, 15, 16, and 17 are used with SSO – For full details of how to set up SSO click here. Changes to these parameters do not come into effect until after a system restart.
5.12 Staff: SSO setting:
None – SSO is not used. Staff log in is through the RefTracker reft998 page.
Authentication – SSO is used but manual login is also allowed.
A call Is made to the Identity Provider to determine who the user is. When redirected back to the RefTracker staff interface, an attempt is made to match the discovered user with a RefTracker staff user. If a match is made then the user is logged in, if there is no match then the user is presented with the option of logging in manually using the reft998 login page as per normal.
Authorisation – Only access through SSO is allowed.
Same as above BUT if there is no match the user is not given the option to login using reft998. In other words, the user has to be known to SSO AND there must be a match against a RefTracker staff record.
5.13 Client: SSO setting:
None – SSO is not used. Clients go directly to the client side home page without an SSO check.
Authentication – Access is limited to SSO users and client contact details are automatically inserted in RefTracker forms, if provided.
A call Is made to the Identity Provider to determine who the user is. If the user is identified by the SSO server, any contact details about that user, that are provided by the SSO server, will be automatically inserted in the RefTracker client interface request form.
Authorisation – For future use only – currently does the same as authentication.
5.14 SSO type:
*Important* – set to OIDC or SAML as appropriate to the type of SSO in use.
5.15 SSO Identity provider:
Not applicable to OIDC SSO.
For SAML SSO – Contains the URL of your chosen IdP. Initially this should be the same as the PartnerIdentityProvider Name value in your saml.config file. For full details of how to set up SSO click here.
5.16 Network logout page: System administrators can specify a page to which the user (staff member) is redirected upon logging off. Once the RefTracker session is ended, the user’s browser session is immediately redirected to the address specified in this Parameter 5.16 ‘Single-Sign-On logout page redirect’.
This feature is important to be set in situations where a RefTracker system has been configured to use autologin in conjunction with a Single-Sign-On system or SAML base SSO; the user begins a Single Sign On (SSO) session before they are passed into the RefTracker staff interface, and is redirected to this SSO logoff page when logging out of RefTracker to terminate the session. e.g. If the value at Parameter 5.16 is ‘http://www.google.com’ on logging out the user’s browser tab will be set to that address.
Customers not using this feature for SSO systems may want to use it take their staff to a staff home page after logging out of RefTracker. If there is no URL specified here the user will be presented with the RefTracker login screen after logging out of RefTracker.
5.17 Change user: Set this to Yes for users logged in under SSO to be offered the option to log on as a different user after they log out of RefTracker.
Set it to No if, for security reasons, users should not be offered the option to log on as a different user when SSO is in place.
5.20 Allow staff remember me cookie: Allows the staff remember me functionality to be turned off, but before you decide to turn it off, consider the following.This parameter must be turned off if SSO is in use, and canno tbe turned back on while SSO is in use.
- The cookie used is encrypted and does not contain any password information.
- When a user is automatically logged in, the system clearly identifies who they have been logged in as and provides clear instructions as to how to log in as a different user.
- If a different user logs in, the cookie will be updated to their details if they tick “Remember me”, and if they do not tick “Remember me” the previous staff login details will be removed from the cookie.
- The system log clearly indicates whether a logon was manual or automatic so administrators can tell how access was obtained.
- The details facilitating this “Remember me” functionality for staff are stored in the same RefTrackerUser cookie that the client interface “Remember me” details are stored in – but the details are stored separately so it can be used for both purposes on one computer.
- This parameter works in co-operation with parameter 2.2.
5.21 Staff remember me expiry: In co-operation with parameter 2.1, this parameter provides control over how long a staff Remember me cookie will remain if it is not being used, ensuring that staff logon details that have not been used for the period that you specify in this parameter, will expire, and be unable to be used.
5.30 Standard DB timeout: The number of seconds before a database operation will presumed to be timed out. This value is necessary as it will ensure that an appropriate error message is created if the SQL server used by RefTracker does not respond. A timeout message may mean that your SQL Server is busy or unavailable, or it may simply mean that the operation that RefTracker asked it to do, took longer than expected. If you have a very large database or a busy SQL server you may need to increase the value in this parameter.
5.31 Long operation DB timeout: The number of seconds before a complex database operation like a Search using multiple parameters, will presumed to be timed out. This value is necessary as it will ensure that an appropriate error message is created if the SQL server used by RefTracker does not respond. A timeout message may mean that your SQL Server is busy or unavailable, or it may simply mean that the operation that RefTracker asked it to do, took longer than expected. If you have a very large database or a busy SQL server you may need to increase the value in this parameter. The maximum time that you should need to wait for a response from RefTracker is the value in this parameter.