Portal User Management for BPDM

[nicoprow]

The authorization concept of the golden record process services (BPDM) has evolved. This impacts the permissions of portal users as well as as the creation of technical users in the Portal.

Relevant concepts

The golden record process contains sharing members which need to share their data (input) to the golden record process and read the result of that process (output). The Pool is a central place that offers golden records that have been created from the shared business partner data. Golden records are distinguished between whether they belong to Catena-X members or not.

BPDM Permission Groups

We defined the following relevant permission groups in BPDM:

1. Gate Admin: Create, update and read sharing member business partner input data as well as read the output data of the golden record process
2. Gate Input Manager: Create, update and read sharing member business partner input data
3. Gate Input Consumer: Read sharing member business partner input data
4. Gate Output Consumer: Read sharing member business partner output data
5. Pool Admin: Read, create and update golden records as well as meta data in the Pool
6. Pool Cx Member: Read golden records that belong to Catena-X members from the Pool
7. Pool Sharing Member: Read golden records of Catena-X members and the overall changelog

Permissions

Permissions as client resources

Cl7-CX-BPDM	Cl16-CX-BPDMGate
read_partner write_partner read_partner_member read_changelog read_changelog_member read_metadata write_metadata	read_input_partner write_input_partner read_input_changelog read_output_partner read_output_changelog read_sharing_state write_sharing_state read_stats

Permissions by permission group

Gate permissions:

Admin	Input Manager	Input Consumer	Output Consumer
All of Cl16-CX-BPDMGate	read_input_partner write_input_partner read_input_changelog read_sharing_state write_sharing_state read_stats	read_input_changelog read_input_partner read_input_changelog read_sharing_state read_stats	read_output_changelog read_output_partner read_output_changelog read_sharing_state read_stats

Pool Permissions:

Admin	Cx Member	Sharing Member
All of Cl7-CX-BPDM	read_partner_member read_changelog_member read_metadata	read_partner_member read_changelog_member read_metadata read_changelog

Mapping to Portal user roles for all companies (for all Catena-X members):

BPDM Permission Group	Portal Role
Gate Admin	Service Manager
Pool Catena-X Member	CX User

Technical Users:

The golden record service provider needs to be able to generate technical users for each permission group (1 - 8). The technical users for sharing member roles 1 - 4 should be associated with the sharing member's BPNL (So that resulting tokens will have the sharing member's BPNL for authorization purposes). Furthermore, there needs to be one technical user option per Pool and Orchestrator permission group.

Resulting technical users to be creatable in the Portal:

For BPDM service:

• Gate BPNLX Admin (for each Sharing Member)
• Pool Admin
• Pool Cx Member
• Pool Sharing Member

For VAS:

• Gate BPNLX Consumer: Having both roles 'Gate BPNLX Input Consumer' and 'Gate BPNLX Output Consumer ' (for each Sharing Member)

Companies which have booked the golden record service should not be able to create any technical users for BPDM. Any such feature to create technical users for companies that are not the golden record service provider should be removed.

Demo Configuration

BPDM is configurable to have arbitrary configurations when it comes to redirect URLs and clients. As long as the above requirements are implemented, BPDM can be configured to be compatible with any Portal environment.

Still, for the sake of defining a demo configuration, here is a proposal:

Clients:*
Cl7-CX-BPDM
Cl16-CX-BPDMGate

Cl7-CX-BPDM:
Valid Origin: https://business-partners.{env}.demo.catena-x.net/pool/*
Description: BPDM Pool

Cl16-CX-BPDMGate:
Valid Origin: https://business-partners{env}.demo.catena-x.net/companies/*
Description: BPDM Gate

Keycloak Example Configuration

This example configuration includes the roles, clients and client scopes that BPDM currently expects.
The actual client IDs are subject to change depending on the name they receive in the Portal Keycloak configuration.

CX-Central.json

[Sebastian-Wurm]

Not sure, why we need "Sharing Member Admin". Just looking at the permissions, there seems to be no difference to "Sharing Member Input Manager". From a business point of view, no one from outside the Sharing Member company should have access to the Gate. The access by the Sharing Member is always through the EDC. So also from business point of view, we do not need Sharing Member Admin.

[nicoprow]

Not sure, why we need "Sharing Member Admin". Just looking at the permissions, there seems to be no difference to "Sharing Member Input Manager". From a business point of view, no one from outside the Sharing Member company should have access to the Gate. The access by the Sharing Member is always through the EDC. So also from business point of view, we do not need Sharing Member Admin.

Seems I have forgotten to add more permissions to that role. The Sharing Member Admin role is what specifically the Portal would need in order to access the Gate. Otherwise, the Portal would need to use several technical users for each company to access the Gate. I think since we know the role of the Portal to have full access to the Gate I added it here as well.

I also added tables for the role permissions so we have a better overview. I kept the list above to illustrate how these permissions are actually expected to be written.

