Provide support to block authorizing/assigning scopes from a given set of API resource identifiers#8095
Provide support to block authorizing/assigning scopes from a given set of API resource identifiers#8095ashanthamara wants to merge 1 commit into
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (8)
📝 WalkthroughWalkthroughThis PR implements a server-wide blocking mechanism for specified API resources in both application API authorization and role permission assignment. It adds configuration constants, database schema support for scope-based associations, validation and filtering logic, and updates exception handling to properly manage blocked resources. ChangesAPI Resource Blocking Framework
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![wso2-engineering[bot]](https://avatars.githubusercontent.com/in/1856828?s=60&v=4){kind=small}
There was a problem hiding this comment.
AI Agent Log Improvement Checklist
- The log-related comments and suggestions in this review were generated by an AI tool to assist with identifying potential improvements. Purpose of reviewing the code for log improvements is to improve the troubleshooting capabilities of our products.
- Please make sure to manually review and validate all suggestions before applying any changes. Not every code suggestion would make sense or add value to our purpose. Therefore, you have the freedom to decide which of the suggestions are helpful.
✅ Before merging this pull request:
- Review all AI-generated comments for accuracy and relevance.
- Complete and verify the table below. We need your feedback to measure the accuracy of these suggestions and the value they add. If you are rejecting a certain code suggestion, please mention the reason briefly in the suggestion for us to capture it.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java (1)
668-691:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winServer exceptions from the inner block get wrapped twice.
An
IdentityRoleManagementServerExceptionraised fromaddPermissions(e.g., the newAPIResourceMgtExceptionwrapping) is caught by the innercatch (SQLException | IdentityRoleManagementException e), rolled back, and rethrown. It is then re-caught by the outercatch (SQLException | IdentityRoleManagementException e)on Line 686 and wrapped again with the generic"Error while adding permissions to roleId : " + roleIdmessage, masking the original error code/context. Consider adding an outercatch (IdentityRoleManagementServerException e) { throw e; }(next to the existing client-exception passthrough) so already-typed server exceptions propagate as-is.♻️ Proposed adjustment
} catch (IdentityRoleManagementClientException e) { throw e; + } catch (IdentityRoleManagementServerException e) { + throw e; } catch (SQLException | IdentityRoleManagementException e) { String errorMessage = "Error while adding permissions to roleId : " + roleId; throw new IdentityRoleManagementServerException(UNEXPECTED_SERVER_ERROR.getCode(), errorMessage, e); }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java` around lines 668 - 691, The inner catch in RoleDAOImpl that rethrows IdentityRoleManagementServerException gets wrapped again by the outer catch; modify the exception handling so server exceptions propagate unchanged: add an outer catch block for IdentityRoleManagementServerException (alongside the existing IdentityRoleManagementClientException passthrough) that simply rethrows the exception, so exceptions thrown by addPermissions or other methods (e.g., IdentityRoleManagementServerException) are not wrapped again by the outer catch that creates the generic "Error while adding permissions to roleId : " message; keep the rollback/commit logic intact and only let the SQLException | IdentityRoleManagementException outer catch perform wrapping.
🧹 Nitpick comments (4)
components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImpl.java (1)
342-345: ⚡ Quick winAdd a handled-client-error log before rejecting blocked API authorization.
The blocked-identifier branch throws a client exception silently. Add a WARN/DEBUG log with safe identifiers (
apiId/resource identifier) right before the throw to improve traceability in this auth path.As per coding guidelines, "Use WARN/DEBUG for handled client/request errors (e.g., INVALID_REQUEST / INVALID_PERMISSION) rather than ERROR."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImpl.java` around lines 342 - 345, In AuthorizedAPIManagementServiceImpl, before the branch that throws buildClientException(INVALID_REQUEST, ...) when blockedIdentifiers.contains(apiResource.getIdentifier()), add a handled-client log (WARN or DEBUG per guideline) that records the safe identifiers (e.g., apiId and apiResource.getIdentifier()) to aid traceability; place the log call immediately before the throw, use the class's logger instance, and avoid logging sensitive data while referencing blockedIdentifiers and apiResource.getIdentifier() in the message.components/application-mgt/org.wso2.carbon.identity.application.mgt/src/test/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImplTest.java (1)
104-157: ⚡ Quick winAdd explicit tests for blocked-resource rejection on add and patch flows.
Given the new server-side block check, add focused tests that assert
addAuthorizedAPI(...)andpatchAuthorizedAPI(...)fail when the API identifier is configured in blocked resources, and pass for non-blocked APIs.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/application-mgt/org.wso2.carbon.identity.application.mgt/src/test/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImplTest.java` around lines 104 - 157, Add unit tests in AuthorizedAPIManagementServiceImplTest to verify server-side blocked-resource checks: configure the blocked API identifiers via APIResourceManagementServiceComponentHolder (or the existing configuration helper used in setUp), then assert that calling authorizedAPIManagementService.addAuthorizedAPI(appId, authorizedAPI, tenantDomain) and authorizedAPIManagementService.patchAuthorizedAPI(appId, authorizedAPI, tenantDomain) throw the expected exception or return failure when authorizedAPI.getApiId() is in the blocked list, and that the same calls succeed for an authorizedAPI whose apiId is not blocked; use the existing helpers addTestAPIResource, addApplication and the AuthorizedAPI builder to create test inputs and assert failure for blocked-resource cases and success for non-blocked cases.components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java (2)
2045-2069: 💤 Low valueN API-resource lookups per
addPermissionscall.
getBlockedAPIResourceIdsperforms onegetAPIResourceByIdentifierlookup per configured identifier on every invocation ofaddPermissions. The blocked-resource identifier list is server-wide configuration that doesn't change at runtime, but the resolved IDs are tenant-specific. Consider caching the resolved ID set per tenant (e.g., a small concurrent map keyed by tenant domain), so we don't repeatedly round-trip to the API resource layer for every role/permission mutation.Also, on
APIResourceMgtExceptionthe original exception is wrapped without a specific error code; consider usingUNEXPECTED_SERVER_ERROR.getCode()(as elsewhere in this class) and throwingIdentityRoleManagementServerExceptionfor consistency with the rest of the file's error handling.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java` around lines 2045 - 2069, getBlockedAPIResourceIds currently does a per-identifier APIResource lookup on every call (causing N lookups in addPermissions); change it to resolve identifiers once per tenant and cache the resulting Set<String> of API IDs in a thread-safe map keyed by tenantDomain (e.g., a ConcurrentHashMap<String, Set<String>>) and consult the cache at the start of getBlockedAPIResourceIds to avoid repeated calls to RoleManagementServiceComponentHolder.getApiResourceManager().getAPIResourceByIdentifier; on cache miss populate the set as now and put it into the map. Also replace the thrown IdentityRoleManagementException on APIResourceMgtException with IdentityRoleManagementServerException using UNEXPECTED_SERVER_ERROR.getCode() and include the caught exception as the cause to preserve stack traces.
2013-2016: ⚡ Quick winFetching all tenant scopes per permission update may be expensive even with caching.
getScopesByTenantDomain(tenantDomain, StringUtils.EMPTY)loads every scope for the tenant on each call, materializing them into a grouped map in memory to resolve permission names. Although the underlying DAO call is cached, the code still processes all scopes even when only a handful of permission names need resolution. For tenants with large API-resource catalogs this is unnecessary overhead on a hot path (every role update/creation that passes permissions).While
APIResourceManageroffersgetScopeByName()andgetScopeByNameAndApiResourceId()for single-scope lookups, these don't fit the use case here because the code must handle cases where multiple scopes share the same name across different API resources and filter by blocked resources.Consider:
- Caching the grouped scope set (keyed by tenant + blocked resources config) so repeated requests reuse the in-memory map instead of recomputing it, or
- Building a more efficient multi-name lookup in
APIResourceManagerif the pattern repeats elsewhere.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java` around lines 2013 - 2016, The code in RoleDAOImpl currently calls APIResourceManager.getScopesByTenantDomain(tenantDomain, StringUtils.EMPTY) and groups all scopes into nameToScopes on every permission update, which is expensive; change this to avoid materializing all scopes each call by either (A) introducing a cached grouped-scope map keyed by tenantDomain and the blocked-resources configuration and use that cache in RoleDAOImpl when resolving permission names (reuse the grouped Map<String,List<Scope>> instead of recomputing nameToScopes each time), or (B) add a new APIResourceManager method (e.g., getScopesByNames(tenantDomain, Set<String> names, Set<String> blockedResourceIds)) that returns only scopes for the requested names filtered by blocked resources and call that from RoleDAOImpl when resolving permissions; locate the logic around getScopesByTenantDomain and the nameToScopes grouping in RoleDAOImpl and update it to use the new cached/grouped map or the new multi-name APIResourceManager lookup accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java`:
- Around line 2005-2043: resolveScopeIdsExcludingBlockedAPIResourceScopes
currently drops permissions silently when nameToScopes returns empty or when
multiple scopes exist but all are in blockedApiResourceIds; update the loop over
permissions (inspect scopesOfSameName and blockedApiResourceIds) to fail-fast:
if scopesOfSameName.isEmpty() throw an
IdentityRoleManagementClientException(INVALID_PERMISSION.getCode(), "Permission:
" + permission.getName() + " is invalid or missing"), and if
scopesOfSameName.size() > 0 but none of the scopes pass the
!blockedApiResourceIds.contains(scope.getApiID()) test (i.e., all are blocked)
also throw the same INVALID_PERMISSION exception (optionally log a WARN before
throwing); keep adding scope.getId() only for non-blocked scopes as before.
- Around line 1943-1976: The code now uses tenantDomainToSearchScopes when
resolving tenantId in the else branch (tenantIdToSearchScopes) causing
non-blocked scope additions to use the primary-org tenant ID (org-level scope
sharing); confirm with architecture whether org-level scope ownership is
intended, and if not, change the else branch to resolve tenantId from the
original tenantDomain (not tenantDomainToSearchScopes) when adding scopes via
ADD_ROLE_SCOPE_SQL (affecting variables tenantIdToSearchScopes, roleId,
permissions), and add a short comment explaining the chosen behavior and
add/update a unit/integration test covering sub-org role scope assignment to
validate the final behavior.
---
Outside diff comments:
In
`@components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java`:
- Around line 668-691: The inner catch in RoleDAOImpl that rethrows
IdentityRoleManagementServerException gets wrapped again by the outer catch;
modify the exception handling so server exceptions propagate unchanged: add an
outer catch block for IdentityRoleManagementServerException (alongside the
existing IdentityRoleManagementClientException passthrough) that simply rethrows
the exception, so exceptions thrown by addPermissions or other methods (e.g.,
IdentityRoleManagementServerException) are not wrapped again by the outer catch
that creates the generic "Error while adding permissions to roleId : " message;
keep the rollback/commit logic intact and only let the SQLException |
IdentityRoleManagementException outer catch perform wrapping.
---
Nitpick comments:
In
`@components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImpl.java`:
- Around line 342-345: In AuthorizedAPIManagementServiceImpl, before the branch
that throws buildClientException(INVALID_REQUEST, ...) when
blockedIdentifiers.contains(apiResource.getIdentifier()), add a handled-client
log (WARN or DEBUG per guideline) that records the safe identifiers (e.g., apiId
and apiResource.getIdentifier()) to aid traceability; place the log call
immediately before the throw, use the class's logger instance, and avoid logging
sensitive data while referencing blockedIdentifiers and
apiResource.getIdentifier() in the message.
In
`@components/application-mgt/org.wso2.carbon.identity.application.mgt/src/test/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImplTest.java`:
- Around line 104-157: Add unit tests in AuthorizedAPIManagementServiceImplTest
to verify server-side blocked-resource checks: configure the blocked API
identifiers via APIResourceManagementServiceComponentHolder (or the existing
configuration helper used in setUp), then assert that calling
authorizedAPIManagementService.addAuthorizedAPI(appId, authorizedAPI,
tenantDomain) and authorizedAPIManagementService.patchAuthorizedAPI(appId,
authorizedAPI, tenantDomain) throw the expected exception or return failure when
authorizedAPI.getApiId() is in the blocked list, and that the same calls succeed
for an authorizedAPI whose apiId is not blocked; use the existing helpers
addTestAPIResource, addApplication and the AuthorizedAPI builder to create test
inputs and assert failure for blocked-resource cases and success for non-blocked
cases.
In
`@components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java`:
- Around line 2045-2069: getBlockedAPIResourceIds currently does a
per-identifier APIResource lookup on every call (causing N lookups in
addPermissions); change it to resolve identifiers once per tenant and cache the
resulting Set<String> of API IDs in a thread-safe map keyed by tenantDomain
(e.g., a ConcurrentHashMap<String, Set<String>>) and consult the cache at the
start of getBlockedAPIResourceIds to avoid repeated calls to
RoleManagementServiceComponentHolder.getApiResourceManager().getAPIResourceByIdentifier;
on cache miss populate the set as now and put it into the map. Also replace the
thrown IdentityRoleManagementException on APIResourceMgtException with
IdentityRoleManagementServerException using UNEXPECTED_SERVER_ERROR.getCode()
and include the caught exception as the cause to preserve stack traces.
- Around line 2013-2016: The code in RoleDAOImpl currently calls
APIResourceManager.getScopesByTenantDomain(tenantDomain, StringUtils.EMPTY) and
groups all scopes into nameToScopes on every permission update, which is
expensive; change this to avoid materializing all scopes each call by either (A)
introducing a cached grouped-scope map keyed by tenantDomain and the
blocked-resources configuration and use that cache in RoleDAOImpl when resolving
permission names (reuse the grouped Map<String,List<Scope>> instead of
recomputing nameToScopes each time), or (B) add a new APIResourceManager method
(e.g., getScopesByNames(tenantDomain, Set<String> names, Set<String>
blockedResourceIds)) that returns only scopes for the requested names filtered
by blocked resources and call that from RoleDAOImpl when resolving permissions;
locate the logic around getScopesByTenantDomain and the nameToScopes grouping in
RoleDAOImpl and update it to use the new cached/grouped map or the new
multi-name APIResourceManager lookup accordingly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
Run ID: 5766eea0-8345-4dc9-b9f2-002bec3cbae9
📒 Files selected for processing (8)
components/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/ApplicationConstants.javacomponents/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImpl.javacomponents/application-mgt/org.wso2.carbon.identity.application.mgt/src/main/java/org/wso2/carbon/identity/application/mgt/dao/impl/AuthorizedAPIDAOImpl.javacomponents/application-mgt/org.wso2.carbon.identity.application.mgt/src/test/java/org/wso2/carbon/identity/application/mgt/AuthorizedAPIManagementServiceImplTest.javacomponents/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/RoleConstants.javacomponents/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.javacomponents/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/SQLQueries.javafeatures/identity-core/org.wso2.carbon.identity.core.server.feature/resources/identity.xml.j2
There was a problem hiding this comment.
Pull request overview
This PR adds server-wide blocklist support to prevent (a) authorizing certain API resources to applications and (b) assigning permissions/scopes that belong to blocked API resources to roles, with corresponding identity.xml configuration and some DAO/transaction updates.
Changes:
- Introduces new identity.xml configuration sections and constants for blocked API resource identifiers (application authorization + role permission assignment).
- Enforces blocklists in
AuthorizedAPIManagementServiceImpland filters implicit cross-API authorization inAuthorizedAPIDAOImpl. - Updates role permission persistence to optionally resolve scope IDs (excluding blocked API resource scopes) and adds related SQL/constants, plus transaction/error propagation tweaks.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| features/identity-core/org.wso2.carbon.identity.core.server.feature/resources/identity.xml.j2 | Adds new APIResourceManagement config blocks for blocked API resources. |
| components/role-mgt/.../RoleConstants.java | Adds config key for role permission assignment blocked API resources; adds SCOPE_ID column constant; updates copyright. |
| components/role-mgt/.../dao/SQLQueries.java | Adds ADD_ROLE_SCOPE_BY_ID_SQL for inserting role-scope mappings by scope ID; updates copyright. |
| components/role-mgt/.../dao/RoleDAOImpl.java | Implements blocked API resource-aware permission assignment logic; adjusts transaction rollback/rethrow behavior; updates copyright. |
| components/application-mgt/.../AuthorizedAPIManagementServiceImplTest.java | Test setup updated to register APIResourceManager in the component holder earlier. |
| components/application-mgt/.../dao/impl/AuthorizedAPIDAOImpl.java | Filters out blocked API resources when implicitly authorizing reused/shared scopes. |
| components/application-mgt/.../AuthorizedAPIManagementServiceImpl.java | Validates API resource is not blocked before add/patch operations. |
| components/application-mgt/.../ApplicationConstants.java | Adds config key for application API authorization blocked API resources; updates copyright. |
Comments suppressed due to low confidence (1)
components/role-mgt/org.wso2.carbon.identity.role.v2.mgt.core/src/main/java/org/wso2/carbon/identity/role/v2/mgt/core/dao/RoleDAOImpl.java:1953
- The new blocked-API-resource-aware permission assignment path (resolving scope IDs and rejecting blocked permissions) is not covered by tests. Add DAO tests covering (a) blocked list empty -> existing behavior, (b) single matching scope belonging to a blocked API -> client exception, and (c) multiple scopes with same name where only some are blocked -> blocked scopes skipped.
Set<String> blockedAPIResourceIds = getBlockedAPIResourceIds(tenantDomainToSearchScopes);
try {
// If there are blocked API resources, resolve the scope IDs for the permissions while excluding the
// scopes of the blocked API resources, and add the permissions with scope IDs.
// Otherwise, add the permissions with scope names.
if (!blockedAPIResourceIds.isEmpty()) {
List<String> addedScopeIds = resolveScopeIdsExcludingBlockedAPIResourceScopes(roleId, permissions,
blockedAPIResourceIds, tenantDomainToSearchScopes);
|
|
||
| ApplicationManagementService applicationManagementService = ApplicationManagementServiceImpl.getInstance(); | ||
| validateTenantDomain(applicationId, tenantDomain, applicationManagementService); | ||
| validateAPIResourceNotBlocked(authorizedAPI.getAPIId(), tenantDomain); |
Codecov Report❌ Patch coverage is ❌ Your patch check has failed because the patch coverage (23.66%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## master #8095 +/- ##
============================================
- Coverage 53.27% 53.17% -0.10%
+ Complexity 20851 20595 -256
============================================
Files 2147 2147
Lines 127691 126746 -945
Branches 18264 18200 -64
============================================
- Hits 68033 67403 -630
+ Misses 51365 51095 -270
+ Partials 8293 8248 -45
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…t of API resource identifiers
ashanthamara
force-pushed
the
api-resource-block
branch
from
29599de to
3bf1560
Compare
|
|
PR builder started |
|
PR builder completed |
|
PR builder started |
|
PR builder completed |
This pull request introduces new mechanisms to block authorization and permission assignments for specific API resources, based on configurable server-wide block lists. It also adds related configuration options, improves error handling, and updates copyright years.
API Authorization Blocking Enhancements:
APPLICATION_API_AUTHORIZATION_BLOCKED_API_RESOURCES, toApplicationConstantsfor specifying API resources that should be blocked from application authorization.AuthorizedAPIManagementServiceImplto check and prevent authorization of blocked API resources during both addition and patching of authorized APIs, throwing a client exception if a blocked resource is used. [1] [2] [3]AuthorizedAPIDAOImplto filter out blocked API resources when auto-authorizing system APIs with shared scopes, ensuring blocked resources are not implicitly authorized. [1] [2]Role Permission Assignment Blocking:
ROLE_PERMISSION_ASSIGNMENT_BLOCKED_API_RESOURCES, toRoleConstantsfor blocking role permission assignments to certain API resources.Code Quality and Maintenance:
RoleDAOImplto ensure proper rollback and rethrowing of client exceptions. [1] [2]SCOPE_IDtoRoleConstants.RoleTableColumns.Related issue