System Configuration

The System Configuration area is split into logical sections, to facilitate use. Each section has system settings relating to that area which can be viewed and, in most cases, edited. Some settings are very powerful so care should be taken before changes are made. A full list of the settings available can also be found in the Support > Documents folder. Please contact the support team via https://frontofficehelp.biomni.com/hc/en-us/requests/new for further information.

This article covers the following topics:

• User Login to Front Office
• Windows Authentication
• Active Directory Import
• Configuring Front Office to use Federated Single Sign-On
• Edit web.config to Enable Federated Single Sign-on
• New User Account Requests

User Login to Front Office

There are three different ways for a user to access Front Office: Windows Authentication, Single Sign-On, or entry via a login page. For further information about Single Sign-On, please contact the support team via https://frontofficehelp.biomni.com/hc/en-us/requests/new.

When user login is required, password rules can be defined to align with in-house security policies. This functionality is set up within the System Configuration section in the Settings category. A customer configured message can be displayed against the User ID field, to assist new users with their login, e.g., “Login using email address”. ‘Remember me’ functionality can provide the reinstatement of the previous session, although as this effectively keeps the user logged in, password expiration policies may be contravened. The ‘Remember me’ duration should be set to a compatible timescale.

If a user is refused login for whatever reason, a non-specific message is displayed. This includes exceeding the normal number of allowed password attempts when the account is locked. The user sees the same message displayed throughout. If a user exceeds the allowed number of password attempts, they may reset their password by using ‘Forgotten Password’ functionality on the login page.

The user’s password is encrypted in the database using a salted one-way algorithm, ensuring that passwords cannot be compromised even by database administrators who have direct access to the system’s database.

System Configuration Settings:

• Enable ‘Forgotten Password’ functionality
• Force AlphaNumeric passwords
• Login Page / User ID help message
• Minimum length of new password
• Number of Previous Passwords Retained
• Password Retries Allowed
• Period of time before password expires (days)
• ‘Remember Me’ duration
• When Should Passwords Expire

Windows Authentication

To use Windows Authentication, users must be set up in the database with user names matching the users’ domain names, e.g., dependent on the system setting, this would be either ACME\john.smith or john.smith.

Configure the Remove Domain Name system setting i.e., switch on if using john.smith or off if using ACME\john.smith.

Once at least one Windows user has access to the Administration area, IIS should be set as Anonymous Authentication and Forms Authentication both disabled and Windows Authentication enabled; configuration within IIS will ensure the web.config file is updated, and Front Office access changed accordingly.

The shipped ‘ADMIN’ user ID can only be used to access the system until Windows Authentication is configured in IIS. After that point, no manual login is available.

Note: if using Active Directory to sync users, ensure that at least one user is associated to the ‘Supervisor’ access profile on initial import, otherwise access to the Admin area is compromised.  Note: these instructions only apply to configuration on initial implementation of the system and are not appropriate for later changes to the login protocol due to impact on historical data. Please contact the support team via the Community at http://community.biomni.com/home for further information. 

System Configuration Settings: Set Domain Name rules for User login.

Active Directory Import

Front Office can be synchronized with Active Directory for easier maintenance. Import is managed via a scheduled import task, allowing a specified time or a frequency to be specified. The schedule should reflect the full user set as any user not included will be deactivated in Front Office.

Multiple import profiles can be created, using a different source for each profile. For each profile a Front Office access profile, cost center and user account status must be specified, and the users may be automatically assigned to zero or more user groups. However, the user group must already exist in Front Office. The Front Office User Name can be sourced from either ‘Full Name’ (default) or ‘Display Name.’ A language may be optionally selected, otherwise the system base language will be used. An import profile can be specified by group or organizational unit, with or without ‘children’ included.

Import profiles will be processed from the top of the list and so can be re-sequenced as appropriate. If the same user is present in multiple profiles, only the Imported User Fields from the latest profile processed will apply. User group membership will be updated from all profiles.

The user-specified within the Active Directory import requires the List Contents and Read All Properties rights at the root level of the domain specified to be able to search all organizational units/groups and import all users.

A system configuration setting allows control of whether the Domain Name should be pre-pended to
the user ID when importing. It is important to verify the appropriate setting value prior to creating the first user accounts as a subsequent change will cause new user accounts to be created and existing accounts disabled, along with the attendant impact on accessing historical requests. The Active Directory import process uses an unchanged identifier to verify whether to add or edit an existing user record. This means that the User ID can be changed at source and be updated in Front Office during the import, with no duplication or intervention required. This process assumes that an Active Directory import has already run post-upgrade to Front Office 9.1, as this will populate the User GUID, and thus allow matching on User ID change.

Exceptionally, it is possible to create locally maintained ‘Front Office’ users, for records not maintained in Active Directory. These users will be ignored by the Active Directory update.

Note: if using Windows Authentication, ensure that at least one user is associated to the ‘Supervisor’ access profile on initial import, otherwise access to the Administration area is compromised. 

Note: these instructions only apply to configuration on initial implementation of the system and are not appropriate for later changes to the login protocol due to impact on the ‘user maintained’ method. Please contact the support team via https://frontofficehelp.biomni.com/hc/en-us/requests/new for further information.

Configuring Front Office to use Federated Single Sign-On

Front Office supports Federated Single Sign-On via the WS-Federation Passive Protocol. It is implemented with Microsoft Windows Identity Foundation (WIF), and uses SAML tokens for claims transfer. However, it does not support the SAML2 Protocol, SAML-P.

When Front Office is installed, it is configured with Forms Authentication requiring first login to utilize the “admin” account. To authenticate via the identity provider:

1. Create users in the Front Office database, who correspond to users in the identity provider.
2. Edit the Front Office web.config file to enable Federated Single Sign-On.

Create a user in Front Office

In Front Office users are identified by their “User ID”. In the identity provider users are identified by “Claims”. For authentication to be successful, users in Front Office must have a User ID matching the value in one of the claims from the identity provider.

Front Office looks at the following claims when attempting to find the Front Office user: Name, Email, WindowsAccountName and UPN. Typically Name and Windows Account Name have the format domain\username, and typically Email and UPN have the format username@domain.

Users can be entered through the portal or imported in bulk, either directly from Active Directory or via a .CSV file.

Edit web.config to Enable Federated Single Sign-On

This section describes the change to web.config to enable Federated Single Sign-On:

1. Navigate to \WebSite
2. Open web.config with notepad, as Administrator.
3. Find the section and uncomment the two IdentityModel modules:
   
4. Find the <authentication section and change the mode to “None”
   
5. Enter the URL of the WS-Federation web site in the issuer attribute of the element
   
6. Find the section and type in the token-signing certificate thumbprint of the WS-Federation server. NOTE: cut & paste should not be used as it may insert hidden characters into the file which interfere with the thumbprint matching).
   
7. If on a test system, using self-sign SSL certificates, uncomment the element:
   
8. Save the web.config file.

If a switch back to Forms Authentication is required, e.g., to recover from a problem, the web.config file can be edited, and the authentication mode set to forms:

Login to Front Office

The system should now be fully configured for Federated login.

1. Close Edge and re-open
2. Type in the URL of Front Office
3. If using test certificates, accept the two certificate errors
4. Enter the credentials for the user-created earlier. The user should be successfully logged in.

New User Account Requests

For user login configurations, a hyperlink labeled New User Registration can be displayed to allow for new user requests. A pop-up screen will display a contact email address.

System Configuration Settings:

• Enable the ‘New User Registration' link on the Home Page
• Notification email address for new user account requests