This paragraph provides a high level overview of the architecture and operational aspects of TrustBuilder.
Attention: It is recommended to read this section before diving into the details as it will provide the required background to understand the technical details.
TrustBuilder is a Security Service Platform that aims at extracting security functions from applications and to provide them as reusable infrastructure services. The security services on which TrustBuilder focuses are:
- Authentication Services
- Identification Services
- Validation Services
- Auditing and Reporting
Authentication Services deal with verifying whether the user really is who he or she claims to be. This ranges from simple username/password authentication mechanisms, to knowledge or two-factor based mechanisms like OTP and PKI, up to biometric solutions.
Identification Services are used to collect attributes or assertions from the authenticated user. The most commonly used attribute is a unique ID with which the user is known within an application or application group. A user could,however, have multiple IDs or other attributes like gender, age, email address, physical address, roles, etc. all to be collected from different sources.
Validation Services focus on the validation of transactions issued by identified users or applications. Validation is a business and/or technical process that comes in many shapes and flavors. Transactions could be validated based on the syntactical correctness of their data (e.g. an amount in a bank transfer is a number) or on the digital signature (OTP or X.509) they carry. It could however also be validated using behavior patterns of the user that issued the transaction or it could enforce that the transaction is stored in a non-repudiation store before it can be processed.
Auditing and Reporting services are often forgotten when building applications. They are however the cornerstone of security and availability, being an important source for tracing and analyzing usage patterns and for capacity planning.
In most of these cases application owners, administrators and developers are facing the challenge of introducing and maintaining complex APIs that are associated with these services. TrustBuilder provides a platform that exposes the afore mentioned functions as abstract services that hide the technical details and maintenance burden of the underlying APIs.
The following figure shows how TrustBuilder fits within the IT infrastructure and how it provides its services to the reliant parties such as:
- Web Access Management
- Enterprise Single Sign-On
- Remote Access and VPN
- End-user Applications
These are just a few examples. TrustBuilder can be exposed to any party that can integrate with the exposed endpoints. These endpoints are described below.
The previous picture shows how TrustBuilder sits between the reliant parties and the backend services. On the left hand side it picks up incoming requests from the applications while on the right hand side it sends outgoing requests to backend resources. In between, TrustBuilder orchestrates the routing from incoming to outgoing requests while potentially applying additional data processing.
This summarizes the main functions performed by TrustBuilder. Each of these functions is provided by a TrustBuilder building block. The TrustBuilder building blocks are illustrated by the following figure.
As shown by this figure, the main building blocks of TrustBuilder are:
- TrustBuilder Core
- TrustBuilder Workflow
- Services (previously Enablers)
The Core of TrustBuilder orchestrates the mapping of frontend requests to backend requests. The mapping is controlled by a workflow and is used to convert incoming requests into one or more outgoing requests.
The following two (very) simple examples illustrate what can be achieved by the engine:
Example 1 : Authenticating against LDAP
- Request authenticate using username/password
- Policy BIND using username/password to LDAP with LDAP Connector
- Response OK, NOT OK
Example 2 : Authenticating with a client certificate
- Request authenticate using certificate
- Policy step 1 check revocation status of certificate using local CRL cache/datastore using JDBC Adapter
- Policy step 2 if not in local CRL cache/datastore, execute OCSP call using OCSP Adapter
- Policy step 3 if not revoked, extract DN from certificate using Certificate Adapter
- Response OK, NOK and DN as user ID.
The above are only illustrations of what the engine can do, however a lot more adapters are available.
TrustBuilder endpoints provide a way to interact with TrustBuilder; an interface that can be called from external parties like Web Access Management solutions and end-user applications. One can look at it as the translation bridge between the outside world and a "Request" that the engine can understand. Furthermore does it also provide the following out-of-the-box endpoints, where each endpoint expects a specific payload.
|HTML||Enables the use of TrustBuilder as a web resource host e.g. login, role selection and error pages|
|OCSP||Turns TrustBuilder into an OCSP server that can be used to check the validity of X.509 certificates|
|Generic||Transforms any HTTP request to TrustBuilder engine format|
|XML||Supports XML over HTTP (deprecated: use Generic Endpoint)|
|SOAP||Exposes the services of TrustBuilder as Web Services (deprecated: use Generic Endpoint)|
|LDAP||Exposes bind, unbind and search functionality to TrustBuilder|
|Radius||Exposes Radius authentication to TrustBuilder|
Both XML and SOAP endpoint were made deprecated since the payload of both can be easily seen as a regular http payload and validated in the workflow. Whereas doing it in the endpoint would require complex configuration.
Adapters allow TrustBuilder to communicate with backend resources like directory servers, database servers and application servers. Technology specific API's are embedded.
New adapters are released on a regularly basis and will be made available as service packs or new product versions.
TrustBuilder comes out-of-the-box with a wide range of adapters:
|AD||This Adapter can be used to authenticate a user against Active Directory. It uses the LDAP interface of AD thus sharing all the functionality available to the LDAP adapter.|
|Certificate||Takes any binary formatted X.509 certificate and exposes its attributes to the script engine.
This makes it straightforward to extract any certificate attribute and use it (e.g.) to map the certificate onto a known user ID or to lookup the user in a directory server or database.
|Custom||Allows any customer to build his own Adapter around a API, proprietary or standard.|
|Digipass||The Vasco DigiPass Adapter is based on the Vasco VacMan Controller API.
It supports the validation of OTP's generated by any of the Vasco tokens (hard tokens, soft tokens and mobile tokens). It also provides functions to reset and unlock tokens.
The Adapter also supports the storage of the blob data in LDAP or a database.
|Gemalto||A special version of the HTTP/SOAP Adapter that has some extensions to support the Gemalto OTP (One-Time-Password) based authentication and transaction signing solution|
|HTTP||Provides HTTP and HTTPS functionality to TrustBuilder.|
|JDBC||This Adapter allows TrustBuilder to send SQL queries to databases like Oracle, DB2, MySQL, SQL Server.|
|LDAP||Provides access to LDAP based directories. It supports functions like BIND, SEARCH and MODIFY.|
|OAuth||With this adapter TrustBuilder can communicate with any OAUTH authority.|
|OCSP||With this Adapter TrustBuilder can communicate with any OCSP based certificate validation server.|
|Push||This adapter allows TrustBuilder to send push notifications to a mobile device|
|RACF||The RACF Username/Password Adapter deals with username/password authentication and password change against a RACF system. It uses the LDAP interface of RACF|
|Radius||Handles authentication requests using the RADIUS protocol with any RADIUS compliant server.|
|OATH||One time password generation and validation. This is an OTP generator that can be used in combination with a sms gateway to provide 2-factor authentication.|
|SAML||Can be used to generate and/or validate/parse SAML tokens.|
|SMTP||With this adapter Trustbuilder can communicate with any SMTP server to send mails.|
|STS||This Adapter provides the WS-Trust protocol to talk to Secure Token Service solutions to map between token formats. The adapter is based on the HTTP Adapter.|
|ISAM||The IBM Security Access Manager (ISAM) Adapter includes most of the ISAM API functionality.
It can be used to make authentication, authorization and administration requests against an ISAM environment.
A TrustBuilder workflow describes the logic on how to process an incoming request.
The major tasks of a workflow:
- describes the logic between the configured backend adapters (LDAP, HTTP, JDBC...)
- preparation of calls required by the backend adapters to fulfill their task
- interpreting the responses received from the backend adapters
- preparation of a response that is returned to the calling endpoint
A service is a collection of useful functionality which can be referenced from a workflow.
The following services are present in TrustBuilder:
- Crypto Services
- Login policy service (e.g. lock after 3 bad authentication attempts)
- Password policy service (e.g. restriction on password characters or length)
- Session service
- Audit service
Adapter elements and workflow references defined in a configuration can be overridden by properties defined in a separate properties file. This allows for different environments to use the same configurations with environment sensitive settings overridden for each specific server.
For instance if there are two environments dev and test. They both used a JDBC adapter but the datasource names are different in each environment.
The datasource element of the JDBC adapter can be overridden so each environment references the correctly named datasource yet the same configuration and the same adapter are used in both.
For more details refer to adapter and workflow chapters.
The TrustBuilder Administrator (TBA) is the partner product to the TrustBuilder core engine. TBA enables simple configuration of service adapters, workflows, API scripts and authorisation policies without any prior knowledge of the TrustBuilder architecture or configuration.
The tool also provides facilities to manage different TrustBuilder instances allowing the user to export files and restart their core engines' to instantly load changes.
TBA is not required but is the recommended way to configure TrustBuilder core due to tailored in-line documentation, validation and graphical representation of workflows.
A working configuration can be exported via a zip file which can then be distributed to production systems.
Workflows can be created using an intuitive drag and drop interface which includes built in validation. This enables the creation of a self documenting security solution that can be deployed within a very short time frame.
Creation of service adapters; database connections, LDAP, HTTP services etc, are made using the in-line documented and self validating forms.
- Drag and drop creation of workflows
- Create adapters with in-line documentation
- Services such as database connection, LDAP, HTTP, Digipass
- Export to and restart TrustBuilder instances
- Manage Authorization policies
- Import files from TrustBuilder instance.
- Manage multiple local or remote TrustBuilder instances.
- Fully featured API script, template and property editors for creation and editing of workflow/policy scripts
- Code completion
- Inline documentation
- Syntax highlighting
- Matching occurrences
- Validation of workflows and adapters on saving.
- Test workflows against the engine before exporting
- Create services that expose Java functionality to the API scripts
- Update license and other configuration details