oyo commented 2 weeks ago

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

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

oyo commented 2 weeks ago

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?