vbhanuchander-lang opened a new pull request, #7936:
URL: https://github.com/apache/hop/pull/7936
Closes #6982.
### Why
The Azure connection could authenticate with a storage account key or a
managed identity. An
account key grants full, non-expiring access to the entire storage account,
which is what #6982
raises: organisations that have to enforce least privilege cannot use it,
and a managed identity is
not always available (external orchestration, on-prem Hop, short-lived
access handed to a third
party).
A shared access signature is scoped to specific resources and permissions
and carries an expiry,
and is what Microsoft recommends for application-level access to Storage.
### What changed
- **`AzureMetadataType`** — new `sasToken` property,
`@HopMetadataProperty(password = true)` so it
is encrypted at rest and masked in the UI, exactly like
`storageAccountKey`.
- **`AzureFileProvider`** — a `"SAS Token"` branch that resolves variables,
decrypts, and passes the
token to `DataLakeServiceClientBuilder.sasToken(...)`, with a clear error
when the field is empty.
It mirrors the existing `Key` branch.
- **`AzureMetadataTypeEditor`** — `"SAS Token"` added to the authentication
type combo, plus a
`PasswordTextVar` shown only for that type, following the existing
show/hide pattern for the
account key.
- **Docs** — the three authentication types were not documented on the Azure
VFS page at all, so I
added a table covering `Key`, `Managed Identity` and `SAS Token`, plus a
short SAS section on how
to generate one and the expiry caveat.
Two deliberate non-changes:
- **No normalisation of the token.** The SDK javadoc for `sasToken(String)`
states the value "should
only be the query parameters (with or without a leading '?') and not a
full url", so stripping a
leading `?` myself would be redundant. I verified
`sasToken(java.lang.String)` exists on
`DataLakeServiceClientBuilder` in the version we depend on
(`azure-storage-file-datalake` 12.20.0)
rather than assuming it.
- **The global `hop-config.json` path is untouched.** That path only has
`account`/`key` and no
authentication type, so adding SAS there is a separate change to
`AzureConfig` and the options
dialog. Happy to follow up if you'd like it there too.
### Backward compatibility
Existing connections keep working unchanged. The `AzureMetadataType`
constructor still defaults
`authenticationType` to `"Key"`, and the provider still treats an empty
authentication type as
`"Key"`. `keyAuthenticationRemainsTheDefault` pins both.
### Testing
New `AzureSasTokenAuthenticationTest` (4 tests):
| Test | Asserts |
| --- | --- |
| `sasTokenIsStoredOnTheConnectionMetadata` | the token round-trips on the
metadata type |
| `sasTokenIsMarkedAsAPassword` | `password = true` is present — the option
is pointless if the token lands in metadata in clear text |
| `storageAccountKeyRemainsAPassword` | the account key keeps the same
protection |
| `keyAuthenticationRemainsTheDefault` | a new connection still defaults to
`Key` and carries no SAS token |
`mvn test -pl plugins/tech/azure` → **91 tests, 0 failures**.
`spotless:check` and
`apache-rat:check` are clean on the module.
I could not exercise a live SAS handshake without an Azure account, so the
credential path itself is
covered by the empty-token guard and by mirroring the key branch; if you
have a storage account
handy, a manual check against a real signature would be worth doing before
merge.
🤖 AI-assisted changes — generated with Claude Code (Opus 5) and reviewed by
me before submitting.
--
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]
