Summary 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 with or without mfa, using web protocols 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: https://mydomain.trustelem.com This URL gives access to a dashboard where all the allowed applications appear. admin URL: https://admin-mydomain.trustelem.com 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. Add users Users created on Trustelem For users that are not stored in corporate directories Users are created in Trustelem administration console or with API https://admin-mydomain.trustelem.com/app#/users 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: https://admin-mydomain.trustelem.com/app#/directories 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: https://trustelem-doc.wallix.com/books/trustelem-administration/page/active-directory-synchronization Users from GSuite It requires to add an GSuite directory on Trustelem: https://admin-mydomain.trustelem.com/app#/directories 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 Most common source of users This directory offers more features than others: users synchronization with their attributes use of the AD passwords into Trustelem login page reset directory passwords using Trustelem complete a passwordless authentication Documentation: https://trustelem-doc.wallix.com/books/trustelem-administration/page/active-directory-synchronization Notes 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 Add applications 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. Add access-rules 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: https://trustelem-doc.wallix.com/books/trustelem-administration/page/access-rules Documentation about multi factors authentication: https://trustelem-doc.wallix.com/books/trustelem-administration/page/multi-factors-authentication Advanced features 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. Documentation: https://trustelem-doc.wallix.com/books/trustelem-administration/page/integrated-windows-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. Documentation: https://trustelem-doc.wallix.com/books/trustelem-administration/page/self-service-password-reset 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 API 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... Documentation: https://trustelem-doc.wallix.com/books/trustelem-administration/page/api Follow the events Admin Dashboard https://admin-mydomain.trustelem.com/app#/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) Logs https://admin-mydomain.trustelem.com/app#/logs Every interaction with Trustelem from administrators, users or directories is visible here. Alerts https://admin-mydomain.trustelem.com/app#/alert 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. Sessions https://admin-mydomain.trustelem.com/app#/sessions 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. How to plan a Trustelem project ? 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