SAFEQ Cloud supports client-based authentication where user authenticates against OAuth2 identity provider such as Microsoft Azure, Google G Suite or Ping Identity platforms, using SAFEQ Cloud PC client. Client-based authentication also allows to use multi-factor authentication in combination with SAFEQ Cloud server.

Client-based authentication must be configured on two sides: the PC Client and the server:

  • Name – choose a name for the authentication provider.
  • Domains – this field should match the domains of the organization and the “@domain” part of the users which authenticate.
  • Priority – A number determining the order in which authentication providers will be called until one succeeds. Higher-priority providers will be called first
  • Type – should be set to “Client” to create a client authentication provider
  • Identity provider – currently the following identity providers are supported: Microsoft Azure, Google G Suite, Ping Identity.

Common

When the user is authenticated on the client side it will be created in SAFEQ Cloud database and visible under Users section, when the corresponding Client provider is chosen from the drop down list. User properties can be changed by the administrator or this user can be added to Access Controls.

  • User expiration policy – choose the policy for user records expiration (see below)
  • Custom user expiration, min – field is visible only when user expiration policy is set to custom one.
  • Service – choose authentication service in this field. In case no service is already created, it can be added using the Add button.

User expiration policy

Traditionally this time is defined by the identity provider and delivered as one of the access token fields. The usual expiration time is one hour but can be changed by the directory administrator. Users must be refreshed by SAFEQ Cloud PC Client periodically, otherwise they won’t be able to print or authenticate. If PC client is not running or offline the user will expire.

Another approach for prolonging user lifetime is to change the expiration policy to one of the custom values: Custom expiration for card login or Custom expiration for all login types and set custom expiration period. For example, if you choose Custom expiration for card login and set 480 to Custom user expiration, mins field, you’ll let to use card for authentication during 8 hours since PC Client or Chrome extension login even if PC client is not running.

For Microsoft Azure

  • Custom application id – this field is optional and it’s used for syncing the Azure groups in case of Identity provider = Microsoft Azure. In case the value is empty, will be used the SAFEQ Cloud build-in client ID. In case of on-premises installations this value must be set.
  • Callback domain for custom application – this field is used only in case the Custom application id is not empty. It should match the Redirect URIs from Azure where the custom application is created.
  • Custom token claim names – in this section, you can define claim names in the token. Their values will be stored in the user attributes after login.

When a new Client authentication provider is created it will have a default group added called Authenticated Users and the groups from Azure (by pressing Sync Groups button) when Azure identity is used (not ADFS). These groups can be used in access controls to enable permissions for authenticated users.

For Google G Suite

  • Impersonated admin account (email) – email of the account with administrative rights in your G Suite domain. Service account that you’ll use for authentication will be limited to the scopes you provide, so SAFEQ Cloud won’t have full administrative access to your domain.
  • Secret JSON file content – paste here the entire content of the secret JSON file that you’ll download when creating the service account.
  • Secret key for Chrome extension single sign-on – (optional) improves security when you want to use Chrome extension without authentication. The key is used to verify authentication requests. You can either generate or enter your own key. The same key must also be set in the Chrome extension in order to work. The key should never be shared.
  • Custom token claim names – in this section, you can define claim names in the token. Their values will be stored in the user attributes after login.

When a new Client authentication provider is created it will have a default group added called Authenticated Users and the groups from G Suite domain (synchronized by pressing Sync Groups button). These groups can be used in access controls to enable permissions for authenticated users.

For Ping Identity

  • Custom application id – required field, the ID of the application created in the Ping Identity portal.
  • Custom application secret – required field, the secret of the application created in the Ping Identity portal.
  • Ping environment id – Ping environment ID
  • Ping region – Ping region, one of “eu”, “com”, “asia”
  • Callback domain for custom application – This field should match the Redirect URIs from Ping application configuration.
  • Custom token claim names – in this section, you can define claim names in the token. Their values will be stored in the user attributes after login.

For Auth0 Identity

Add a new Auth0 authentication provider with configuration of custom fields as explained below.

Custom application id – required field, the ID of the application created in the Auth0 Identity management.
Callback domain for custom application – this field should match the Redirect URIs from the Auth0 application configuration.
Auth0 API client id – optional field, the ID of the Regular Web Application created in the Auth0 Identity management.
Auth0 API client secret – optional field, the Client Secret of the Regular Web Application created in the Auth0 Identity management.
Auth0 Domain – required field, domain of the application created in the Auth0 Identity management.
Custom token claim names – in this section, you can define claim names in the token. Their values will be stored in the user attributes after login.

Custom token claim names
In this section, you can define claim names in the token. Their values will be stored in the user attributes after login.

For example, if the Auth0 provider is returning email value in its token claims (named registered_user_email), you can input registered_user_email into the email field, and upon successful login, the email from the custom token claim will be stored under the email user attribute.

Sync groups

When a new Client authentication provider is created it will have a default group added called Authenticated Users To synchronize more groups use the “Sync groups” button in the provider view.
These groups can be used then in access controls to enable permissions for authenticated users.

For Microsoft Azure or Ping Identity the group sync requires an OAuth2-based workflow. By clicking on the “Sync groups” button a confirmation window will be opened:

In case of clicking OK button, the groups will be retrieved from the identity provider and added or updated in SAFEQ Cloud server.

For Azure identity provider there are two situations:
1. In case the Custom application id field is empty on the client authentication provider, then the sync groups will be done using the SAFEQ Cloud build-in client ID (for build-in client ID is mandatory to be on [custom domain].eu/[us]/[uk]/[ap].ysoft.cloud).
2. In case the Custom application id field is not empty, the value should be taken from a native Azure application. Also, should be a match between Callback domain for custom application and one of the Redirect URIs set for the new created Azure application. In this case the sync groups will be done using the new created Azure application.
Please see the section: Adding a custom app in the Azure directory for more details.

Relevant information:

Feedback

Was this helpful?

Yes No
You indicated this topic was not helpful to you ...
Could you please leave a comment telling us why? Thank you!
Thanks for your feedback.

Post your comment on this topic.

Post Comment