Description
Currently, when configuring a Copy Job using the SAP Datasphere Outbound for ADLS2 source, the UI does not provide an option for Shared Access Signature (SAS) authentication to the underlying ADLS Gen2 storage account. This forces users to provide an Account Key (Full Access), which contradicts enterprise security standards of least privilege.
The Inconsistency
There is a clear functional discrepancy within Microsoft Fabric:
Lakehouse Shortcuts: Correctly allow SAS authentication when creating a shortcut to the same ADLS2 storage.
Standard ADLS2 Connections: A standalone ADLS2 connection in a Copy Job or Pipeline allows SAS authentication.
SAP Datasphere Outbound connection in Fabric: When selecting this specific connection type in a Copy Job, the UI restricts the authentication methods, omitting SAS.
Why This Is Critical
Security & Compliance: SAP Datasphere itself supports and recommends SAS tokens for writing to ADLS2 storage. By not supporting SAS on the Fabric side for the same connection, Fabric becomes the "weakest link" in the chain, requiring "all or nothing" Account Keys.
Enterprise Readiness: Large-scale SAP integrations require granular, time-bound access. Using Account Keys for staging containers is often rejected by InfoSec teams.
Workflow Efficiency: Users already have the infrastructure (SAS tokens) generated by SAP Datasphere. Requiring a different credential type specifically for the Fabric Copy Job adds unnecessary friction.
Proposed Solution
Expose the "Shared Access Signature (SAS)" authentication kind within the connection settings for SAP Datasphere Outbound sources in the Copy Job UI, achieving parity with the standard ADLS Gen2 connector.
