Difference between revisions of "OS4X Enterprise Webaccess multi-factor authentication"
| (4 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | [[File:Bildschirmfoto 2023-11-14 um 10.54.49.png]] | + | [[File:Bildschirmfoto 2023-11-14 um 10.58.48.png]] [[File:Bildschirmfoto 2023-11-14 um 10.54.49.png]] |
= Purpose = | = Purpose = | ||
| − | In | + | In critical environments, having users to authenticate to use OS4X Webaccess is often required to support additional means of identification. OS4X Webaccess multi-factor authentication is a functionality to support this requirement. Authenticated users then must: |
#provide a valid username and password | #provide a valid username and password | ||
#must have access to their user email inbox, where a dynamically created token is sent to | #must have access to their user email inbox, where a dynamically created token is sent to | ||
| Line 17: | Line 17: | ||
*Mail subject: Subject of the sent email to the user, encoded as UTF-8 mail subject (so special characters can be added here as well). If unconfigured or empty, the subject text "OS4X 2FA" is being used. | *Mail subject: Subject of the sent email to the user, encoded as UTF-8 mail subject (so special characters can be added here as well). If unconfigured or empty, the subject text "OS4X 2FA" is being used. | ||
*Mail sender address: Sender of the email, given in the mail header. If unconfigured, the value "OS4X <os4x>" is used. | *Mail sender address: Sender of the email, given in the mail header. If unconfigured, the value "OS4X <os4x>" is used. | ||
| − | *Sendmail command: command which is being executed for emailing. If unconfigured, the system's default "sendmail" command is used. | + | *Sendmail command: command which is being executed for emailing. If unconfigured, the system's default "<code>sendmail</code>" command is used. |
== User configuration == | == User configuration == | ||
| Line 24: | Line 24: | ||
Every user requiring MFA must be enabled. There exists no global configuration to activate the feature system-wide. The default is "off", so no MFA functionality is used. If the functionality is activated, a valid email address must be configured for this user. If no email address is configured for a user, the functionality is disabled during login. | Every user requiring MFA must be enabled. There exists no global configuration to activate the feature system-wide. The default is "off", so no MFA functionality is used. If the functionality is activated, a valid email address must be configured for this user. If no email address is configured for a user, the functionality is disabled during login. | ||
| − | = | + | = Behavior = |
For users with enabled MFA, after each successful authentication via username and password, a prompt will be presented asking for the dynamically created token. Three attempts entering the token can be made. If the code is incorrect after these three attempts, the user session is destroyed and he must re-authenticate for a new session. | For users with enabled MFA, after each successful authentication via username and password, a prompt will be presented asking for the dynamically created token. Three attempts entering the token can be made. If the code is incorrect after these three attempts, the user session is destroyed and he must re-authenticate for a new session. | ||
| Line 30: | Line 30: | ||
For every user requiring MFA, the OS4X client daemon is asked to send out a MFA email. The dynamic token is saved on server-side in the user session. After successful authentication with the token, the dynamic token information is removed from the user session. If a (typically malicious) web request is executed leading to a user session with a MFA token inside, the user session is destroyed, forcing the user to re-login. | For every user requiring MFA, the OS4X client daemon is asked to send out a MFA email. The dynamic token is saved on server-side in the user session. After successful authentication with the token, the dynamic token information is removed from the user session. If a (typically malicious) web request is executed leading to a user session with a MFA token inside, the user session is destroyed, forcing the user to re-login. | ||
| − | The MFA email is rendered by the OS4X client daemon in [[OS4X_Core_configuration#run_OS4X_programs_as_user| | + | The MFA email is rendered by the OS4X client daemon in [[OS4X_Core_configuration#run_OS4X_programs_as_user|its configured user context]] using the configured MTA. |
= A word about portal users = | = A word about portal users = | ||
Latest revision as of 10:14, 14 November 2023
Purpose
In critical environments, having users to authenticate to use OS4X Webaccess is often required to support additional means of identification. OS4X Webaccess multi-factor authentication is a functionality to support this requirement. Authenticated users then must:
- provide a valid username and password
- must have access to their user email inbox, where a dynamically created token is sent to
Configuration
OS4X Webaccess MFA contains of several configuration parameters.
Global configuration
The global configuration is located in "Configuration" -> "OS4X Enterprise" -> "Webaccess" -> "Multi-factor user authentication".
- Multi-factor authentication mail template: A mail text template (which is automatically created for updated OS4X installations) containing HTML code for the email. The variable "
$MFA_TOKEN" will be replaced during template rendering. - Mail subject: Subject of the sent email to the user, encoded as UTF-8 mail subject (so special characters can be added here as well). If unconfigured or empty, the subject text "OS4X 2FA" is being used.
- Mail sender address: Sender of the email, given in the mail header. If unconfigured, the value "OS4X <os4x>" is used.
- Sendmail command: command which is being executed for emailing. If unconfigured, the system's default "
sendmail" command is used.
User configuration
Every user requiring MFA must be enabled. There exists no global configuration to activate the feature system-wide. The default is "off", so no MFA functionality is used. If the functionality is activated, a valid email address must be configured for this user. If no email address is configured for a user, the functionality is disabled during login.
Behavior
For users with enabled MFA, after each successful authentication via username and password, a prompt will be presented asking for the dynamically created token. Three attempts entering the token can be made. If the code is incorrect after these three attempts, the user session is destroyed and he must re-authenticate for a new session.
System internals
For every user requiring MFA, the OS4X client daemon is asked to send out a MFA email. The dynamic token is saved on server-side in the user session. After successful authentication with the token, the dynamic token information is removed from the user session. If a (typically malicious) web request is executed leading to a user session with a MFA token inside, the user session is destroyed, forcing the user to re-login.
The MFA email is rendered by the OS4X client daemon in its configured user context using the configured MTA.
A word about portal users
The MFA token is generated on portal server side. The OS4X portal daemon periodically fetches MFA tokens from every configured portal server, sends out the email from the internal network to the configured email address and deletes this information on portal side. This offers the functionality to be only configured on internal zone and suppresses the need for a configured MTA on DMZ side.
Logging
Every sent MFA email token is being logged in OS4X's system log containing the email address and the token value.