Client Application Connectivity and Security
There are two types of client applications that connect to the PubSub+ Cloud. The first type of client applications utilize the messaging infrastructure of the event broker services and the second type are client applications that perform management of event broker services (creation and configuration).
For information about client applications for messaging or applications for management of event broker services, see Client Applications for Messaging and Client Applications for Management, respectively.
Client applications connect to the event broker services to publish and subscribe to the messaging and events. To connect, client applications must authenticate and be authorized for each event broker service.
Client applications connect to event broker service via a hostname using a protocol and port with Solace 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 Certificate Authority.
OAuth Provider Authentication is also available but is currently limited to MQTT clients.
For more information about:
- connectivity models for messaging clients, see Connectivity Models for Messaging Client Applications
- connecting to hostnames, see Client Application Connections Using a Hostname
- connecting using APIs and protocols, see Client Applications and Using Messaging APIs
The connectivity of a deployment 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 connect to PubSub+ Cloud via VPN. Messaging clients in the customer's cloud networks connect via network peering. Certain messaging applications may also be given access to PubSub+ Cloud via the public Internet.
For more information, see the PubSub+ Cloud Deployment Connectivity Models.
Client applications connect to event broker services via a hostname and port. The hostname for an event broker service is a unique, generated hostname.
For more information about accessing event broker services, see Connectivity Between Event Broker Services and Client Applications.
Client applications use Solace 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 for each are as follows:
- Solace Messaging — Solace client libraries communicate over proprietary Solace Message Format (SMF) protocol over TCP. The client libraries available are:
Solace PubSub+ Messaging API for C
- Solace PubSub+ Messaging API for .NET
- Solace PubSub+ Messaging API for Java
- Solace PubSub+ Messaging API for Java (JCSMP)
- Solace PubSub+ Messaging API for JavaRTO
- 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 Web sockets or HTTP. The client libraries available are:
- Solace PubSub+ Node.js Messaging API
- Solace PubSub+ 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 production usage, Solace 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.
When an event broker service is created, by default, the username of
solace-cloud-clientand 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.
- 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.
Client applications can be created that issue high-level commands to create, manage, update, and edit event broker services in your deployment using the PubSub+ Cloud REST APIs. Alternatively, you can also create applications that use SEMPv2 calls to connect directly to your event brokers.
Using PubSub+ Cloud REST APIs for Management
Applications that connect to PubSub+ Cloud are authenticated and authorized using an API token. API tokens are issued per account. For more information, see API Tokens for Client Applications.
Client applications that issue management commands do not directly connect to event broker services, but instead communicate with Solace Home Cloud through a set of secure, PubSub+ Cloud REST APIs. Operations performed by these REST APIs are high-level operations. These client applications connect from the public Internet to PubSub+ Cloud. For more information about the PubSub+ Cloud REST APIs, see Understanding the PubSub+ Cloud REST API.
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 Solace-controlled dedicated customer regions or customer-controlled private 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.
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 PubSub+ Cloud REST APIs:
- Solace recommends that the minimum permissions be assigned to an API token for accounts that are in production.
- Solace 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:
- Solace 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.