Integrating the Security Server to B2B by Practice

The following steps are necessary to set up the B2B by to work together with the previously configured Security Server:

  • Check B2B version
  • Configure B2B nodes
  • Activate Security Server user interface
  • Configure Security Server connection

Check B2B version

The B2B by Practice version needs to match the corresponding Security Server version. To check if that is the case, you may compare the versions of the following libs:

[SecurityServer Home]\lib\[VERSION].jar

[B2B Home]\webapps\b2bbp-engine\WEB-INF\lib\[VERSION].jar

After the basic communication between B2B and Security Server is established, the client and server versions are also shown in B2B-Versioninfo view: View B2B version info

If the versions do not match, contact the Next Level Integration support to verify your installation.

Activate the Security Server user interface

To manage certificates and private keys you need to install the SecurityServer UI module into B2B by Practice. You can grant permission to this module using Roles and Role Attributes.

The following Role Attribute enables the SecurityServer UI, it may be administrated to Roles as needed.

Attribute Name Value
Module_SecurityServer Override={view=mainView,type=AddChild,target=toolBarBox,name=org.b2bbp.ui.uicomponent.MainNavLinkButton,value=[id:'SecurityServer';label:'SecurityServer';isExtension:'false';type:'com.nextlevel.b2b.securityserver.ui.swf';provider:'';version:'1.0';container:'applicationViewStack';toolTip:'SecuritySserver Administration';width:'180';labelPlacement:'right';textAlign:'left';horizontalGap:'10';paddingLeft:'5';paddingRight:'5';iconURL:'images/famfamfam-icons/folder_key.png']}

Configure Security Server connection

To enable the connection between B2B by Practice and the Security Server, you need to add some global properties to your configuration.

Global Property Value Description
SEC_GW_ACTIVE true/false If this option is set to true, the connection to Security Server will be established. Otherwise B2B will work without using the Security Server.
SECURITY_SERVER_BASE_URL http://:/fss/api/v1 The base URL where the endpoints of the FSS can be reached. (hostname and port need to be adquately adapted, e.g. localhost as hostname 2222 as port, if the FSS is a local installation running on port 2222)

Configure runtime to use Security Server

You can now start integrating the Security Server into your in- and outbound processes.


The integration for inbound messages is currently only possible for the mail service, as there are only SMIME filters active. You need to change the class of your MailService to

The Security Server analyses the incoming Mimestream for encryption and signature automatically. So, there are no additional configuration steps necessary. Additional, optional service-property:

Service Property Value Override context Description
B3P_CRYPTO_ERROR_CHANNEL Your channel name for erroneous messages yes In this property is configured, in which channel messages with error should be placed. Default channel is CRYPTO_ERROR_CHANNEL


To integrate the Security Server in outbound processes, you need to change your Mail Sender Service to class

Additionally you need to add some properties to your OutboundMail Action classes.

Service Property Value Override context Description
B3P_MAIL_SEC_PROCEDURE procedure1_procedure2_… yes This defines the configuration of the SecurityServer pipeline. The configuration of the pipeline defines the actions that need to be executed.e.g.: sign_encrypt or sign or encrypt or (see B3P_PROCEDURE_EQ_PLAIN). Use “automatic” to let the SecurityServer automatically configure the pipeline depending on existing certificates for that partner
B3P_PROCEDURE_EQ_PLAIN ignore;plain yes This defines templates, which will be ignored by the SecurityServer if the above property is equal to one of these.
B3P_USED_SERVICE_ID <new service with SecurityServer> no If you added a new service, you need to change the configuration here, too!
B3P_MAIL_SEC procedure1_procedure2_… yes if set and filled this setting overrides the setting in B3P_MAIL_SEC_PROCEDURE (may be used in ClearingCodes to send a message without changing ruleset)

Configure CryptoServerChanneldistribution

For a distribution into the CRYPTO_ERROR_CHANNEL (for example in case of a decryption error) the following Channel Distribution needs to be added to the registered classes in the EXT_CHANNEL_DIST extension: org.b2bbp.channels.extension.CryptoServerChanneldistribution

The Channel Distribution should be one of the first entries (EXAMPLE):


The Channel Distribution must also be configured in the configuration part of the extension (beneath the registration part):



All messages (inbound and outbound) which have an error or a warning while processing in the crypto server (e.g. signature not valid) will be routed into the CRYPTO_ERROR_CHANNEL through the ChannelDistribution named above. In order to restart these messages the CRYPTO_ERROR_CHANNEL needs to be configured in the B2B with at least one Action:

As long as this action is configured the messages in the CRYPTO_ERROR_CHANNEL can be restarted and are sent back to the Security Server for processing. If you want to omit the Security Server processing you can declare additional clearing codes in the ClearingCodes extension, see below:

Service Property Value Override context Description
B3P_TARGET_CHANNEL Channel which is configured at your inbound-service no Target-Channel for restart of erroneous messages.

Configure Clearing Codes

For restarting your messages in error-state, you can use the following two ClearingCodes.

601=Restart ohne CRYPTO-Prüfung (INBOUND)
602=Restart ohne CRYPTO-Verarbeitung (OUTBOUND)
888=Restart mit erneuter Crypto-Prüfung






