Issue with Scope Checks for Tenant and Sub-Organization Levels in Frontend

PasinduYeshan commented 5 months ago

Describe the issue: We're encountering an issue in the frontend regarding scope checks at both tenant and sub-organization levels. The current implementation in deployment.config.json does not effectively differentiate between scopes that are specific to tenants or sub-organizations.

Eg:

"applications": {
    "disabledFeatures": [],
    "enabled": true,
    "scopes": {
        "feature": ["console:applications"],
        "create": ["internal_application_mgt_create"],
        "read": [
            "internal_cors_origins_view",
            "internal_application_mgt_view",
            "internal_claim_meta_view",
            "internal_role_mgt_view",
            "internal_userstore_view",
            "internal_idp_view"
        ],
        "update": ["internal_application_mgt_update"],
        "delete": ["internal_application_mgt_delete"]
    }
}

In the current setup, for sub-organizations, the frontend appends _org to the internal scopes (e.g., internal_org_application_mgt_view). However, some scopes are either tenant-specific or sub-organization-specific.

For instance, the scope internal_org_cors_origin_view does not exist, leading to issues such as the application view being hidden in sub-organizations due to checks for a non-existing scope.

Expected behavior: The FE should have a clear distinction and handling mechanism for scopes that are specific to tenants or sub-organizations.

Suggested Solution: A potential solution could be to establish separate scope definitions for sub-organizations and modify the scope-checking logic to recognize and handle these correctly. This would involve both backend and frontend adjustments to manage these scope distinctions properly.

Environment information (Please complete the following information; remove any unnecessary fields) :

Product Version: [e.g., IS 5.10.0, IS 5.9.0]
OS: [e.g., Windows, Linux, Mac]
Database: [e.g., MySQL, H2]
Userstore: [e.g., LDAP, JDBC]

Optional Fields

Related issues:

Suggested labels:

PasinduYeshan commented 5 months ago

Temporary Solution for Sub-Organization Role Tab Visibility Issue

These removed scopes should be reinstated when a distinct scope checking mechanism is introduced for both tenant and sub-organizations.

PasinduYeshan commented 5 months ago

The updated scopes under the temporary solution are tracked in the following sheet: https://docs.google.com/spreadsheets/d/1N1hcwxxlpcAYQr2YPvTVgI_mNXGomKpGGB76EIVGp_M/edit#gid=0

PasinduYeshan commented 5 months ago

Further, there is a requirement where sub-organization users should have the option to invite the parent users but not the ability for direct user creation. To cater to such requirements, we will need sub-feature-wise scope check capabilities. In my opinion, since we have to put considerable effort into separating sub-organization and tenant scopes, it would be better to consider this capability as well.

wso2 / product-is

Issue with Scope Checks for Tenant and Sub-Organization Levels in Frontend #19094

Optional Fields