MFA for Veridium Manager login

The administrators currently access the Veridium Admin Manager via Certificate-based or header authentication. In addition to these, strong MFA options and flexibility for administrators have been added in version 3.5, mirroring the other applications and integrations options that are available for end users.

The functionality can be divided in scenarios varying from the most generic to the more specific ones:

1. Third-party IdP

This is the most generic integration that can contain an external IdP that responds to SAML requests from Veridium Admin. Based on the SAML response, the admin users are created in Veridium and assigned the corresponding permissions based on AD group membership mapping that is already present in previous versions.
No separate enrollment and authentication flows are available in this scenario.

2. SAML provider is Shibboleth with Veridium users

This method uses the existing Veridium enrollment and authentication flows' configuration for Veridium Manager admin login.

This requires an existing user in a Directory Service connected to Veridium via LDAP. Administrators would enroll via the Self-Service Portal and be assigned the corresponding permissions based on AD group membership mapping that is already present in previous versions. User attribute sync will be done during authentication, so when entering the Veridium Manager at the end of a successful authentication, the user will be presented with the appropriate permissions inside it.

Authentication is done through Shibboleth which is configured to consider Veridium as both the Service Provider and the IdP for this scenario.

3. Certificate authentication

Existing authentication mechanism already established are still available: certificate authentication and Proxy (user header) authentication can still be used.

4. Mixed mode

Both Certificate / Proxy authentication and IDP authentication can be required for groups of users, based on configuration.

5. Recovery mode as an alternative backup authentication flow

There are some cases when SAML authentication is unavailable and (e.g initial deployment, system configuration errors). Veridium server will fallback to accept certificate/proxy authentication for all users. Right now the implemented recovery mode is done by adding a explicit java property called security.pre-auth-only . When set on true, then recovery mode is enabled. This parameter can be set in file bin/start-websecadmin.

How to use SAML with current authentication methods in Veridium Manger

In the Veridium Manager authentication process, two primary methods, certificate or headers, are available options. These methods continue to be accessible within the application. Additionally, there is now the possibility of introducing a supplementary SAML authentication step.

It's important to note that the sequence of authentication steps cannot be altered. Initially, users must provide a certificate or headers, and only after successful completion of this step can they proceed to authenticate using SAML. It's essential to understand that failing either of these steps will result in the overall authentication process failing.

How to enable SAML authentication in Veridium Manager

To enable SAML authentication within Veridium Manager, it is imperative to initiate the process by confirming the existence of a well-configured application entry for "veridium-manager." This verification can be performed by navigating to the "Applications" section in the management console.

If the application setup is not in place, you can proceed by visiting the "Admin Auth Settings" page. Within the SAML submenu, the initial step involves thorough verification of the URL placeholders to ensure they are correctly updated. Following this crucial verification step, you can proceed to configure Veridium as the Identity Provider (IdP) by selecting the appropriate action from the menu on the right side of the page.

With all the necessary configurations in place, you can seamlessly activate SAML authentication by simply toggling the switch located within the "General" submenu of the "Admin Auth Settings" page and make sure that you groups are allowed to use SAML.

Group mapping permission for authentication

This feature empowers Veridium groups to mandate the activation of SAML and/or Certificate authentication methods for user access to the application. To validate the group mapping, navigate to the 'Admin Auth Settings' and access the 'General' submenu. Here, you'll find an expanded Group Mapping section, featuring two new fields that define whether SAML and/or Certificate authentication is mandatory.

Note: in order to save the group mapping authentication methods, click Update in the group editing snippet, then Save from the top right corner:

If both ‘Cert or Proxy’ and ‘SAML auth’ are set to true, this means that the user in the corresponding group is required to perform both authentication checks before it is allowed entry. If only one option is set to true then only that is authentication method is required.

If an user has multiple groups assigned and those groups have different authentication configurations then this precedence is applied:

i. if a user is part of any group that has both ‘Cert or Proxy’ and ‘SAML auth’ set to true, then this rule will apply to him upon authentication;

ii. otherwise if a user is part of any group that has ‘SAML auth’ set to true, then this rule will apply to him upon authentication;

iii. otherwise certificate or proxy authentication applies. Note that this option implies also for users that are part of Veridium groups that are not present in this mapping. E.g. Internal Veridium Administrators which are assigned static groups.

Optional configuration - Bindings used for transmitting SAML messages between Idp and SP

In the context of SAML (Security Assertion Markup Language), there are different bindings used for transmitting SAML messages between identity providers (IdPs) and service providers (SPs) during Single Sign-On (SSO) processes. These bindings define how the SAML messages are transported over HTTP.

When enforcing a specific binding in SAML, you are determining how the SAML messages will be transmitted between the IdP and SP. Depending on your security and integration requirements, you may choose either the Redirect or POST binding.

For SSP and Veridium manager SAML settings, we have add this configuration in order to optimise the usage of SAML capability.

Optional configuration - SAML Force authentication

We have introduce the Enable force authnetication configuration, in the SAML tab, to specify that user authentication should be forced during SSO requests to the Identity Provider, regardless of any existing sessions or tokens. This enhances security by ensuring that the user's identity is re-verified during sensitive transactions or access attempts.

Functional considerations:

These are some functional explanations, including specific scenarios with their expected outcomes:

as a general rule of thumb: if a user has simple authentication (i.e. certificate, SSL termination) and SAML available, SAML will be chosen automatically as the preferred auth method.
if a user is member of 2 mapped groups, one group with SAML enabled and one group with SAML disabled, and general SAML method is set to off, the fallback authentication mechanism will choose the condition of the group with no SAML.
administrators need to be enrolled in Veridium via the Self Service Portal (like end-users) in order for SAML authentication to be available for them.
SAML authentication in Veridium Manager are logged in Audit / Sessions tab, similar to the end-user authentications. Detailed status and potential errors can be found in logs, by filtering for class com.veridiumid.websecurity.managers.LoginAudit
if an internal administrator certificate has been defined with externalID = email and there is an identity with the same email address registered as a Veridium user, the account is re-used in all operations. If the identity is blocked (manually or triggered via Authentication Max Retries parameter), then the admin certificate will be blocked also, not allowing the user to login at all (either as admin, or as an end-user)