The B2B can download Certificate Revocation Lists (CRLs) every day. Use the SchedulerRegisterService CrlDownloadScheduler.

  • Service class = org.b2bbp.service.inbound.scheduled.SchedulerRegisterService
  • Service type = SCHEDULER

SchedulerRegisterService Properties

  • B3P_CRON_HOURS = 03
  • B3P_SCHEDULER_NAME = Job Crl Download

Due to this sample configuration, the CRLs will be updated every day at 03:00 am.

Further Properties:

  • OLDER_THAN_HOURS = 0 (default) If you enter a number h greater than zero, only certificates which have not been accessed for at least h hours will be updated.
  • SEC_GW_TIMEOUT This service property overrides the standard-timeout from the global property with the same name.

Proxy configuration

CRLs are accessed either via HTTP or LDAP web addresses. Therefore, B2B needs access to the web. If a Proxy is used, configure these Global Properties:

Global Property Value Description
B3P_PROXY_SERVER Port is mandatory.
B3P_PROXY_USER proxy-user Not every proxy needs login information.
B3P_PROXY_PASSWORD **** Encrypted password, using standard B2B password encryption.
B3P_PROXY_NTLM true/false If true, proxy-authentication via NTLM is used.
B3P_PROXY_EXCLUDELIST; Semicolon-separated list of excluded addresses.

Source restrictions

It is possible to filter specific sources during the CRL update process. To exclude LDAP sources from the update process (for example if LDAP is not be accessible by a proxy), you can set a global property or a service parameter:

Global Property Value Description
SEC_CRL_ACCESS_RESTRICTIONS LDAP The CRL accesses via LDAP will not be downloaded

If the property is defined at a service, it will override the global property setting (if set). A set LDAP filter will never update any LDAP URIs. It may be necessary to activate soft validation to be able to see a correct CRL status.

If using this property, we recommend to configure also soft.crl.validation=true on FSS (because we never update the LDAP-distribution-points).


It’s possible to configure some Workbaskets, to see only the messages with warnings or errors whil decrypting or verifying then or to show the automatically restarted messages. If you want to use the CRYPTOAUTO Workbasket, you must follow the rulestore convention:

Use a clearingcode that corresponds to the cryptoerror /-warning. For example CW6.2 becomes clearingcode W62, CE3.0 becomes E30.

Attribute Name Value
Inbox_MSGMON_CRYPTORULE InboxViewDefinition={type=MSGMON,id=MSGMON_CRYPTOAUTO,title=CRYPTO automatisch akzeptierte Fehler/Warnungen,params=[sqlWherePart:'(clearingcode LIKE 'W%' OR clearingcode LIKE 'E%')']}
Inbox_MSGMON_CRYPTOERROR InboxViewDefinition={type=MSGMON,id=MSGMON_CRYPTOERROR,title= CRYPTO Fehler,params=[sqlWherePart:'STATE LIKE 'CE%'']}
Inbox_MSGMON_CRYPTOWARN InboxViewDefinition={type=MSGMON,id=MSGMON_CRYPTOWARN,title= CRYPTO Warnungen,params=[sqlWherePart:'STATE LIKE 'CW%'']}


Protecting FSS Endpoints with Keycloak is highly recommended.

System will load Keycloak properties from JSON file (keycloak.json) and use them to authorize REST Requests outgoing from tomcat, so it must be configured if FSS REST endpoints are protected by Keycloak and OAuth. It’s important that this keycloak file is available in the tomcat’s classpath (e.g. tomcat/lib or tomcat/conf folder). You can export the keycloak.json file from the b2b-tomcat client configuration in your Keycloak administration.

If the JSON file is missing, system will then fallback to use deprecated Extension KEYCLOAK, see below.

For B2B to be able to send messages to FSS, the b2b-tomcat Keycloak client needs to have the role FSS-Message. First, make sure that the Access Type is “confidential” and enable the Service Account in Keycloak administration of the b2b-tomcat client:

then save the changes and assign the Role FSS-Message in the newly appeared tab Service Account Roles:

Extension KEYCLOAK (Deprecated)

(empty provider, empty version)

This extension authorizes REST Requests outgoing from tomcat, so it must be configured if FSS REST endpoints are protected by Keycloak and OAuth.

Extension Content:

# if disabled, outgoing REST requests are not authorized by Keycloak. Possible values: true/false

# Keycloak Realm*

# Keycloak URL*

# specified in Keycloak*

# specified in Keycloak*

# Whitespace separated list of additional claimed OAuth scopes

# * ask your Keycloak Admin

Optional Configurations

Visibility and Accessability of the SecurityServerProtocol

On default the SecurityServerProtocol is displayed as a professional attribute in monitoring. This behaviour is changeable by GlobalProptery SEC_PROTOCOL_ATTRIBUTE_TYPE.

Global Property Value Description
SEC_PROTOCOL_ATTRIBUTE_TYPE PROFESSIONAL_FOR_ARCHIVE default protocol is displayed as professional attribute and can be archived like, e.g. a mime stream, if configured
SEC_PROTOCOL_ATTRIBUTE_TYPE TECHNICAL protocol is displayed as a technical attribute on corresponding service entry

To actually archive the protocol the attribute SECURITY_SERVER_PROTOCOL needs to be added to the list of attributes to be archived. See Archive Job

View Me   Edit Me