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? Several options:
Option 1: subdomain of your domain name
In order to make the service appear to users as a legitimate service, using something like “elabftw.university.edu” or “eln.company.com” is a good solution.
To achieve this, there is again several possibilities:
Option 1 A: add a CNAME (recommended)
In your DNS Zone, add a CNAME record with your subdomain pointing to an address we will provide 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 1 B: use a proxy
This is not recommended but it is a possibility: the traffic gets directed to a web proxy on your infrastructure, and it is then sent to our service.
Advantages: you keep control over the subdomain’s certificates
Disadvantages: it adds a Single Point of Failure and latency
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! :)