Skip to main content


WALLIX Trustelem provides Identity-as-a-Service (IDaaS) including a cloud Single Sign-On (SSO) and Multi-Factor Authentication (MFA).

  • Trustelem manages applications authentications, with or without SSO or MFA

The goal is to unify, secure and simplify user access to their applications

  • Block attacks (phishing, social engineering) and protect strategic assets (MFA
  • Increase the efficiency of IT teams (SSO)
  • Improve user experience (SSO)

SSO.png SSO with or without mfa, using web protocols LDAP-Radius.png LDAP or Radius authentication, with or without MFA, but with no possibilities of SSO

Wallix Trustelem has an offer dedicated to WALLIX products (Bastion and Access Manager) which is named WALLIX Authenticator.

When you start with WALLIX Trustelem, you receive a domain.
This domain is used for:

  • users URL:
    This URL gives access to a dashboard where all the allowed applications appear.

  • admin URL:
    This URL gives access to the admin dashboard where the subscription is setup.

In order to do this setup, there are 3 major steps:

  • Add users

  • Add applications

  • Setup access rules

In addition, Trustelem offers a lot of other features like passwordless authentication, self-service password reset, api...
Finally, you have tools to follow each event of your subscription.

Users created on Trustelem
  • For users that are not stored in corporate directories

  • Users are created in Trustelem administration console or with API

  • The attributes of these users are fully editable

  • The passwords associated with these users accounts are stored by Trustelem

  • Trustelem accounts should only be used for:

    • temporary users for testing purpose

    • the definition of a backup administrator

    • users with no entry in directories such as partners, clients…

Users from Azure AD
  • It requires to add an Azure AD directory on Trustelem:

  • Users with their attributes can be synchronized

  • It doesn’t allow the use of the Azure AD password
    Note: in practice it’s possible but it will only work if Office 365 is not federated. In other cases these users have a password stored by Trustelem

  • Synchronization requires the creation of an “application” in Azure AD admin console for authorizing Trustelem to request Azure AD data

  • Documentation:

Users from GSuite
  • It requires to add an GSuite directory on Trustelem:

  • Users with their attributes can be synchronized

  • It doesn’t allow the use of GSuite passwords

  • The passwords associated with these users accounts are stored by Trustelem

  • The GSuite subscription is identified by one of its admin email address

For the moment, the documentation is only available directly on the directory settings, on Trustelem admin console.

Users from Active Directory
  • There are connectors for synchronizing GSuite or Azure AD with Active Directory.

  • An AD synchronized with GSuite or Azure AD can then be synchronized with Trustelem too.

  • Benefits:

    • no password stored
    • self service reset passwords
    • passwordless authentication

There are different kinds of applications:

  • SAML2.0

  • OpenID Connect

  • Basic without SSO

  • LDAP

  • Radius

SAML and OpenID Connect

These protocols are used for Single Sign On authentications.
To authenticate to your application, you need to authenticate to Trustelem with a browser first.
Then, if you go to another application using SAML/OpenID Connect, you are already authenticated to Trustelem so you don't have to provide your credentials again.
Consequently, you have a single sign on.
To setup these applications, you need to establish a trust relationship between the application and Trustelem.
The goal is to give to the application the ability to verify the identity of Trustelem and the URL needed to communicate.
When a user wants to authenticate, the application can redirect him to Trustelem then use the attributes received without risks.
So implementing SSO authentication for a client application consists in:

  • configuring the client application.

  • creating a Trustelem application using:

    • a generic models which will always work with applications supporting SAML or OpenID Connect, but have generic documentation.
    • a pre-integrated models which have a simple setup and detailed procedure.

Example for Google application:


Note: you can find the documentation of each application on their settings page, or on this website.

Basic without SSO

The authentication on these applications is only possible by providing a username and a password stored by the application.
That means Trustelem can't provide the users identity to the application.
Consequently, add an application like that allows to have a redirection link on the user dashboard but not to authenticate.
Note: Trustelem is working on a passwords keeper in order to improve the security and the user experience for these applications.

LDAP and Radius

With these protocols, the authentication on Trustelem has to be done for each authentication on the application.
So the credentials used are still unique, and still the same as for other Trustelem authentications, but it's not a single sign on.
LDAP and Radius can be activated on each kind of generic models, or on specific pre-integrated models (WALLIX Bastion, VPN...).
Note: you can find the documentation on the pre-integrated applications settings page, and you have a global documentation about LDAP and Radius on this website.

When you have users and applications, you can create access-rules in order to define how users will authenticate to an application.
Documentation about access rules:
Documentation about multi factors authentication:

Integrated Windows Authentication (IWA)

Integrated Windows Authentication (IWA) is an authentication using the Kerberos token of the user Windows session.
For a user point of view, it's a passwordless authentication.

Self Service Password Reset (SSPR)

The Self Service Password Reset (SSPR) allows user to reset his password using Trustelem login page.

  • A user provides his login and additional secrets to Trustelem.

  • Then he can define a new password.

  • This new password is saved on Trustelem or sent to Active Directory.



Replace the password by a certificate

By uploading a root certificate or users' certificates on to Trustelem, it is possible to remove the first authentication (login+password authentication).
Documentation: coming soon


Using APIs, you can create your own tools to manage your subscription: synchronize users from local files, build your own form for user creation, create alerts based on the logs...

Admin Dashboard

The dashboard provides a summary of the subscription state:

  • users in the subscription

  • users authenticated

  • unread alerts

  • authentication succeed / failed, with MFA or not

  • number of users by applications

  • number of users by directories (the led indicates if the directory synchronization works, needs attention or doesn’t work)



Every interaction with Trustelem from administrators, users or directories is visible here.



When a user requests help (for an authentication or a self-service password reset), administrators receive an email to notify them of the new alert.
The admin can generate a code/link required to unlock the user.



Users logged in Trustelem are visible here.
The red trash allows the administrators to kill the session.
Note: killing a Trustelem session doesn’t mean users will be disconnected from their applications.


1/ Add users and groups
  • Setup directories if needed

    • Active Directory
    • Azure AD
    • GSuite
    • LDAP
  • Add Trustelem users / groups

  • Define the administrator accounts

2/ Setup Multi Factor Authentication
  • Activate login and auto-enroll for the wanted factors 

  • Select 2 factors for Trustelem admin accesses

3/ Add applications
  • Do the configuration for both applications and Trustelem

  • Verify if the authentication is working

4/ Setup access rules
  • Define the internal / external IP areas of the company

  • Create access rules depending on users, applications, protocols, IP areas, MFA

5/ Activate the needed advanced features 
  • Setup Integrated Windows Authentication

  • Setup certificate authentication

  • Setup self-service password reset

  • Setup the APIs

6/ Get prepared for production phase
  • Prepare the enrolment plan: population, procedure, schedule

  • Communicate to users about:

    • The SSO activation, objectives and date
    • The applications list
    • How to access to Trustelem (login+password, MFA, IWA…)
    • The enrolment plan
  • Communicate a reminder the day before with the same information

7/ Switch to production
  • Activate SSO in the applications

  • Just after the switch, inform users about it

8/ Follow-up
  • Verify in the alerts if there isn’t an abnormal number of users requiring some help

  • Verify with the logs if users actually access their applications