BPDM: Adjust to Rights and Role Concept of 24.08. Release

[nicoprow]

Description

At the moment the rights and roles expected in the default BPDM configuration do not match entirely the configuration of the Central-IDP.

1. There is no client and therefore no roles for the BPDM Orchestrator component as specified here.
2. Like mention in BPDM: Missing Technical User for Component Communication #146 there are no dedicated technical users seeded for establishing an authenticated golden record process
3. There is no technical user for the BPDM provider EDC to create an offer allowing access to the Pool member data

Aligning BPDM and Central-IDP reduces the initialization and configuration overhead. Therefore, I propose to fill the gap between the two systems to enhance the experience of the operators.

Acceptance Criteria

• Add a client for the BPDM Orchestrator component containing the client roles as described in the permissions here.
• Add Orchestrator roles to the technical_roles_management client according to the specification above
• Add a service account for the Portal Gate to access the Orchestrator having the Orchestrator role 'Task Creator'
• Add a service account for the Portal Gate to access the Pool having the Pool role 'Consumer'
• Add a service account for the Cleaning Service Dummy to access the Orchestrator having the Orchestrator roles 'Clean Task Processor' and 'CleanAndSync Task Processor'
• Add a service account for the Pool to access the Orchestrator having the Orchestrator role 'PoolSync Task Processor'
• Add a service account for the BPDM provider EDC having the Pool role 'Member Consumer'

Additional Information

[evegufy]

Hi @nicoprow very good that you make this inconsistency transparent!
Could you please set the milestone to the 24.12 release?
As we're at the end of E2E Testing for 24.08 this change can't be part of 24.08 anymore.

IMO, it should be documented as a known known for BPDM for the 24.08. release that its right and roles concept is not completely reflected in the CX-Central realm config and the workaround for it (so what configuration BPDM did in order to get through the E2E Testing) should be mentioned.

The IAM version for the 24.08. release is the 3.0.1 version and #146 will be part of it, as we added that technical user before E2E Testing started.

Could you please raise an issue for this topic in sig-release so that we can plan it accordingly for 24.12 release and also discuss the testing process for this change in the open planning?

Relates to eclipse-tractusx/sig-release#578 more specifically #86

cc: @MaximilianHauer @jjeroch

[Sebastian-Wurm]

Probably, this issue should be solved for 24.12 under the bug eclipse-tractusx/sig-release#751

[evegufy]

@nicoprow @Sebastian-Wurm does this issue also cover #132 (comment)?

[Sebastian-Wurm]

@nicoprow @Sebastian-Wurm does this issue also cover #132 (comment)?

Yes, this should be included. Additionally to the missing technical users / service accounts for intra-service communication (BPDM internally), I also added a feature as seen by the company admin, that subscribes to BPDM: #168. Also this one should be handled in eclipse-tractusx/sig-release#751

[evegufy]

@nicoprow @Sebastian-Wurm does this issue also cover #132 (comment)?

Yes, this should be included. Additionally to the missing technical users / service accounts for intra-service communication (BPDM internally), I also added a feature as seen by the company admin, that subscribes to BPDM: #168. Also this one should be handled in eclipse-tractusx/sig-release#751

@Sebastian-Wurm ok regarding #132 (comment), @nicoprow could you please take that over as part of #155 (review)?

Regarding missing technical users / service accounts, I already commented on here #168 (comment), it's not related to eclipse-tractusx/sig-release#751 because in eclipse-tractusx/sig-release#751 I'm referring to clients, service accounts, etc... that need to be seeded to be available at startup and with #168 you're are referring to service accounts that are created during runtime.

[Sebastian-Wurm]

@nicoprow @Sebastian-Wurm does this issue also cover #132 (comment)?

Yes, this should be included. Additionally to the missing technical users / service accounts for intra-service communication (BPDM internally), I also added a feature as seen by the company admin, that subscribes to BPDM: #168. Also this one should be handled in eclipse-tractusx/sig-release#751

@Sebastian-Wurm ok regarding #132 (comment), @nicoprow could you please take that over as part of #155 (review)?

Regarding missing technical users / service accounts, I already commented on here #168 (comment), it's not related to eclipse-tractusx/sig-release#751 because in eclipse-tractusx/sig-release#751 I'm referring to clients, service accounts, etc... that need to be seeded to be available at startup and with #168 you're are referring to service accounts that are created during runtime.

OK, understood that you make the difference between Portal runtime and Portal startup time, where you only refer to Portal startup time in eclipse-tractusx/sig-release#751.

Do we get #168 implemented for 24.12, even if it's not so much related to eclipse-tractusx/sig-release#751?

From my point of view it's a left-over of 24.08 and also a security issue, as credentials are given to the Sharing Member, which secure the negotiated EDC assets of the BPDM Gate.

[MaximilianHauer]

Do we get #168 implemented for 24.12, even if it's not so much related to eclipse-tractusx/sig-release#751?

this conversation is slowly getting confusing.
we aligned to split up #168 first.
i assume the newly created story #175 is a part of this ? and therefor your question is referring if #175 could be part of 24.12 ?
anyway we are currently not able to provide a clear feedback on this as this is dependent on how quick we can deliver the topics steered and aligned already for 24.12

[Sebastian-Wurm]

@MaximilianHauer Fair enough. #168 is now split up in #168 and #175. For both points there seems to be a workaround from Cofinity-X side / in their implementation. Still both requirements are valid. Let's see if someone from Cofinity-X wants to contribute.