Configuring Connection Details

Solace PubSub+ Connection Details

The Spring Cloud Stream Binder for PubSub+ uses Spring Boot Auto-Configuration for the Solace Java API to configure its session. In the application.yml, this typically is configured as follows:

solace:
  java:
    host: tcp://localhost:55555
    msg-vpn: default
    client-username: default
    client-password: default

For more information and options to configure the PubSub+ session, see Spring Boot Auto-Configuration for the Solace Java API.

Preventing Message Loss when Publishing to Topic-to-Queue Mappings

If the connector is publishing to a topic that is subscribed to by a queue, messages may be lost if they are rejected (for example, if queue ingress is shut down).

To prevent message loss, configure the reject-msg-to-sender-on-discard option with the including-when-shutdown flag.

Amazon SQS Connection Details

We assume that you are familiar with the Spring Cloud AWS Credentials. However, the steps that follow help you to connect to AWS services without in-depth knowledge.

In addition to authentication credentials, the AWS client libraries also require setting a property for the AWS cloud region using "spring.cloud.aws.region.xxx" properties. AWS credentials are valid in a context of a region.

There are several options for configuring the connection details:

Automatic Credential Discovery
Access Key and Secret Key
Chained IAM Roles Assumption

Automatic Credential Discovery

By default, the Spring Cloud AWS starter automatically configures a DefaultCredentialsProvider, which looks for AWS credentials in this order:

Java System Properties—aws.accessKeyId and aws.secretAccessKey
Environment Variables—AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
Web Identity Tokens—The credentials from system properties or environment variables
Credential Profiles Files—The default location is at ~/.aws/credentials, which is shared by all AWS SDKs and the AWS CLI.
Amazon EC2 Container Services—The credentials delivered through the Amazon EC2 container service if the AWS_CONTAINER_CREDENTIALS_RELATIVE_URI environment variable is set and security manager has permission to access the variable.
Instance Profile Credentials—These credentials are delivered through the Amazon EC2 metadata service.

Access Key and Secret Key

You can manually specify an AWS Access Key and Secret Key through the application configuration, which uses the Spring Cloud AWS authentication libraries.

You can set the cloud.aws.credentials.xxx as well as cloud.aws.region.xxx in application.yml. For more details about these configuration options, see:

the AWS Credentials section of the Spring Cloud AWS Core documentation
the Regions, Availability Zones, and Local Zones in the Amazon Relational Database Service User Guide

Follow the example below to set the Access Key and Secret Key:

spring:
  cloud:
    aws: # SqsTemplate configuration
      credentials:
        access-key: <aws credentials/access key> #Specifies the access key
        secret-key: <aws credentials/secret key> #Specifies the secret key
    region:
        static: us-east-1 # A static value for region used by auto-configured AWS clients (e.g., eu-west-1) as AWS credentials are valid in a context of a region.
      auto: false

Chained IAM Roles Assumption

Chained IAM role assumption allows connectors to securely access AWS resources across different AWS accounts without requiring direct credential exchange. Chained IAM role assumption works through a trust relationship between AWS accounts:

The resource owner creates an IAM role (solace-mi-workload-role) in their AWS account, and configures it with the specific permissions required.
This role is configured to trust the connector host AWS account's role (single-pod-identity-role).

When a connector needs to access the resource, it uses the trust chain to temporarily assume the necessary permissions, as follows:

[Assume single-pod-identity-role] → [Get credentials to assume solace-mi-workload-role] → 
[Assume solace-mi-workload-role] → [Get credentials to access the target vendor resource] → 
[Access the resource]

To set up chained IAM role assumption for your connector, perform the following steps:

Create a role called single-pod-identity-role in the connector host environment.

If your connector is hosted on an EC2 instance, attach the following trust policy:

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Principal":
        {
          "Service":"ec2.amazonaws.com"
        },
    "Action":[
     "sts:TagSession",
     "sts:AssumeRole"
     ]
    }
  ]
}

If your connector is hosted on EKS pods, attach the following trust policy:

