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

[PasinduYeshan]

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]

Temporary Solution for Sub-Organization Role Tab Visibility Issue

• Fix the role tab hidding issue in Sub-Orgs identity-apps#5308
• Fix the role tab hidding issue in Sub-Orgs carbon-identity-framework#5410
• Add console scope related changes carbon-identity-framework#5416
• Update scopes in api resource collection carbon-identity-framework#5417
• Fix scope related issues that occurred after removing sub-org APIs identity-apps#5339

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

[PasinduYeshan]

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]

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.