Retrieve/ store claim value based on the claim wise configured store location

[NutharaNR]

Proposed changes in this pull request

These changes facilitate the claim wise storage configuration. This allows to selectively configure the claim storage location.i.e. each claim can be chosen to store in either IDENTITY_DB or USER_STORE regardless of the claim being an identity_claim or a user_claim.

Related

• Introduce claim property enableUserStorePersistence and extend excludedUserStores property to all claims. wso2/carbon-identity-framework#7104
• Add enableUserStorePersistence property. wso2/carbon-kernel#4349

The storage location of a claim is determined by the claim property skipUserStore, which accepts a boolean value. By default, this property is set to null. Only a selected subset of claims will have a specifically configured storage location using this property.

For claims without a configured storage location (skipUserStore = null), the system follows the default behavior:

• Identity claims are stored and retrieved from the IDENTITY_DB
• User claims are stored and retrieved from the USER_STORE_DB

If there are any server-level configurations for claim storage, these defaults will apply to claims with skipUserStore = null. However, for claims that have an explicitly configured storage location, the value of skipUserStore will override the server-level configuration.

When should this PR be merged

[Please describe any preconditions that need to be addressed before we
can merge this pull request.]

Follow up actions

[List any possible follow-up actions here; for instance, testing data
migrations, software that we need to install on staging and production
environments.]

Checklist (for reviewing)

General

• Is this PR explained thoroughly? All code changes must be accounted for in the PR description.
• Is the PR labeled correctly?

Functionality

• Are all requirements met? Compare implemented functionality with the requirements specification.
• Does the UI work as expected? There should be no Javascript errors in the console; all resources should load. There should be no unexpected errors. Deliberately try to break the feature to find out if there are corner cases that are not handled.

Code

• Do you fully understand the introduced changes to the code? If not ask for clarification, it might uncover ways to solve a problem in a more elegant and efficient way.
• Does the PR introduce any inefficient database requests? Use the debug server to check for duplicate requests.
• Are all necessary strings marked for translation? All strings that are exposed to users via the UI must be marked for translation.

Tests

• Are there sufficient test cases? Ensure that all components are tested individually; models, forms, and serializers should be tested in isolation even if a test for a view covers these components.
• If this is a bug fix, are tests for the issue in place? There must be a test case for the bug to ensure the issue won’t regress. Make sure that the tests break without the new code to fix the issue.
• If this is a new feature or a significant change to an existing feature? has the manual testing spreadsheet been updated with instructions for manual testing?

Security

• Confirm this PR doesn't commit any keys, passwords, tokens, usernames, or other secrets.
• Are all UI and API inputs run through forms or serializers?
• Are all external inputs validated and sanitized appropriately?
• Does all branching logic have a default case?
• Does this solution handle outliers and edge cases gracefully?
• Are all external communications secured and restricted to SSL?

Documentation

• Are changes to the UI documented in the platform docs? If this PR introduces new platform site functionality or changes existing ones, the changes should be documented.
• Are changes to the API documented in the API docs? If this PR introduces new API functionality or changes existing ones, the changes must be documented.
• Are reusable components documented? If this PR introduces components that are relevant to other developers (for instance a mixin for a view or a generic form) they should be documented in the Wiki.

[CLAassistant]

All committers have signed the CLA.

[Malith-19]

Let's bump the framework version once the dependent PR has merged.

[NutharaNR]

okay

[sadilchamishka]

Let's check why this detected as a change.

[NutharaNR]

In the getLocalClaimInTenant method of IdentityMgtUtil.java (lines 90–102), a ClaimMetadataException is thrown but caught and handled as a UserStoreException.

[sadilchamishka]

We can pass the domain from here.

getCustomPersistenceEnabledClaims Let's think about a good method name. The method name should imply that it returns how claims are persisted.

Do we need both information to be returned?

Suggession:- filterIdentityDataStoreManagedClaims(String[] claimsURIs, String tenantDomain, String domain)

• Get the tenant domain from privilege carbon context.

Returning identity database managed claims should be enough as other claims will be user store managed claims. We don't need to return both explicitly.

[NutharaNR]

Addressed in commit 8b77039. But the userStoreManager instance is passed as an argument due to code refactoring.

filterIdentityDataStoreManagedClaims(String[] claims, UserStoreManager userStoreManager )

[sadilchamishka]

Let's see whether we can organize the logic in this manner.

We invoke a method which gives what are the identity db stored claims. It checkes attribute level data. server level, user store level data also.

In this class, we can simply rely on that information and store in the identity db.

[NutharaNR]

Do you mean removing the hybrid and user store-based logic from this class, delegating it to a separate class (IdentityMgtUtils.java), and keeping this class responsible only for storing the given set of identity claims returned by that utility class?

[NutharaNR]

Addressed in commit 8b77039.

[Malith-19]

Do we have claims which don't have a key?

[NutharaNR]

In previously also, it was checked as a condition. Hence I didn't changed. I will check whether it is required.

[NutharaNR]

TODO: Update unit tests.