Authentication providers

Introduction

For users to access the Web UI’s, submit print jobs or release using the embedded terminals, mobile Apps or similar, users must be authenticated. In the Authentication Providers configure how a vendor’s or customer’s users are authenticated.

SAFEQ Cloud server supports three main authentication types:

Local user authentication
Authentication to external directory based on service account
Authentication to external directory performed on the client side (client-based authentication)

Local user authentication

This is the simplest authentication type where the users are created and managed manually in the SAFEQ Cloud server, under the built-in “Local authentication provider”. By default there are few users predefined for each created account, including the admin user.

It is recommended to keep the local admin user as a fallback login in the case when other authentication methods don’t work anymore, for example due to the network issues or a service disruption on the external provider side.

Authentication based on service account

This type of authentication requires to create a service account on the external identity platform which has permissions to search and retrieve users. SAFEQ Cloud supports the following identity platforms for service accounts: Microsoft Entra ID, LDAP (including Active Directory), Okta.

Service account details (username and password) should be entered in the authentication provider settings. Users can authenticate against SAFEQ Cloud server using all available login types: password, card ID, short ID.

The limitation is that the multi-factor authentication (MFA) is not supported for Microsoft Entra ID or LDAP when using service accounts.

Client-side authentication

This type of authentication requires SAFEQ Cloud PC client software which uses interactive browser-based authentication provided by the identity platform. It is not necessary to define service accounts and the MFA is fully supported.

The limitation with this authentication type is that it is not possible to login using username and password from the embedded terminal. Only card ID and short ID login is supported. It is possible, however, to login using one-time passwords, for example for card registration. OTPs can be generated manually in the web UI or automatically by the triggers. See section One-time passwords for more information.

The authenticated user has a limited validity time which is defined by the identity platform and the token expiration, typically one hour. SAFEQ Cloud client will automatically renew the token as long as it stays online.

Authentication configuration

The following authentication provider types are available:

Local – Local authentication provider, will authenticate users against the internal users database in SAFEQ Cloud.
LDAP – LDAP authentication provider enables authentication using LDAP/LDAPS against Active Directory, Novell eDirectory and IBM Domino.
Azure AD – Microsoft Entra authentication enables authentication against Microsoft Entra ID. How to configure Azure AD authentications.
OKTA – OKTA authentication enables integration with OKTA authentication service. How to configure OKTA authentications.
Client – Client authentication is a special authentication type which is performed by SAFEQ Cloud PC client on the client side. How to configure client authentications.
External – SAFEQ Cloud supports external authentication provider where external authentication service such as External Card Repository is used to identify user from different authentication provider.

New vendor or customer accounts always get the Local Authentication Provider added by default, and cannot be removed.

There is no limit to the number of authentication providers which can be added, for multiple domains etc.

Every provider has its priority number that can be changed (higher number means higher priority) and is used for every logical operation where the order of providers matters.

Warning: in a production environment where numerous users are enrolled into the system, deleting an Authentication Provider will result in users information not being available anymore for Authentication, retrieving Card numbers, Short ID etc… as users records are bound to the Authentication Provider ID that was used when adding into the database.

See additional instructions for configuring specific authentication providers: