oscerd opened a new issue, #3014:
URL: https://github.com/apache/camel-kamelets/issues/3014
## Summary
Every Salesforce Kamelet in the catalog authenticates with username and
password only. `camel-salesforce` supports four authentication types; the
Kamelets expose one.
Raised originally as a secondary question in #1546 ("does the kamelet
salesforce connector support keystores for authentication? I didn't see the
parameters"). That issue is really about Pub/Sub support, which #3012
addresses, so this splits the authentication half out before it is lost.
## Current state
All five Kamelets build their component bean the same way:
```yaml
- name: local-salesforce
type:
"#class:org.apache.camel.component.salesforce.SalesforceComponent"
properties:
clientId: "{{clientId}}"
clientSecret: "{{clientSecret}}"
userName: "{{userName}}"
password: "{{password}}"
loginUrl: "{{loginUrl}}"
```
| Kamelet | auth properties exposed |
|---|---|
| `salesforce-source` | clientId, clientSecret, userName, password |
| `salesforce-create-sink` | clientId, clientSecret, userName, password |
| `salesforce-update-sink` | clientId, clientSecret, userName, password |
| `salesforce-delete-sink` | clientId, clientSecret, userName, password |
| `salesforce-composite-upsert-sink` | clientId, clientSecret, userName,
password |
(`salesforce-pubsub-source`, added in #3012, follows the same pattern for
consistency — it would be included in whatever is decided here.)
The component offers considerably more:
```
authenticationType: enum ['USERNAME_PASSWORD', 'REFRESH_TOKEN',
'CLIENT_CREDENTIALS', 'JWT']
jwtAudience: String
keystore: org.apache.camel.support.jsse.KeyStoreParameters
instanceUrl: String
```
So JWT bearer flow — the flow Salesforce recommends for server-to-server
integrations, and the one that avoids storing a user password — is unreachable
from the catalog.
## Why it is not a trivial addition
`authenticationType`, `jwtAudience` and `instanceUrl` are plain scalars and
would drop straight in. `keystore` is the problem: it is typed
`KeyStoreParameters`, an object, so there is no scalar to bind a Kamelet
property to.
That leaves the same fork already faced for the OpenSearch Kamelets in #3000:
1. **Build the `KeyStoreParameters` bean inside each template** from scalar
properties (path, password, type). Matches the catalog's usual idiom —
`aws-redshift-sink` builds its `BasicDataSource` this way. But Kamelet beans
are created unconditionally, so a username/password user would still get a
keystore bean constructed, and it needs checking whether an empty one is
harmless here.
2. **Accept a bean reference** — one optional property taking
`#bean:myKeystore`. This is what #3000 does for `sslContextParameters`. Minimal
and safe, but pushes bean registration onto the operator.
Whichever is chosen should be applied consistently across all six Salesforce
Kamelets rather than one at a time, since the auth block is currently identical
in each.
## Suggested scope
- add `authenticationType`, `jwtAudience` and `instanceUrl` as scalar
properties
- decide between (1) and (2) above for `keystore`
- apply uniformly to all six Kamelets
- keep `USERNAME_PASSWORD` as the default so existing bindings are unaffected
Happy to implement once the `keystore` approach is chosen — that decision is
the only part that is not mechanical.
---
_Claude Code on behalf of Andrea Cosentino_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
