Adoption Request: Add support for federated identity in Azure Blob Extension

[ank19]

---

name: Adoption Request about: Submit your feature to the project title: 'Adoption Request' labels: 'adoption' assignees: ''

---

Adoption Request

Thank you for wanting to contribute to the project! We are very happy to see the functionalities of the EDC being extended. Providing this open-source is a great opportunity for others with similar requirements and to avoid additional work.

For any details about the guidelines for submitting features, please take a look at the contribution categories.

General information

Please provide some information about your project or code contribution.

_If you choose to be referenced as a "friend", these will be added to the known friends list._ If you choose to add your feature as a core EDC component, links to your current code and correlated issues, discussions, and pull requests are of great importance.

Title	Description	Contact	Links
Integration of Azure Data Lake	Add support for federated identity	andreas.klug2@de.bosch.com	https://github.com/eclipse-edc/Technology-Azure/pull/77

Adoption level

Next, please tell us what level of adoption you intend to provide. (pick only one)

• [ ] Reference a feature as "friend"
• [x] Incorporate a feature as core EDC component

Adoption in EDC core

If you chose to add your feature as a core EDC component, please answer the following questions.

Why should this contribution be adopted?

Please argue why this feature must be hosted upstream and be maintained by the EDC core team. The foundation or core feature is already maintained by the EDC core team. Currently, the extension only supports authentication by providing a shared key. Explicit credential management is companies implies efforts and costs, adhering to security / compliance rules like key rotation. With a few lines of code, a huge security and operational efficiency can be achieved by supporting a standard Microsoft feature named "Federated Identity".

Could it be achieved with existing functionality? If not, why?

If there is any existing code that can achieve the same thing with little modification, that is usually the preferable way for the EDC core team. We aim to keep the code succinct and want to avoid similar/duplicate code. Make sure you understand the EDC code base well! Yes, the change is by itself only a little modification to the existing Azure Blob Storage extension.

Are there multiple use cases or applications who will benefit from the contribution?

Basically, we want you to motivate who will use that feature and why, thereby arguing the fact that it is well-suited to be adopted in the core code base. One-off features are better suited to be maintained externally. I strongly assume that this is the case, as the general topic of managing credentials on a platform like Azure is an issue for all companies.

Can it be achieved without introducing third-party dependencies? If not, which ones?

EDC is a platform rather than an application, therefore we are extremely careful when it comes to introducing third party libraries. The reasons are diverse: security, license issues and over all JAR weight, just to mention a few important ones. No, it cannot be achieved without third-party dependencies, an Azure Identity library has to be added, but that would be just one additional Azure library amongst many which are already present.

Would this feature limit platform independence in any way? If so, how and why?

Features that do not work well in clustered environments are difficult to adopt, since EDC is designed from the ground up to be stateless and clusterable. Similarly, features, that have dependencies onto certain operating systems are difficult to argue. This question does not apply, as the nature of this change wants to address a specific platform.

Is it going to be a self-contained feature, or would it cut across the entire code base?

Features that have a large impact on the code base are very complex to thoroughly test, they have a high chance to destabilize the code and require careful inspection. Self-contained features on the other hand are easier to isolate and test. The feature is self-contained as an extension.

[github-actions[bot]]

Thanks for your contribution :fire: We will take a look asap :rocket:

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.

[github-actions[bot]]

This issue was closed because it has been inactive for 7 days since being marked as stale.