Claims-Based Security (CBS) Authentication
Experimental
CBS authentication support is an experimental feature.
The AMQP connector supports Claims-Based Security (CBS) for token-based authentication with AMQP 1.0 brokers. CBS allows the client to authenticate by sending a security token (such as a JWT or SAS token) to the broker over the AMQP connection, rather than relying solely on SASL mechanisms. This is commonly used with brokers like Azure Service Bus.
Enabling CBS
To enable CBS authentication on a channel, set the cbs.enabled attribute:
CBS can be enabled on both incoming and outgoing channels independently.
Providing Tokens
When CBS is enabled, the connector requires a CDI bean implementing CbsTokenProvider. This bean is called during initial connection and on each token refresh cycle.
The getToken method receives the channel configuration, allowing you to adapt token generation per channel (e.g., using different audiences or scopes).
It returns a Uni<CbsToken> to support non-blocking token retrieval from external identity providers.
The CbsToken Interface
A CbsToken provides:
| Method | Description |
|---|---|
token() |
The token string value (JWT, SAS token, etc.) |
type() |
The token type (e.g., "jwt" or "servicebus.windows.net:sastoken") |
expiresAt() |
When the token expires |
refreshAt() |
When the token should be refreshed (defaults to expiresAt() if not set) |
The DefaultCbsToken record provides a convenient implementation:
Token Refresh
The connector automatically refreshes tokens before they expire.
After a successful authorization, a timer is scheduled based on the refreshAt() value of the token.
- If
refreshAt()is set earlier thanexpiresAt(), the token is refreshed proactively. - If the refresh fails after retries, the connection is closed and re-established.
Setting refreshAt() earlier than expiresAt() is recommended to avoid authentication gaps during refresh:
CBS Exchange Protocols
The connector supports two CBS exchange protocols, configured with cbs.exchange:
set-token (default)
The set-token protocol sends the token as an AMQP message to the CBS node with:
- Subject:
set-token - Application property
token-type: the token type - Body: the token string
The broker acknowledges the message to confirm the token was accepted.
put-token
The put-token protocol uses a request-reply exchange, compatible with Azure Service Bus.
It sends the token as a request and validates the response status code.
When using put-token, the cbs.audience attribute sets the token audience.
If not configured, the audience is derived from the broker host and target address in the format amqp://HOST/ADDRESS.
Connection Sharing with CBS
When multiple channels share the same connection using container-id, CBS authentication is performed once for the shared connection:
Both channels share a single connection and a single CBS token authorization.
Azure Service Bus Example
To connect to Azure Service Bus using CBS with SAS tokens:
Retry Configuration
If token authorization fails, the connector retries with exponential backoff. The retry behavior is controlled by the standard connector retry attributes:
If all retries are exhausted, the connection is closed and re-established using the connector's reconnection mechanism.
Configuration Reference
| Attribute | Type | Default | Description |
|---|---|---|---|
cbs.enabled |
boolean | false |
Enable CBS authorization |
cbs.exchange |
string | set-token |
CBS exchange protocol: set-token or put-token |
cbs.audience |
string | Token audience (auto-derived from address if not set) | |
cbs.scopes |
string | Token scopes for authorization | |
cbs.token-manager |
string | default-cbs-token-manager |
CDI bean identifier of a custom CbsTokenManager.Factory |
All attributes are available for both incoming and outgoing channels.