Features overview
This section provides an overview of the features provided by the TrustBuilder platform.
1. User-centric and policy-based
TrustBuilder is a superior Identity & Access Management (“IAM”) platform available as a Software-as-a-Service. It is superior thanks to its two fundamental principles:
Identity-centricity to put your user’s interests in one focal point. This contrasts with traditional IAM that lets people adapt to the technical application landscape.
Policy-based to put your organization’s interests in a second focal point. This contrasts with traditional IAM where policies are only implicit and are only implied by the actual assignment of permissions and roles, and by coded scripts and workflows.
Based on these two key principles, TrustBuilder also introduces the concept of ‘persona’ to enable security administration at scale. It achieves scale thanks to its self-service model combined with policy-based validation and proofing.
TrustBuilder refines the Identity & Access Management domain as follows:
Identity management focuses on knowing the user, while access management is focused on protecting your assets and enforcing your policies to use them. Making this distinction clear reinforces our two fundamental principles stated above and differentiates us from traditional IAM.
This model also clarifies the difference between what happens beforehand and what happens when people interact. Whereas the former is focused on the joiner/mover/leaver lifecycle, the latter is focused on decisions on the spot.
2. Identity Management
Identity Registration is the process of setting up a user profile for a person, registering one or more personas and maintaining the lifecycle thereof. TrustBuilder is unique because it decouples the management of a user profile from managing access through the concept of ‘persona.’ It allows more self-service, more accurate lifecycles and more streamlined workflows.
Universal directory
TrustBuilder decouples the concept of ‘user profile’ and the different accounts needed for access. It thereby takes the concept of a ‘Universal Directory’ very literally: all people involved in your digital services and digital resources are identified within the same directory, ranging from workforce to external people like suppliers, distributors and customers.
Additionally, also ‘Things’ such as IoT devices are identified in the same Universal Directory and enjoy the same functionality of registration, provisioning, authentication and authorization.
On top of the encryption provided by our cloud services provider, TrustBuilder adds its own layer of encryption. There is no way for the cloud services provider to recover TrustBuilder-supplied keys or to recover any encrypted data without TrustBuilder supplying those keys. Even in case the cloud services provider were subpoenaed, they will not be able to supply cold data in the clear to foreign authorities.
In order to make the encryption measures described above effective, TrustBuilder implements very strong key management procedures. These procedures fit in the TrustBuilder ISMS (Information Security Management System) that is certified against ISO 27001 on an annual basis. The procedures limit the number of staff members that manage the keys, ensure segregation of duties and ensure full auditability.
Ensure that your subscription includes the option “Universal Directory”.
Universal user profile
Within this model, TrustBuilder fundamentally implements the model of “every user has one and only one profile” even if they have different subscription accounts and even when they work with different mandates or in different capacities.
To enable this, TrustBuilder introduced its persona-model. A user profile in TrustBuilder can embody one or more different ‘personas.’ Please refer to Working with Personas for a broader description of the TrustBuilder “persona” concept.
A persona denotes a user segment in business terms, as illustrated above. You may have a user segment of employees, one of consumers and one of corporate customers, one for suppliers, another for distributors and resellers, etc. Since a person may be assigned one or more personas, that person can belong to one or more user segments. For example, an employee can also act as a consumer at times. And yet, the person only needs a single user profile.
Ensure that your subscription includes the option “Universal Directory”.
Progressive profiling
TrustBuilder does not require people to supply all information at once, and does not ask for data that is not relevant at a certain stage.
For example, TrustBuilder allows a kind of “remember me for next time” function when the user interacts for the very first time. Another example is delegated administration whereby initially only an email address is provided. The user can then activate their profile by clicking on magic link, accepting a push notification, or scanning a QR code. Later during their journey, the user may be asked additional information if and when relevant for getting additional access.
In general, TrustBuilder allows you to start with a user profile that only has a username. Other details can be added later, either provisioned by your own sources (such as a HR system or a CRM) or by the user themselves. Please refer to Defining custom attributes for an overview of the user profile definition and how it can be extended. To be recognized at a later stage, users can add an authentication factor of their choice, such as passwordless TrustBuilder MFA and Windows Hello.
Ensure that your subscription includes the option “Universal Directory”.
Persona
TrustBuilder offers an identity model based on its concept of ‘persona.’ Every person receives a single user profile to which one or more personas are added. A persona reflects the role the person relative to your organization and your digital services. The persona concept allows you to segment your users, even when users belong to more than one segment. The persona concept further allows policies to differentiate between user segments, including authentication policies, provisioning policies, attestation policies and authorization policies. Please refer to Working with Personas for a broader description of the TrustBuilder “persona” concept.
Ensure that your subscription includes the option “Persona”.
Identity Lifecycle
User profiles at TrustBuilder have a lifecycle. In combination with progressive profiling and self-service, a user can add or update attributes. Additionally, personas can individually be added, approved, activated and deactivated.
When it comes to revoking access for a person, it is not the user profile that will be deactivated. Instead, it is one of the personas that will be deactivated or suspended. This way, TrustBuilder uniquely allows a user to still use their user profile to identify themselves, while you can finetune the way they can access your resources by selectively add, activate and deactivate personas.
Furthermore, the persona concept allows you to implement different lifecycles for different types of personas. For example, co-worker personas may be treated differently with different processes and approval chains than supplier and reseller personas.
The lifecycle of a persona is maintained using following attributes:
“status” with values “pending,” “active,” “inactive”
“valid_from” and “valid_till”
Please refer to Working with Personas for a full description of these attributes.
Ensure that your subscription includes the option “Persona”.
Certified Identities
As an EU player, TrustBuilder fully supports registrations through a person's national e-ID or bank ID. For you, this means high levels of assurance in the identity. For the person, this means a one-click registration experience.
TrustBuilder currently supports FINeID, Mobilivarmenne, Audkenni, France connect, MoieID, Authenticao.gov, FREJA eID, MyBank, Authenteg, Giropav ID, NEM ID, .beID, itsme, HELIX, http://pl.id , BankID, Id numérique, PostID, BankID PA Mobil, Idea, Titulná stránka -... - UPVS , Buypass, Idento.one, Smart-ID, COMMFIDES, ID-porten, SwissID, Digitaliseringstyrelsen, Jolocom, TUPAS, eParaksts, Luxtrust, Verimi, Finanssiala, MiniID.
Ensure that your subscription includes the option “Certified Identities”.
Social Integrations
TrustBuilder provides people the freedom to start their journey with you using a social account (such as Facebook, LinkedIn and WordPress) or an OS account (such as Google, Apple and Salesforce). Please refer to Identity Providers for configuring social integrations. Enabling initial registration using such accounts reduces registration friction on mobile devices.
A social account is not only useful during initial registration; it can also be used as one of the authentication factors for returning users. TrustBuilder also enables users to link multiple social accounts and to unlink social accounts at a later stage.
Ensure that your subscription includes the option “Social Identity”.
Just-in-time registration
In case you already have a user repository in place, such as an IAM platform, Active Directory, LDAP Directory, or Certificate Authority, and you need a smooth migration with minimal impact onto the user experience, TrustBuilder supports just-in-time registration. This scheme registers a user the first time they log in. Using just-in-time registration, TrustBuilder will register the user in its own repository using data from your existing user repository.
From an authentication perspective, this may also include password validation after which the password is rehashed and stored by TrustBuilder. This way, people are not asked to reset their password as a result of the migration. Please refer to Just-in-Time migration for a description of this process.
Ensure that your subscription includes the option “Universal Directory”.
Deep local integration
As a SaaS platform, TrustBuilder offers a TB.Connect component that can be installed within or close to your IT environment, be it on-prem or in your private cloud. TB.Connect is installed on-prem or in your private cloud and runs on a separate server from your domain controller. Through the Admin Portal, you configure it to have access to your Domain Controller.
TB.Connect enables TrustBuilder to call upon your databases, applications and repositories to obtain information, such as derived attributes and on-the-spot risk rating. TB.Connect also enables TrustBuilder to push certain updates to your databases, applications and repositories in its provisioning flows.
For example, TB.Connect enables direct integration with an on-premises Active Directory or LDAP for user provisioning, de-provisioning, and authentication requests. TB.Connect is combined with the TrustBuilder cloud service itself to form a highly available, easy to set up and maintain architecture that supports multiple use cases.
TB.Connect includes connectors for security and connectivity infrastructure such as Cisco, F5, Checkpoint, Radius and Juniper.
Ensure that your subscription includes the option “Information Broker.”
3. Authentication Management
Identity Authentication is the process of recognizing a returning user and asking them to prove they own the corresponding user profile. TrustBuilder is unique because it considers authentication as an event during the lifecycle of a session. Once identified with a single user profile, TrustBuilder initiates a session. Afterwards and depending on the circumstance and needs, TrustBuilder will ask the user to authenticate.
Universal login
TrustBuilder Universal Login defines your login flow and session management. Each time a user needs to prove their identity, your applications redirect to the Universal Login and TrustBuilder will do what is needed to verify the user’s identity.
TrustBuilder Universal Login does not require integration work to handle various flavors of authentication. You can start off using username and password. You can also add other features such as social login and multi-factor authentication. All of this is dynamic and adjustable in real time without requiring application-level changes. Your application will benefit from any improvements TrustBuilder makes in the login flow without the need for you to change your code.
Create a consistent, branded login experience by customizing the login page appearance and behavior from the TrustBuilder admin portal including the logo, colors, fonts and language. For more advanced use cases, you can adopt your own styling and journey or adopt our SDK. Please refer to Hosted Login for the ready-to-use logon screens.
Ensure that your subscription includes the option “Single Sign-on”.
Single sign-on
TrustBuilder provides single sign-on that enables users to access any number of applications or services using a single login step. If you have 25 applications and 17 cloud platforms, they can all be made available with one login, one click.
TrustBuilder achieves single sign-on experience using federation protocols, token exchange and many more features.
Single sign-on enables a user to access multiple applications, websites and apps after a single login, but it requires those applications, websites and apps to be connected to the same identity management system, e.g. the same Active Directory or the same CIAM.
Ensure that your subscription includes the option “Single Sign-on”.
Federated authentication
Federated identity management offers single sign-on experience for applications, websites and apps that are not connected to the same identity management system. It achieves this by set of agreements and standards that help applications, websites and apps of different domains to share user identities and to pass on authentication events.
TrustBuilder offers support for SAML2, OAuth2 and OIDC1 (see Glossary ), whereby security tokens, such as JWT and SAML assertions, pass on permissions from one organization to the other. TrustBuilder also enables tokens to be exchanged from one domain into another. Please refer to Application integrations for connecting applications, platforms and digital services to our SSO.
Ensure that your subscription includes the option “Single Sign-on”.
Passwordless
Passwordless login enables the user to perform the authentication procedure without remembering and entering a password.
The TrustBuilder MFA enables a user to authenticate using the biometrics of their device, e.g., fingerprint or face-id. The device previously enrolled by the user thus provides proof of the presence and digital identity of the user.
The TrustBuilder MFA has its own SDK that enables this authentication method to be built into any mobile app. The SDK even allows the authenticator to be used on a regular PC, with or without a camera or fingerprint scanner. The TrustBuilder MFA further enables biometrics to be complemented with a secret code either for reasons of security or for reasons of convenience when no registered device is in the neighborhood. Please refer to The TrustBuilder MFA fundamentals for a detailed description on how to engage the TrustBuilder MFA.
Ensure that your subscription includes the option “Secure Standard Authenticator” and/or “Secure Integrated Authenticator”.
Session management
TrustBuilder decouples session management from the act of authentication. A session can be created as soon as a user is recognized, even without any form of authentication, for example during a chatbot session.
As soon as a user can be identified, a session is started. During the lifetime of a session, the user may be asked to supply an authentication factor, depending on your security policy for a given context. For example, a user may be asked to confirm their presence using the passwordless TrustBuilder TrustBuilder MFA. For signing a transaction at a later stage, the user may be required to add a second authentication factor, such as a pin code. Please refer to User Sessions for a description of session management with TrustBuilder.
Ensure that your subscription includes the option “Secure Basic Authenticator”.
Adaptive Authentication
Adaptive Authentication bridges the gap between user experience and account security by providing a secondary factor for end-users but only prompting them for secondary verification when the primary factor login looks suspicious or unusual. For example, if the user logs in from a new device or logs in from previously unseen geolocation, these signals can indicate low confidence that a login attempt is legitimate and that the user should be prompted to authenticate via the second factor.
By only prompting for second-factor authentication when confidence is low, users who access applications on a regular basis from the same device and location never have to be interrupted with a second-factor prompt. Factors taken into consideration include location context, device fingerprint, network context, prior session context, third party risk scoring. Please refer to Adaptive Authentication for a description of Adaptive Authentication with TrustBuilder.
Ensure that your subscription includes the option “Secure Basic Authenticator”.
Zero-Trust Architecture
TrustBuilder supports a zero-trust architecture (“ZTA”, see Glossary) that is no longer counting on security at infrastructure level and the user context is not trusted by default. A zero-trust security architecture applies adaptive authentication with user identification.
Adaptive authentication starts from the premise that a person may work in different circumstances and may represent different levels of risk and thus needs to present different levels of assurance. Additional assurance can, for example, be given in the form of a device certificate, an additional authentication factor, periodic re-authentication, etc.
TrustBuilder allows you to assess risk of user access at any point in time, taking into consideration infrastructural elements such as location, type of device, geolocation in addition to type of authentication, type of persona and type of access. This way, you can distinguish between a an employee accessing your application from the intranet using a company-PC, and a supplier using their own mobile device from the web.
TrustBuilder also allows you to adapt authentication requirements to the type of access the user needs. For example, your policy may indicate that “changing the inventory in an ERP” always requires multi-factor authentication even when being on-prem, and that doing this from the web requires a company authorized device to be used.
Ensure that your subscription includes the option “Secure Basic Authenticator”.
Step up Authentication
Sessions in TrustBuilder have a lifecycle. As such, a user may start a session using an authentication mechanism of their choice, say Facebook. During their session, a policy decision may require the user to provide more assurance by adding passwordless authentication. TrustBuilder thus considers Step-up Authentication as just a specific form of Adaptive Authentication. Please refer to User Sessions for a description of Step-up Authentication with TrustBuilder.
Ensure that your subscription includes the option “Secure Basic Authenticator”.
Multifactor Authentication
Sessions in TrustBuilder enable more than one authentication factor to be recorded in a session. TrustBuilder thus considers Multi-Factor Authentication (“MFA”) as just a specific form of Adaptive Authentication.
Please refer to Defining Security Policies to understand more about “obligations” (such as additional authentication factors) that may be returned to the client app.
Ensure that your subscription includes the option “Secure Basic Authenticator”, “Secure Standard Authenticator” and/or “Secure Integrated Authenticator”.
Persona Switching
With its identity model based on the ‘persona’ concept, TrustBuilder enables authentication policies to depend on a user’s persona type. Co-workers working on-site may be subject to different authentication rules than suppliers and dealers.
Users with more than one persona can be asked to switch to a different persona when needed for specific access. This persona switching happens without a new login.
For example, a person can both be a retail customer and be mandated for administrative tasks on behalf of her company. With TrustBuilder, the person only needs one profile and receives two ‘personas’ in their user profile corresponding to the two roles they can play. During a session, a user can select the persona needed for a certain task and will be granted access correspondingly, subject to a policy decision. The user does not need to logout and login again: if the user is sufficiently authenticated (as determined by the policy decision) she can simply switch personas during a valid session.
With TrustBuilder, you can also implement IGA-Lite (see Glossary) that supports privilege elevation. Using the persona concept, people may receive a specific persona that allows them to execute highly privileged tasks, or tasks that would normally conflict with their day-to-day tasks. Switching to this persona gives the user additional permissions for a period during which the user cannot use his day-to-day permissions.
Please refer to Defining Security Policies to understand more about “obligations” (such as persona switching) that may be returned to the client app.
Ensure that your subscription includes the option “Persona”.
A catalog of authentication factors
TrustBuilder offers its own TrustBuilder Authenticator for passwordless and multi-factor authentication that can work as a stand alone mobile app or through integration into an existing browser app or mobile app.
TrustBuilder also supports external authentication factors including:
SMS loop-back, e-mail loop-back,
direct integration with OneSpan, Gemalto/Thales,
OATH compliant factors (e.g. Microsoft and Google authenticator)
RADIUS compliant factors (e.g. RSA, HID, OneSpan, Gemalto).
Ensure that your subscription includes the option “Secure Basic Authenticator,” “Third party Authenticator” and/or “Notification Service”.
4. Authorization Management
Access Authorization is the process of on-the-fly denying or permitting a user (or a ‘thing’ or an API call) to do something in your digital domain. TrustBuilder is unique because it offers policy-based authorization that combines provisioning rules, authentication rules and persona-driven access rules.
Policy-based Authorization
TrustBuilder offers Policy Based Access Control (“PBAC”), which combines Attribute-Based Access Control (“ABAC,” see Glossary) with Role-Based Access Control (“RBAC,” see Glossary).
RBAC needs application-specific roles to be defined and assigned and thus takes an application-centric approach. ABAC takes attributes of the user, the target application and the context into account. As such, ABAC tends to be more user-centric.
To enable access-relevant attributes to be administered at scale, TrustBuilder introduces the concept of ‘persona.’ By making the security policies explicit and formulating them in terms of user-centric personas, TrustBuilder enables fine-grained authorization to become effective in practice. In fact, it combines persona-driven provisioning of roles of RBAC with persona-driven ABAC with authentication and authorization policies that are evaluated in real-time and in context.
TrustBuilder thus offers a unique Policy-Based Access Control model that is manageable at scale and is auditable at all levels. Please refer to Defining Policies & Rules for a description of the declarative policy model of TrustBuilder.
Ensure that your subscription includes the option “Single Sign-on”.
Dynamic Authorization
TrustBuilder supports different methods to obtain an authorization decision:
Either by adopting XACML3 as protocol: before accessing a system, application, platform or other resource, an authorization decision can be requested through an API call.
Or by adopting OAuth2 as protocol: an authorization decision can be obtained by requesting an advanced access token through the OAuth2 protocol.
With its identity model based on the ‘persona’ concept, TrustBuilder enables authorization policies to depend on the persona type. For example, acting with an ‘co-worker’ persona will authorize the person for more types of actions than a user with the ‘supplier’ persona. As such, the persona concept allows you to segment its policy setting in a natural and auditable way.
Please refer to Dynamic Authorization for a description of Dynamic Authorization with TrustBuilder.
Ensure that your subscription includes the option “API Security”.
API Authorization
In addition to authorization decisions taken on the spot for a user, TrustBuilder also allows this to be applied to machine-to-machine calls from an IoT device or from an application calling another.
Please refer to Dynamic Authorization for a description of API Security with TrustBuilder.
Ensure that your subscription includes the option “API Security”.
Application Authorization
TrustBuilder offers a Service Catalogue, with connectors to a wide variety of off-the-shelf applications and platforms, so called Service Providers.
Please refer to Connecting Service Providers for a description on how to connect and secure your own Service Providers with TrustBuilder.
Ensure that your subscription includes the option “Customer Applications” and/or “Workforce Applications”.
Ecosystem Authorization
Using Token exchange, TrustBuilder provides direct support for digital ecosystems. Using your digital ecosystem, you can extend your service portfolio with digital services from partners. With TrustBuilder, you can offer your customers a seamless experience across your own services and those of your partners from a security viewpoint. No need to re-login, no need to re-register.
Ensure that your subscription includes the option “API Security”.
Symbiosis between ABAC and RBAC
The TrustBuilder Policy-based Access Control model basically externalizes authorization decisions. Because these decisions are taken in real-time, this model implements Dynamic Authorization.
Many enterprise applications, however, are not ready for Dynamic Authorization and are controlling access using application-level permissions that are statically assigned. Permissions may be grouped into roles or groups. For example SAP has roles and composite roles for transaction-level authorization. Also Salesforce uses roles to specify the levels of access of a user. Microsoft applications use Activate Directory groups. So, how does RBAC relate to the TrustBuilder PDAC model?
Permissions, roles and groups are preassigned access rights. So, a system administration will preassign these and hope they are sufficient to let the user do their job, and hope they are not giving too much access. To counter the first issue, users will complain very soon when they cannot do something. To counter the second issue, the system administration cannot count on the user: who’d complain about too much access? Moreover, because users change jobs, teams and function, the continuous correct adjustment of the permissions, roles and groups becomes a challenge. Certainly at scale. So, periodic attestation by local management is often used as a compensating measure.
To address the challenges of continuous re-adjustments, TrustBuilder offers a model that does no longer need pre-assigned roles and permissions. In fact, its PDAC model takes a number of user and session attributes into account as well as takes an enterprise and application perspective.
The TrustBuilder PDAC model shares many characteristics with ABAC (Attribute-Based Access Control). ABAC is typically user-oriented and mostly considers user-related attributes. Conversely, RBAC is application-oriented and associates application features with permissions and roles. TrustBuilder PDAC combines the best of both.
It allows the customer to configure application-specific policies as well as configure the type of metadata to be passed on or provisioned to the application. For example, you can configure TrustBuilder to include the application-specific user account or the user roles in the access token so that RBAC by the application is enabled. Additionally, you can design policies to use the pre-assigned roles and simulate RBAC.
Moreover, you can adopt policies to provision entitlements (in the form of roles, permissions, groups, licenses, privileges) to service providers so the latter can do its own RBAC.
So, in addition to the authentication-driven coarse-grained access control, TrustBuilder also offers semi-fine-grained access control in front of the RBAC of the application.
Ensure that your subscription includes the option “Single Sign-on”.