{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Effect":"Allow",
      "Principal":
        {
          "Service":"pods.eks.amazonaws.com"
        },
    "Action":[
     "sts:TagSession",
     "sts:AssumeRole"
     ]
    }
  ]
}

Create an AWS policy called cross-account-solace-policy with the following policy document:

{
  "Version":"2012-10-17",
  "Statement":[{
    "Sid":"AssumeRoleOnThirdPartyAccount",
    "Effect":"Allow",
    "Action":[
     "sts:TagSession",
     "sts:AssumeRole"
     ]
    "Resource":"arn:aws:iam::*:role/solace-mi-workload-role"
  }]
}

Attach this policy to the single-pod-identity-role.

Create a role called solace-mi-workload-role in the resource owner's AWS account and attach the following trust policy:

{
  "Version":"2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Principal":{
      "AWS":"arn:aws:iam::<MI_HOST_AWS_ACCOUNT_ID>:role/single-pod-identity-role"
    },
    "Action":[
     "sts:TagSession",
     "sts:AssumeRole"
     ]
  }]
}

where <MI_HOST_AWS_ACCOUNT_ID> is the ID of the AWS account where the connector is hosted.

Attach the required resource permissions to the solace-mi-workload-role. The minimum required permissions are:
- sqs:GetQueueAttributes
- sqs:GetQueueUrl
- sqs:SendMessage
- sqs:ReceiveMessage
- sqs:DeleteMessage
Configure your connector to authenticate using chained IAM role assumption:
```
spring:
  cloud:
    aws:
      credentials:
        chained-iam-assumption:
          account-id: <resource-owner-account-id>
          session-name: <optional‑session‑name>
          external-id: <optional‑external‑id>
```
Where:
- account-id (required): The ID of the AWS account where solace-mi-workload-role was configured.
- session-name (optional): A custom Security Token Service (STS) session name. If not configured, the default solace-mi-workload-session.
- external-id (optional): An arbitrary ID to use if the resource owner's trust policy requires an sts:ExternalId condition.
  
  To configure it, you must separate the sts:TagSession and sts:AssumeRole into different statements in the solace-mi-workload-role trust policy and add the following condition to the sts:AssumeRole statement:
```
"Condition":{
  "StringEquals":{
    "sts:ExternalId":"<my_external_id_string>"
  }
}
```

Connecting to Multiple Systems

To connect to multiple systems of a same type, use the multiple binder syntax.

For example:

spring: 
  cloud:
    stream: 
      binders:
        
        # 1st solace binder in this example 
     solace1:
          type: solace 
       environment: 
         solace: 
           java:
             host: tcp://localhost:55555
         
     # 2nd solace binder in this example 
     solace2:
          type: solace 
          environment: 
            solace: 
           java:
             host: tcp://other-host:55555
        
     # The only sqs binder 
     sqs1:
          type: sqs      
          # Add `environment` property map here if you need to customize this binder. 
          # But for this example, we'll assume that defaults are used.
        # The only sqs binder 
     sqs2:
          type: sqs      
          # Add `environment` property map here if you need to customize this binder. 
       # But for this example, we'll assume that defaults are used.
          
     # Required for internal use 
     undefined:
          type: undefined 
     bindings:
          input-0:
            destination: <input-destination> 
         binder: sqs1          output-0:
            destination: <output-destination>
            binder: solace1 # Reference 1st solace binder 
       input-1:
            destination: <input-destination> 
         binder: sqs2          
           output-1:
            destination: <output-destination>
            binder: solace2 # Reference 2nd solace binder

The configuration above defines two binders of type solace and of type sqs, which are then referenced within the bindings.

Each binder above is configured independently under spring.cloud.stream.binders.<bindername>.environment.

When connecting to multiple systems, all binder configuration must be specified using the multiple binder syntax for all binders. For example, under the spring.cloud.stream.binders.<binder-name>.environment.
Do not use single-binder configuration (for example, solace.java.* at the root of your application.yml) while using the multiple binder syntax.

Provide feedback