[jjeroch]

Status Release Image of Seeding data

Clients:
Cl7-CX-BPDM
Cl16-CX-BPDMGate

Cl7-CX-BPDM:
Valid Redirects: https://partners-pool.{env}.demo.catena-x.net/*
Description: BPDM Pool
Permissions:

• add_company_data
• delete_company_data
• view_company_data

Cl16-CX-BPDMGate:
Valid Redirects: https://partners-gate.{env}.demo.catena-x.net/*
Description: Portal Gate
Permissions:

• update_company_data
• view_company_data
• view_shared_data

---

Technical User Roles available inside the core:
BPDM Pool - view_company_data on the pool
BPDM Management - full pool access
BPDM Partner Gate - full gate access
BPDM Gate Read - view_company_data gate access
BPDM Gate Read & Write - full gate access

Role	Available for
BPDM Pool	"Operator", "CX Participant", "Service Provider", "App Provider"
BPDM Management	"Operator"
BPDM Partner Gate	"Operator"
BPDM Gate Read	"Operator", "CX Participant", "Service Provider", "App Provider"
BPDM Gate Read & Write	"Operator", "CX Participant", "Service Provider", "App Provider"

[nicoprow]

Status Release Image of Seeding data

Clients: Cl7-CX-BPDM Cl16-CX-BPDMGate

Cl7-CX-BPDM: Valid Redirects: https://partners-pool.{env}.demo.catena-x.net/* Description: BPDM Pool Permissions:

* add_company_data

* delete_company_data

* view_company_data

Cl16-CX-BPDMGate: Valid Redirects: https://partners-gate.{env}.demo.catena-x.net/* Description: Portal Gate Permissions:

* update_company_data

* view_company_data

* view_shared_data

Technical User Roles available inside the core: BPDM Pool - view_company_data on the pool BPDM Management - full pool access BPDM Partner Gate - full gate access BPDM Gate Read - view_company_data gate access BPDM Gate Read & Write - full gate access

Role Available for
BPDM Pool "Operator", "CX Participant", "Service Provider", "App Provider"
BPDM Management "Operator"
BPDM Partner Gate "Operator"
BPDM Gate Read "Operator", "CX Participant", "Service Provider", "App Provider"
BPDM Gate Read & Write "Operator", "CX Participant", "Service Provider", "App Provider"

I incorporated the As-Is information into the requirement description.

I think the issue is now ready to be processed.

[nicoprow]

Added a keycloak realm definition in order to further illustrate how the BPDM applications currently expect the Keycloak configuration to be.

[nicoprow]

Added Orchestrator permissions and restructured comment to better align with Keycloak concepts

[jjeroch]

@nicoprow what happened here - this is not the same requirement anymore as shared 2 weeks ago
....

[nicoprow]

@jjeroch Since we are currently working on our own Keycloak configuration I saw the chance to rephrase the issue to be more aligned with a Keycloak configuration requirement to make it more expressive. For the clients BPDM and BPDMGate the requirements didn't change, I just think I expressed it better.

In regards to the Orchestrator configuration that is something I actually added afterwards. I was not aware that these requirements had already been digested by you. If the Orchestrator makes problems I can also remove it. Or I can revert the Issue description to the previous version. It's not ideal for us, but it doesn't break anything really

[Sebastian-Wurm]

I fully agree that this feature should describe the BPDM KeyCloak configuration as required for a GoLive of the operating company with BPDM. Since the orchestrator is sadly and probably not used by the only operating company, we know of, it would be OK to not implement this in 24.05 portal. However, I would leave the orchestrator permissions in the description and just state our decision here.
@nicoprow: Do we need the orchestrator permissions for our E2E tests?

[nicoprow]

Orchestrator config is not needed to perform the E2E tests.
I removed the Orchestrator config from the issue.

I also revised the technical user requirements according to our sync.
Technical users for sharing members are now reduced to 1 per service.
Also defined the technical users for the VAS

[stephanbcbauer]

Hello @jjeroch , @evegufy

Since the feature is a 24.05 feature and the development phase for 24.08 is coming to an end, we need a status on the feature. Can you please update the status?

• Currently you are assigned (Responsible) → Is this correct? If not, please assign the correct contact person
• Please check whether the status (backlog, work in progress ...) is set correctly
• Please comment on the current status of the feature
• Are all SubTasks (issues from other repositories that deal with the feature) linked? → The easiest way is to mention the feature here in the issue (via the ID) so we can see which teams/repositories are involved.
• Is there a spillover planned?

If you need any clarification, please get in touch, thank you very much.

Stephan

[jjeroch]

The feature was delivered with 24.05.
Changes are included in the following ticket (note the tickets are holding multiple permission/role changes)
eclipse-tractusx/portal-iam#66
eclipse-tractusx/portal-iam#102