Access orchestrator for smooth operation
Orchestration is at the heart of any Identity and Access Management (IAM) system. All requests for access to applications or resources pass through the orchestrator. This allows us to provide a seamless user experience as far as identity, authentication and access control is concerned.
Why use TrustBuilder for orchestration?
The way orchestration is handled in TrustBuilder Server is one of the many strong points of our IAM solution.
TrustBuilder was conceived to work together with a vast array of Identity Providers and Service Providers. This openness and the large number of built-in connections in TrustBuilder make orchestration easy.
Policies are a key ingredient for the orchestration between different servers. TrustBuilder offers a Workflow Engine featuring a Workflow Editor. This Workflow Editor provides a graphical visualization of the onboard authentication policy.
Besides supporting numerous open standards which allow of different authentication mechanisms, TrustBuilder connects to the security vendors when their authentication mechanism is required. The decoupling of authentication/federation ‘connectivity’ allows us to concentrate the effort into the actual setup and enforcement of the IAM.
Orchestration as the air traffic control tower of IAM
In an IAM system, the orchestrator performs the function of an air tower in traffic control. Just as planes request permission to take off or land, users request permission to access a resource or an application.
Before a user gets access to the system, he has to provide information on himself to the system. This happens in the onboarding flow. Administrators set up this onboarding flow using the graphical user interface of TrustBuilder’s Workflow Engine. What steps the onboarding flow contains, differs from one organization to another. Sometimes an email address will be verified, or a contract checked. All these small actions are orchestrated in the TrustBuilder Server.
The orchestrator will check information from different sources to verify whether the request can be granted. Depending on the policies that are set, the orchestrator will consult with different servers before the user is allowed granted access. A policy can, for instance, demand that an AD or LDAP server provides a username/password combination, and that a captcha server then verifies that the user is not a robot. To access a resource of a more sensitive nature, extra authentication methods may be called upon.
Once a user is recognized by the system, the user can make changes to some of the information the system holds and that are part of the lifecycle of the journey with a company. For instance, a user can change a telephone number, request a new password,… In this way a user can manage his own identity through self-management.
Orchestration handles access requests
The orchestrator in TrustBuilder picks up all requests, analyzes them and forwards them to the targeted services. The orchestrator mainly deals with two types of requests.
Requests from TrustBuilder Gateway
When TrustBuilder Gateway gets a request from a user, it doesn’t know whether the user has the privileges to access the application or API they are requesting. This decision will be passed on to the orchestrator. Depending on the case, this will trigger the orchestrator to activate an authentication flow and/or return and an authorization decision to the gateway.
Federated authentication requests
This type of request occurs when TrustBuilder is involved in a federation scenario dealing with an identity or service provider. This could be a SAML or OIDC authentication request, or any other open standard request. In this case, the orchestrator will activate our own internal federation server, which will proxy the federation requests to the correct identity or service provider.