Client Application Connectivity and Security

Two types of client applications connect to advanced event mesh for SAP Integration Suite:

Diagram of the Cloud architecture that shows the data paths to applications as described in the following text.

Client Applications for Messaging

Client applications connect to event broker services to publish and subscribe to messaging and events. To connect, client applications must authenticate and be authorized for each event broker service.

Client applications connect to event broker services using a hostname with a protocol and port, and SAP client APIs or Open APIs. Depending on the connectivity model, you may need to consider which APIs and protocols to use with your event broker services. The APIs do not provide a mechanism for client applications to access the host or instances; only the messaging functionality of the event broker service is available. There is no direct access to the compute instances on deployments for client applications.

To access event broker services, client applications must be authenticated. The default authentication scheme uses basic authentication. An event broker service can be configured to use multiple authentication schemes. The authentication mechanism for an event broker service can be as basic as an internal database configured with generated usernames and passwords (basic authentication), or a more robust mechanism using LDAP, Kerberos, Client Certificates, or a Certificate Authority.

Connectivity Models for Messaging Client Applications

Messaging Connectivity refers to the way messaging clients access the event broker services. A messaging client can connect in three ways: via the public internet, via private IP addresses, or via a hybrid of both.

  • Public Internet: Messaging clients connect to the event broker service endpoints over the public internet.
  • Private IP Addresses: Messaging clients connect to the event broker service endpoints via private routes inside the customer's network.
  • Hybrid: Messaging clients in internal networks and in the customer's cloud networks connect via network peering.

For more information, see the Connectivity Requirements.

Protocol and Port Access for Client Application Connections to Event Broker Services

Client applications connect to event broker services via a hostname and port. The hostname for an event broker service is a unique, generated hostname. Alternatively, you can configure a custom hostname. For more information, see Configuring Custom Hostnames for an Event Broker Service.

For clients to access event broker services, the ports must be open on the network where the deployment is and enabled on the event broker service. For more information, see Changing the Port Configuration for Event Broker Services.

After client applications connect to an event broker service using the available protocol and port, they must authenticate and be authorized to use the event broker service for Messaging Connectivity and Management Connectivity. For more information, see Client Applications for Messaging.

Default Port and Protocol Configuration for Messaging Connectivity

The following table lists the protocol ports, indicates whether the port is enabled by default when a event broker service is created, the protocol used for Messaging Connectivity (Data traffic).

Port for Each Protocol Enabled by Default for an Event Broker Service Protocol and Description

443

 Yes

Secured Web Transport TLS/SSL

5671

 Yes

Secured AMQP

8443

 Yes

WebSocket Secured MQTT

8883

 Yes

Secured MQTT TLS/SSL

9443

 Yes

Secured REST TLS / SSL

55443

 Yes

Secured SMF TLS/ SSL (without compression)

80

 No

Web Transport

1883

 No

MQTT (plain-text)

5672

 No

AMQP (plain-text)

8000

 No

MQTT / WebSockets (plain-text)

9000

 No

REST (plain-text)

55003

 No

SMF-compressed

55555

 No

Solace Message Format (SMF) - plaintext

For more information about the default event broker service port configurations, see Load Balancer Rules Per Service (Default Protocols and Port Configuration).

Using Messaging APIs with Client Applications

Client applications use Solace Messaging APIs and open API protocols to publish and subscribe to event broker services. All APIs use a protocol connect to event broker services. The protocols permitted and the access details are configurable for each event broker service. The ability to configure each event broker service gives you fine-grained control to manage what protocols, ports, and APIs can be used to connect to your event broker services.

The supported protocols are as follows:

  • Solace Messaging — Solace client libraries communicate over proprietary Solace Message Format (SMF) protocol over TCP. The client libraries available are:
    • Solace Messaging API for C
    • Solace Messaging API for .NET
    • Solace Messaging API for Java
    • Solace Messaging API for JCSMP
    • Solace Messaging API for Java RTO
    • Spring Boot JMS API
    • Spring Boot Java API
    • Spring Cloud Stream
  • Solace Web Messaging — Solace client libraries communicate over proprietary Solace Message Format (SMF) protocol over WebSockets or HTTP. The client libraries available are:
    • Solace Messaging API for Go
    • Solace Messaging API for Javascript
    • Solace Messaging API for Node.js
    • Solace Messaging API for Python
  • AMQP — Open APIs that use the AMQP protocol.
  • MQTT — Use open APIs that use the MQTT protocol.
  • REST — Use the REST protocol to exchange messages with event broker services.

For more information, see Developing Applications.

Authentication and Authorization for Messaging Clients

For production usage, SAP recommends that client applications connect to the event broker services to access message data using the available authentication and authorization models that pertain to your organization's security requirements.

