Config.xml Structure

Config.xml Structure

Order of Configuration Elements

The order of the configuration elements is important as they are matched to an XSD schema for validation. If the order is incorrect then the application will not start. This is the order that the elements must follow:


The following attributes are available on teh config.xml as extensions.

  • version : version in which the workflow was created (Optional)
  • logging : enable extensive logging, logs input/output for specific adapters as well as for workflows
  • statistics : gather statistics on number of requests, time it took for specific nodes adapter
  • jmx : expose administrator functionality via jmx
  • audit : keep track of all steps that are being traversed


The license key is checked when the configuration is initially loaded if this is not correct then the configuration will fail and TrustBuilder will not be available. The license limits the number of connectors that can be used.

config.xml configuration

 <!-- Paste your license here -->


This determines what process will be followed within TrustBuilder.

TrustBuilder will not start if the configuration fails against the XSD schema when this element does not exist. This file can be created by TrustBuilder Administration GUI. And must be referenced in the config.xml file later in this section. Or you can create the file manually on the filesystem in the shared library or the systems classpath and import it in the TrustBuilder Administration GUI.

Command Line Interface

touch /opt/securit/trustbuilder/workflow.xml

From version 7.1 its possible to assign workflows to specific endpoints. This way you can set a workflow to be only available to one endpoint which.

Instead of scripting you can set : scripting ( Default ) radius ( Radius endpoint only) ldap ( Ldap Endpoint) ocsp ( OCSP Endpoint )

This is set in the stb:type field. Example :

<stb:Workflow stb:id="RadiusVPNflow" stb:type="radius">/workflow_vpnradius.xml</stb:Workflow>
Scripting example

config.xml configuration

<stb:Workflow stb:id="Validationflow" stb:type="scripting">/workflow_validation.xml</stb:Workflow>

When working with subworkflows, multiple workflow elements are declared. config.xml configuration

<stb:Workflow stb:id="Validationflow" stb:type="scripting">/workflow_validation.xml</stb:Workflow>
<stb:Workflow stb:id="StoreFirstflow" stb:type="scripting">/store_first.xml</stb:Workflow>
<stb:Workflow stb:id="OcspFirstflow" stb:type="scripting">/ocsp_first.xml</stb:Workflow>
Xsl example


The XSL validation and scripting is deprecated and will be removed in future versions of TrustBuilder. We recommend you don't use this way of programming your workflows however its still available.

The Validate tag enables validation of the XML request. The RequestTransformer tag specifies the XSL file that is to be used to process the incoming request. The Connector tag determines which XSL file will process the response and also which Adapter tag (connector) is to be used. config.xml configuration

<stb:Workflow stb:type="xslt" stb:id="workflow">
 <stb:RequestTransformer stb:id="req2http">req2http.xsl</stb:RequestTransformer>
 <stb:Connector stb:id="HttpTestConnector">
  <stb:ResponseTransformer stb:id="http2rsp">http2rsp.xsl</stb:ResponseTransformer>

A number of Connector elements can be used within the Workflow element to daisy-chain requests and responses thus: config.xml configuration

<stb:Workflow stb:type="xslt" stb:id="workflow">
 <stb:RequestTransformer stb:id="req2http">req2http.xsl</stb:RequestTransformer>
 <stb:Connector stb:id="HttpAuthAdminConnector">
  <stb:ResponseTransformer stb:id="http2Arsp">http2Arsp.xsl</stb:ResponseTransformer>
  <stb:ResponseTransformer stb:id="httpS2Arsp">httpS2Arsp.xsl</stb:ResponseTransformer>

 <stb:Connector stb:id="HttpAuthConnector">
  <stb:ResponseTransformer stb:id="http2AUrsp">http2AUrsp.xsl</stb:ResponseTransformer>
  <stb:ResponseTransformer stb:id="httpSA2rsp">httpSA2rsp.xsl</stb:ResponseTransformer>


The Adapter tags define the connection to the module that communication will be sent to (xsl), the end point of the process. Below is illustrated a sample adapter element, an HTTP adapter, which makes an http connection to a servlet, as an example. Each adapter has its own specific configuration. Please refer to the Adapters section in this documentation for more details for every adapter. config.xml configuration

<stb:Adapter xsi:type="stb:HttpAdapter" stb:id="HttpTest">
 <stb:Server stb:name="TestServer" stb:priority="1">
  <stb:Transport stb:protocol="1.1">

  • parseHeaders : Should headers be parsed or not
  • maxRequestSize : Limits the maximum size of the request
  • contextFormat : Format to use as context id
    • {no} -> Sequential number
    • {ip} -> Remote Ip address
    • {principal} -> Principal name
  • sessionService : Underlying session service to use for storing session information
  • disposalFlow : Flow to call when a session expired
  • passUrlsAsIs : Do not parse urls to retrieve config/workflow, but pass them entirely
  • ocspResponderKeystoreType : See configuration ocsp workflow
  • ocspResponderKeystorePassword : See configuration ocsp workflow
  • ocspResponderKeystoreFile : See configuration ocsp workflow
  • ocspResponderKeystoreAlias : See configuration ocsp workflow
  • ocspResponderKeystoreAliasPassword : See configuration ocsp workflow
  • forceEncoding : Force encoding on outgoing response
  • krb5Conf : krb5 config (see endpoint configuration)
  • krb5LoginConf : login config (see endpoint configuration)
  • krb5Module : module to use (see endpoint configuration)
  • krb5ClientModule : see endpoint configuration
  • krb5AllowBasic : if basic auth is permitted
Was this article helpful?
0 out of 0 found this helpful



Please sign in to leave a comment.