BDRS security improvement

[ybidois]

Overview

Explain the topic in 2 sentences

Transition from API Key to Technical User Authentication for BDRS Integration

What's the benefit?

To make it consistent as we have been calling the other services from portal backend and its more secure.

What are the Risks/Dependencies ?

Change from BDRS side would also required.

Detailed explanation

We need to update the authentication mechanism for our portal's integration with the BDRS. The current implementation uses an API Key, but it is needed to switch to a new authentication method using a technical user with client ID and secret. The endpoints the portal is hitting remain unchanged, however, the error handling got improved to support the new errors provided with the technical user authentication method.

Current implementation

Currently we have been calling BDRS by APIKey

Proposed improvements

Feature Team

Contributor

@tfjanjua

Committer

• @oyo
• @ntruchsess
• @Phil91
• @evegufy
• @nitin-vavdiya for BDRS side

User Stories

• https://github.com/eclipse-tractusx/portal-backend/issues/1078

Acceptance Criteria

• [ ] Replace the API Key authentication with the technical user credentials (client ID and secret). [Portal - BDRS IF] Transition from API Key to Technical User Authentication for BDRS Integration portal#456
• [ ] Ensure that all existing endpoints are reachable and fully functional with the new authentication method.
• [ ] Update the error handling to support the new errors specific to technical user authentication.
• [ ] Test all endpoints to ensure that the new authentication is working as expected.
• [ ] Update any documentation to reflect the change in the authentication method.

Test Cases

Functionality and Test Cases should work as they are working right now, this change will only transform the way of calling BDRS service.

Expected Result

• [ ] Obtain the client ID and secret for the technical user from the BDRS team.
• [ ] Update the authentication module in portal to use the technical user's client ID and secret instead of the API Key.
• [ ] Conduct thorough testing on all endpoints to validate the new authentication mechanism.
• [ ] Update the integration documentation to outline the changes in the authentication process.

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented:

• [ ] This feature aligns with our current architectural guidelines
  • Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)
  • [ ] CX-0010 Business Partner Number
  • [ ] CX-0013 Identity of Member Companies
  • [ ] CX-0018 Data Space Connectivity (EDC)
  • [ ] CX-0049 DID Document Schema
  • [ ] CX-0050 Framework Agreement Credential
  • [ ] CX-0149 Verified Company Identity
  • Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)
  • [ ] CX-0001 EDC Discovery API
  • [ ] CX-0002 Digital Twins in Catena-X
  • [ ] CX-0018 Data Space Connectivity (EDC)
  • Data Format:
  • [ ] The data model is based on a published Semantic Model
• [ ] The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
• [ ] Potential risks or conflicts with existing architecture has been assessed

Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)

Additional information

• [ ] I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer) Issues · eclipse-tractusx/sig-release Contribute to eclipse-tractusx/sig-release development by creating an account on GitHub.

[evegufy]

Hi @ybidois I created a bdrs label and added it to the issue. Please also create an issue for the BDRS for this topic https://github.com/eclipse-tractusx/bpn-did-resolution-service/issues. The change on portal side can't be merged without an according change on BDRS side.

[stephanbcbauer]

Some hints from Release Management (@ther3sa) and Tractus-X Project Lead (@stephanbcbauer)

• Status currently in Inbox. ⇾ Only features with status backlog are considered in open planning
• Please add missing sections from the feature template, or fill them out
• Please add contributor and committer

[evegufy]

Portal Committers: @oyo @ntruchsess @Phil91 @evegufy

Only viable if also a BDRS Committer is added

[stephanbcbauer]

@ybidois mentioned ⇾ already implemented on Cofinity-X side ⇾ want to bring it back to Tractus-X