Introduction
To get started with your hosted eLabFTW instance, a few things need to be decided and configured.
Domain name
This is the first thing to decide: where will the service be hosted?
The domain name is the name of the user facing website for the service. For example:
- elab.uni-vancouver.ca
- eln.uni-vancouver.ca
- elabftw.uni-vancouver.ca
Please choose a domain name similar to the ones above, and let us know via email.
We will not be able to setup your instance without this information.
This section is intended for IT Staff at your institution or company.
Please choose one of these two options:
- Option 1: use a subdomain of your institutional domain name (e.g. elab.example.edu)
- Option 2: let us provide you with a subdomain on a domain we control (e.g. your-company.elab.one).
See details below.
Option 1: subdomain of your domain name via CNAME
In order to make the service appear to users as part of your institutional infrastructure, you will need to modify your DNS settings to add an alias (CNAME) to our internal address.
In your DNS Zone, add a CNAME record with your subdomain pointing to the address that we provided you. For example:
CNAME elab.example.com => example.elab.one
We use Let’s Encrypt for TLS certificates, so if you have CAA record, this needs to be adjusted.
Option 2: subdomain on our domain
We simply use something like startup-name.elab.one and there is nothing to do on your side.
Users authentication and lifecycle
Primary Authentication
You’ll want to decide how users will authenticate to the system, and this is also tied to how user accounts are created.
Option 1: straightforward email and password
This is the default and doesn’t require further configuration, except 2FA and password complexity and lifetime rules. Users can register accounts from the Register page, or we can disable this option and let Admins or Sysadmins create accounts beforehand. We can also restrict the domain names allowed for emails, to prevent users registering accounts with a personal email.
Local password policy
If local passwords are used, a password policy must be enabled. By default, only the minimum password length is enforced (12).
Things that are possible:
- increase minimum password length
- enforce having at least one upper and one lower case characters
- enforce having at least one upper, one lower case and one digit
- enforce having at least one upper, one lower case, one digit and one special character
The maximum number of days since last password change (default is 3650 days). We recommend no less than 365 days.
Option 2: SAML
This is the recommended approach if you have centralized authentication in place already. Once the instance is UP, we provide you with the /metadata.php link so the SP can be added to your IDP. Users can then be created automagically on their first login: they’ll be asked to select a team, and the team Admin will validate the account (or not).
Secondary Authentication
It is possible to enable two-factor authentication (TOTP). By default, only Sysadmin accounts are forced to enable it. Let us know if you wish to force its usage for all Admins or all Users, too.
Email configuration
The application needs to send emails, for notifications or password reset.
Option 1: use our system
We provide SMTP service through SMTP2GO (hosted in Europe).
Option 1 A
The emails will come from “notifications@elabf.tw”. You have nothing to do with this option.
Option 1 B
We configure properly the subdomain with SPF and DKIM to make the notifications come from elab.example.com.
Option 2: use your system
We can also configure eLabFTW to use an application account on your SMTP server. You will need to provide us with credentials.
Conclusion
There are many ways eLabFTW can be configured, some more straightforward than others. The point being that there is always a solution! :)