Skip to main content

Authentication

Definition

Soffid could use different kinds of external authentication sources. These mechanisms could be selectively enabled or disabled.

Screen overview

image-1685356857220.png

Standard attributes

Global status

  • Maintenance mode (only administrators can log in): if this option is checked (value is Yes), only the administrators could connect to Soffid Console.

image-1685358837043.png

  • Message to display before logging in: administrators can configure a banner that will be displayed before the user logging in. This banner will display security advice.

image-1685358984524.png

Username and password

Internal

  • Enabled: the only one enabled by default in the installation of Soffid. It is the internal username and password authentication mechanism. Therefore, the authentication is made with the username and password of the soffid account.

External

  • Forward authentication requests to trusted target systems: to use external username and password sources. Therefore, the authentication is made with the username and password of an account of an external system.

Not all the external systems are included, only the ones that have marked the check "Trust password" on the agent. For more information about agents please visit the Agents page.

Once an agent is configured, Soffid will still use its internal tables to authenticate usernames and passwords.

If the password entered by the user does not match, the Soffid core will issue a "ValidatePassword" task for each trusted target system. If any of the trusted target systems accepts the password, it will be hashed and stored in Soffid tables and login will be accepted.

External SAML identity provider 

It should be noted this feature does not depend on the federation addon. That is a feature included by default in the Soffid smart engine to allow you to include in the authentication flow a mechanism to use a third-party SAML system.

  • Enable: check it (select value Yes) to use an external SAML Identity Provider.
  • Soffid Server host name: the URL that will be used by external IdP. This URL will be resolved by end user's browser in order to send the SAML assertion.
  • SAML federation metadata: the URL where federation information can be found. If the Soffid console can fetch federation metadata, the Identity provider drop-down will be filled in with any identity provider found in the federation metadata URL.
  • Cache limit (seconds): how often the federation information will be refreshed. By default, 10 minutes will be taken.
  • Identity provider: Identity Provider to use for authentication.

Finally, download the Soffid Console and load it into your SAML Identity Provider federation.

If SAML Identity Provider is enabled, as well as username and password, the user will have the chance to select the preferred authentication method. Otherwise, if only SAML is enabled, the user will be automatically redirected to SAML Identity Provider.

image-1685358871521.png


Enable LinOTP integration

Soffid allows you to use an external OTP, LinOTP in this case. If you decide to use LinOTP, Soffid could be configured to request the user to authenticate using a second factor authentication to perform certain actions. In another case, you can use the Soffid OTP.

  • Enabled: check it (select value Yes) to use an external SAML Identity Provider.
  • LinOTP server URL:  URL of your LINOTP service.
  • LinOTP admin username: username of the admin account used by Soffid.
  • LinOTP admin password: password of the admin account used by Soffid.
  • LinOTP users domain: the user's domain for LinOTP authentication. The selected user domain will guess the LinOTP username for any Soffid identity. It is extremely important when LinOTP users do not match Soffid usernames. Please visit the Account naming rules page for more information

If you want to configure the Soffid OTP you could visit Two factor authentication (2FA) chapter.

Second Factor Authentication configuration

This section requires to have the LinOTP integration enabled (previous section)

  • Pages that optionally require OTP authentication for users with an enabled token: (Optional) If a URL optionally requires OTP authentication, and the user does not have any OTP token, access will be granted. Otherwise, if the user has an OTP token, the OTP value will be required, and no access will be allowed until the user provides the right token value.
    • You can include the list of pages to include the two factors only for the users with the token.
💻 Example

Request only the OTP for these pages:

image-1691657269637.png

    • You can add a regular expression to determine the list of pages to always include the second factor to the users with the token
💻 Example

Request OTP for all pages except those containing menu.zul or otp.zul:

image-1691736830460.png

  • Pages that require OTP authentication to any user: (Mandatory) You should include the list of pages to always include the second factor to the users with the token. Therefore, if a URL strictly requires OTP authentication, users with no token won't be allowed to use them.
💻 Example

image-1692278416756.png

  • Second factor authentication period: number of seconds after that, a new OTP value will be required.

In both configurations, if OTP is required by the user, a popup requesting the token value is raised to write the OTP value.

Actions

Download metada

Allows you to download an XML file with metadata to load it into your SAML Identity Provider federation when you use an External SAML identity provider

Confirm changes Allows you to save the changes made in the Authentication setup.