The following are considerations for the authentication and authorization for messaging clients that you may want to implement as well.

For authentication:

  • When an event broker service is created, by default, the username of solace-cloud-client and a unique password is generated for the supported protocols that were enabled at creation time. These usernames and passwords are stored on an internal database on the event broker service for ease of use and integration for basic authentication for development.

    The usernames and passwords used for each protocol are available on the Status tab in Mission Control for each event broker service for basic authentication. In production environments, we recommend that you use a more robust authentication scheme rather than the basic authentication with an internal database. Specifically, we recommend that client applications connect to the event broker services to access message data using the same security requirements for authentication as your environment.

  • Client applications connect to event broker services using secure, encrypted communication. Like users, applications are authenticated and can use basic authentication, LDAP-based authentication, client certificate authentication, OAuth Provider authentication, and authentication using a certificate from a certificate authority.

    The authentication mechanism is configurable on a per event broker service level, which means that it is possible to have multiple event broker services running on the same deployment (data center) with non-homogenous authentication schemes. For example, you could use LDAP authentication for one service and OAuth for another service. For more information about configuring authentication for an event broker service, see Configuring Authentication to Event Broker Services.

For authorization:

  • After (or in conjunction with) authentication, the client application must be authorized to access the system's data and resources. We recommend that in production that you configure your event broker services to handle different authorization levels that include:
    • ability or authorization connections
    • to consume resources
    • to send and receive data

  • Each event broker service that is created is configured with a client profile called default. The default client profile has common settings that lets you bring up a service quickly and to start using your event broker services quickly. We recommend for production that you minimize the authorizations allowed for default and create and configure client profiles to align with your security requirements.

    Authorization for various features and of subscribed data are performed using client profiles. Different client profiles can be used on the same event broker service to define a set of client behaviors or capabilities to be used by different client applications. For more information, see Using Client Profiles and Client Usernames.

Protocol and Port Client Applications for Management

Client applications can be created that issue high-level commands to create, manage, update, and edit event broker services in your deployment using the advanced event mesh REST APIs. Alternatively, you can also create applications that use SEMPv2 calls to connect directly to your event brokers or CLI commands.

Default Protocol and Port Configuration for Management Connectivity

The following table lists the protocol ports, indicates whether the port is enabled by default when a event broker service is created, the protocol used for Management Connectivity (management traffic).

Port for Each Protocol Enabled by Default for an Event Broker Service Protocol and Description
8080

Yes/No (See note)

SEMP (plain-text)

This port is disabled by default on event broker services created after December 2020.
22 Yes

Secured Shell

943

 Yes

SEMP over TLS

Using REST APIs for Integration and Management

Applications can manage event broker services, users, and perform various configuration and management tasks using REST APIs. Applications that connect to advanced event mesh are authenticated and authorized using an API token. API tokens are issued per account. For more information, see Understanding Authentication When Using the REST API.

Client applications that issue management commands do not connect directly to event broker services, but instead communicate with Home Cloud through a set of secure advanced event mesh REST APIs. Operations performed by these REST APIs are high-level operations. These client applications connect from the public Internet to the Home Cloud. For more information about the advanced event mesh REST APIs, see Understanding the REST API.

SAP reserves the right to adjust the rate limits at any time to ensure a high quality service for all users of our platform. If you are subjected to rate limiting, reduce your request rate. For more information, see API Rate Limiting.

Using SEMP APIs for Management

You can also use also use the Solace Element Management Protocol (SEMP) APIs to configure, monitor, and manage event broker services. Applications that use SEMP authenticate and are authorized in the same manner as client applications for messaging. For more information, see Authentication and Authorization for Messaging Clients.

For deployments to Dedicated Regions (that use only private IP addresses for connectivity) or Customer-Controlled Regions, the client applications must connect directly to the event broker service and therefore must be co-located in the same private region (or private network) to ensure they are secure.

Considerations for Client Applications for Management

These are the considerations for client applications to authenticate and be authorized to manage event broker services for an account.

For client applications that use advanced event mesh REST APIs:

  • SAP recommends that the minimum permissions be assigned to an API token for accounts that are in production.
  • SAP recommends that API tokens be regenerated and reassigned according to the security policies for your organization.
  • The API tokens utilize keys cannot be regenerated. Any storage of that key should be protected using the same security policies followed by your organization.

For client applications that use SEMP APIs:

  • SAP recommends that you configure the client with minimum required permissions to perform the required operations.
  • For event broker services in a private network, use VPC/VNet peering when the client applications reside in a separate region.
  • Consider using more robust authentication and authorization schemes than the default basic authentication.
  • Consider a custom client profile for use with management applications that use SEMP with a minimal set of capabilities.