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\com.nextlevel.fastlane.security.server-[VERSION].jar

[B2B Home]\webapps\b2bbp-engine\WEB-INF\lib\com.nextlevel.fastlane.security.server.client-[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:

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.

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.

Configure runtime to use Security Server

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

Inbound

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 com.nextlevel.b2b.securityserver.services.CryptoMailService

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

Outbound

To integrate the Security Server in outbound processes, you need to change your Mail Sender Service to class com.nextlevel.b2b.securityserver.services.CryptoMailSenderService

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

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):

registered.classes=org.b2bbp.channels.extension.BGMStoreChanneldistribution;\
org.b2bbp.channels.extension.CryptoServerChanneldistribution;\
...

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

org.b2bbp.channels.extension.CryptoServerChanneldistribution.registeredServiceIds=*
org.b2bbp.channels.extension.CryptoServerChanneldistribution.executeOnChannelId=INBOUND_CHANNEL_ERROR;CRYPTO_ERROR_CHANNEL
org.b2bbp.channels.extension.CryptoServerChanneldistribution.skipChannelDistributionOnChannelId=CRYPTO_ERROR_CHANNEL

Configure CRYPTO_ERROR_CHANNEL

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: org.b2bbp.services.inbound.mail.SecurityGateWayCheckAction

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:

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

&SkipCryptoCheck=601;602
&Properties.601=B3P_SKIP_CHANNEL_DISTRIBUTION,B3P_SKIP_FORMAT_RECOGNITION,B3P_BASE_CHANNEL_ID,B3P_SKIPABLE

&Property.601.B3P_SKIP_CHANNEL_DISTRIBUTION=$NULL
&Property.601.B3P_SKIP_FORMAT_RECOGNITION=$NULL
&Property.601.B3P_BASE_CHANNEL_ID=$DB
&Property.601.B3P_SKIPABLE=false

&Properties.602=B3P_SKIP_CHANNEL_DISTRIBUTION,B3P_SKIP_FORMAT_RECOGNITION,B3P_BASE_CHANNEL_ID,B3P_MAIL_SEC,B3P_SKIPABLE
&Property.602.B3P_SKIP_CHANNEL_DISTRIBUTION=$NULL
&Property.602.B3P_SKIP_FORMAT_RECOGNITION=$NULL
&Property.602.B3P_BASE_CHANNEL_ID=$DB
&Property.602.B3P_MAIL_SEC=AUTOMATIC-OMIT-ERRORS
&Property.602.B3P_SKIPABLE=false

&Properties.888=B3P_SKIP_CHANNEL_DISTRIBUTION,B3P_SKIP_FORMAT_RECOGNITION,B3P_BASE_CHANNEL_ID
&Property.888.B3P_SKIP_CHANNEL_DISTRIBUTION=true
&Property.888.B3P_SKIP_FORMAT_RECOGNITION=true
&Property.888.B3P_BASE_CHANNEL_ID=CRYPTO_ERROR_CHANNEL

CrlDownloadScheduler

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_SCHEDULER_REGISTER_CLASSNAME = com.nextlevel.b2b.securityserver.services.scheduler.CrlDownloadScheduler
• B3P_SCHEDULER_TYPE = CRON
• B3P_CRON_HOURS = 03
• B3P_CRON_MINUTES = 00
• 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:

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:

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).

Arbeitsvorräte

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.

Keycloak

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
enable-keycloak=true

# Keycloak Realm*
realm=NLI

# Keycloak URL*
auth-server-url=https://colen-keycloak.de

# specified in Keycloak*
client-id=b2b

# specified in Keycloak*
client-secret=ddaaf0d0-2d3f-4c70-a61c-a93ea4ac50b6

# Whitespace separated list of additional claimed OAuth scopes
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.

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