feat(access): allow more flexible access checks

[oyo]

Description

Enable access checks with arbitrary check functions.

Why

Currently the frontend role check is only based on role name assuming the roles names are unique across clients. This assumption can be incorrect so we implemented a more flexible access check which allows to check for client id and role name. To be future-proof the mechanism now allows arbitrary checks to be executed for decision whether access is granted or not.

In the process some redundant code has been identified and removed.

Issue

#657

Checklist

• I have followed the contributing guidelines
• I have performed a self-review of my own code
• I have successfully tested my changes locally
• I have added tests that prove my changes work
• I have checked that new and existing tests pass locally with my changes
• I have commented my code, particularly in hard-to-understand areas

[evegufy]

Looks good in general but as the impact of this change could be quite huge if there was some inconsistency in which client was validated updated to now: did you check the following?:
"
The following resource needs to get checked when the user access the respective page:

URL	Ressource
/registration	Cl1-CX-Registration
/registration/*	Cl1-CX-Registration
/?overlay=consent_osp	Cl1-CX-Registration
/semantichub	Cl3-CX-Semantic
/admin-credential	Cl24-CX-SSI-Credential-Issuer
/usecase-participation	Cl2-CX-Portal
/certificate-credential	Cl2-CX-Portal
all others	Cl2-CX-Portal

"

[oyo]

Looks good in general but as the impact of this change could be quite huge if there was some inconsistency in which client was validated updated to now:

The logic now intersects the resourceAccess attribute from the keycloak user token with a same object securing any resource. Access is granted if the intersection is not empty which means that at least one required client+role combination has been found in the user token. Tests for this logic are here:

https://github.com/eclipse-tractusx/portal-frontend/blob/feat/657/allow-clientid-for-rolecheck/src/utils/dataUtils.test.ts#L138-L181

did you check the following?: " The following resource needs to get checked when the user access the respective page:

URL Ressource
/registration/* Cl1-CX-Registration

Those URLs are from the registration app and the check must be implemented there.

/registration Cl1-CX-Registration

https://github.com/eclipse-tractusx/portal-frontend/blob/feat/657/allow-clientid-for-rolecheck/src/types/Config.tsx#L111-L112

Checked for combination of Registration client id and VIEW_REGISTRATION role - is this the correct one?

/?overlay=consent_osp Cl1-CX-Registration

Looks like this overlay is not implemented any more.
https://portal.dev.demo.catena-x.net/?overlay=consent_osp
There is a page with this name - but it's broken
https://portal.dev.demo.catena-x.net/consent_osp
@jjeroch has this logic been changed or is it broken for other reasons?

/semantichub Cl3-CX-Semantic

https://github.com/eclipse-tractusx/portal-frontend/blob/feat/657/allow-clientid-for-rolecheck/src/types/Config.tsx#L169-L175

plus two more uses of userHasSemanticHubRole in the semantic hub code

/admin-credential Cl24-CX-SSI-Credential-Issuer

https://github.com/eclipse-tractusx/portal-frontend/blob/feat/657/allow-clientid-for-rolecheck/src/types/Config.tsx#L567-L568

/usecase-participation Cl2-CX-Portal
/certificate-credential Cl2-CX-Portal
all others Cl2-CX-Portal

all other pages are using userHasPortalRole checking for that client id if correctly injected:
https://github.com/eclipse-tractusx/portal-frontend/blob/feat/657/allow-clientid-for-rolecheck/src/services/AccessService.tsx#L97-L98

[jjeroch]

@oyo beside the comment added to the code; one more thing

• Wallet UI - the revocation button should also need a {userHasSsiCredentialRole could you please check this once
• Partner Network - for the Partner Network UI the user needs to have BPDM roles assigned; do we have this validation somewhere included? I couldnt see it

[oyo]

• Wallet UI - the revocation button should also need a {userHasSsiCredentialRole could you please check this once

added userHasSsiCredentialRole(ROLES.REVOKE_CREDENTIALS_ISSUER) to the check

• Partner Network - for the Partner Network UI the user needs to have BPDM roles assigned; do we have this validation somewhere included? I couldnt see it

it is implemented with the check allowTo: () => userHasBpdmRole(ROLES.READ_PARTNER),
src/types/Config.tsx:210 (file too large and not shown by default in diff)
https://github.com/eclipse-tractusx/portal-frontend/pull/873/files#diff-f207e98afeed11e7e08f809e36fa97a268e311ceeeebb779c00d05f3bf99ba6aR210

[evegufy]

@oyo could you please resolve the conflicts? I'd approve it then.

[oyo]

@oyo could you please resolve the conflicts? I'd approve it then.

@evegufy conflicts resolved and PR updated

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud