TrustBuilder ID Hub Architecture

A complete IAM solution

TrustBuilder ID Hub contains all the components you’d expect in an Identity and Access Management (IAM) system. On top of that, we deliver extra elements, such as (i) the workflow engine and (ii) an outstanding integration feature set, including built-in adapters to connect to your back-ends, as well as (iii) support for standard and commercial Identity Providers (IdPs) and Service Providers (SPs), that make life much easier for anyone involved in implementing airtight security while offering the best experience possible to customers.

 

The authentication and authorization flow

Before we explore the components of TrustBuilder ID Hub, let’s look at a typical authentication flow. Users are not supposed to notice it, but before they gain access to a resource or a service in a network, a lot of elements come into play. First, they need to be identified and authenticated. Authentication is all about verifying that a user is who he claims to be. This is the identification part. This could be as simple as checking a username/password combination or as complex as validating a biometric characteristic of the user. Secondly, they need to be authorized. Authorization deals with validating whether an authenticated user is allowed access to the application or service he’s requesting. In other words, even when you are who you claim to be, you may still not have the right to access an application or a service.

Authentication and Authorization process

While the entire authorization flow is invisible to the user (it is only visible when the access is not authorized, or when the user is asked to (re-)authenticate), a number of entities will get involved in the authorization flow:

  • Policy Enforcement Point (PEP): Point which request a decision to the PDP to obtain the authorization decision about a given resource and enforce the PDP decision.
  • Policy Decision Point (PDP): Point which evaluates the access requests against authorization policies before issuing positive or negative access decisions.
  • Policy Administration Point (PAP): Point which manages access authorization policies.
  • Policy Information Point (PIP): The system entity that acts as an extra source of attribute values (i.e. a resource, subject, environment).
  • Policy Retrieval Point (PRP): Point where the access authorization policies are stored, typically a database or a file system.

Three main components in TrustBuilder ID Hub

TrustBuilder ID Hub consists of three main components:
TrustBuilder Gateway, TrustBuilder Server and TrustBuilder Repository.

TrustBuilder Gateway

This component in our architecture acts as Policy Enforcement Point for all HTTP(s) traffic. TrustBuilder Gateway is the barrier between your internal systems and the outside world. The Gateway inspect all web traffic, verifies all sessions and passes them on to the TrustBuilder Server. TrustBuilder Gateway can be used for web traffic, but also for Mobile/API traffic.

TrustBuilder Server

This core component acts as both the Policy Decision Point and the Policy Administration Point. TrustBuilder Server takes care of orchestration, authentication, federation, authorization, self-service administration, logging and auditing, adapters and services and the workflow engine. These functionalities are configured with a Graphical User Interface (GUI) by the administrator of TrustBuilder Identity Hub.

TrustBuilder Repository

This third component in our architecture acts as internal Policy Information Point and Policy Retrieval point. The TrustBuilder Repository contains all information that is required to run TrustBuilder ID Hub. It can hold end-user information itself (though this is not mandatory) and stores information related to both internal and external protected applications and service providers, as well as information about registered internal and external authentication services (identity providers).

In a development and test environment, all three components can be deployed on a single server. For production systems, it is recommended to put TrustBuilder Gateway in the DMZ, while TrustBuilder Server and TrustBuilder Repository are placed in the internal network.

TrustBuilder architecture scheme

TrustBuilder ID Hub brings unique architectural features

TrustBuilder ID Hub differs from other IAM solutions in a number of ways.

Attribute-based access control

TrustBuilder ID Hub uses the model of Attribute-based Access Control (ABAC), which offers a much more fine-grained approach than the traditional Role-Based Access Control (RBAC) model. TrustBuilder ID Hub combines the openness for organizations to create their own attributes, allowing them to customize security to their own purposes, and address B2C which does not fit the traditional RBAC model.

Choice of authentication mechanisms

TrustBuilder Identity Hub provides several standard authentication mechanisms out of the box. TrustBuilder is, in this sense, a vendor-agnostic brokering platform. TrustBuilder is flexible, using either its own authentication mechanisms or adapting to the customer’s preferred authentication mechanism, including bespoke ones.

No need for user synchronization

TrustBuilder Repository works with a virtual directory technology. TrustBuilder Identity Hub can retrieve “on-the-fly” user identification information from an existing internal or external source and use this information for any authentication decision. This avoids the need and the trouble that come with user synchronization between user repositories/databases.

Design your custom flows

TrustBuilder offers ultimate flexibility to its customers by allowing them to design flows themselves and decide on the conditions for these flows. For each application the customer wants to authorize, separate flows can be designed, without needing developer coding skills.

Secure both users and APIs

TrustBuilder has a unique approach to API security. Where API management tools only secure APIs at the edge, TrustBuilder also takes care of security between APIs. This way, one solution secures both web users and APIs in one single system, further enhancing security of your customer-facing applications (web and mobile).

Easy policy management through Workflow Engine

Implementing an IAM solution is one thing, maintaining it and adapting the system to changing market conditions is quite another. That’s why TrustBuilder equips TrustBuilder Identity Hub with a Workflow Engine and a graphical Workflow Editor. The entire process of implementing a new authentication/enrolment policy can easily be controlled by the customer. The workflow engine can be hooked up into the authentication flow, but also to customize standard built-in mechanisms such as logging, and fetch information from customized/bespoke repositories.

  • TrustBuilder Workflow Editor does not require coding, even though data manipulation may require some scripting.

  • TrustBuilder Workflow Engine provides a graphical visualization of the IAM policy. As the visualization takes away the need for expert knowledge, its logic can easily be understood by all kinds of business and security teams. 

TrustBuilder access flow editor

Easy integration thanks to built-in connections

From its inception, TrustBuilder ID Hub was conceived as an open system that can easily be connected to and interact with external repositories, third-party authentication technologies and federate with external vendor solutions. TrustBuilder Server contains adapters, i.e. functional building blocks, that implement either a standard protocol or an API from other security vendors.  

In the TrustBuilder Suite, TrustBuilder ID Hub is complemented by TrustBuilder.io. TrustBuilder.io offers a catalog of services, connecting to a variety of Identity Providers (IdPs) and authentication mechanisms and providing easy integration with additional applications and service providers (SPs). TrustBuilder.io is available as a cloud-based managed service. TrustBuilder constantly adds new IdPs and SPs, thus allowing easy and fast integration and a shorter time to market.