Email OTP locale doesn't work for federated users even with 'Assert identity using mapped local subject identifier' toggled on

[vfraga]

Describe the issue:
We've noticed that the 'locale' claim is not honoured in the Email OTP flow for federated users even if the claim was provided (present in the IdP response or set in the SP adaptive script).

Additionally, when we enabled JIT provisioning and ticked on the 'Assert identity using mapped local subject identifier' checkbox, the output was the same even if the associated local user had a value for the Locality claim (http:https://wso2.org/claims/locality).

Further investigation revealed that we're only trying to retrieve the user attributes from the user store using the username and user store domain shared in the event properties [1][2], which would only work if we passed the username and user store domain from the associated local user when creating the event [3].

We attempted to overcome this limitation by trying different things in the adaptive scripts (e.g., setting the remote/local claim value or changing the subject name to the same as the local user's) with no success.

I think we should allow the retrieval of federated user data since some IdPs can provide their language preferences in their response [4] or the use of the attribute values from the associated local user.

How to reproduce:

1. Set up an Identity Server instance with mail-sending capabilities.
2. Configure the Email OTP feature and add templates in a different language
3. Add a federated authenticator (e.g., Google) and enable JIT provisioning
4. Enable 'Supported by Default' for the 'Locality' local claim to allow changing the user claim values trough the User Profile
5. Set up a Service Provider and add one step with both the federated and basic authentication, and another step with EmailOTP.
6. Tick the 'Assert identity using mapped local subject identifier' checkbox under Local & Outbound Authentication
7. Log in once to create the user locally. The email sent in this step will be in English if the IdP didn't send a value for the user's locale
8. Change the newly created user's locale value in the User Profile with the email template's locality
9. Log in again and observe the email language

Expected behavior:
The emails or SMS sent triggered by a federated authentication flow should honour the user's locale.

Environment information:

• Product Version: IS 5.10.0

[Thisara-Welmilla]

The fix is not straightforward and solution may have higher complexity.

The following considerations should be taken into account:

• Now that multiple claim persisting options are available for JIT provisioning, it is required to honor those options when resolving the locale attribute for the authenticated user.
• This issue is common across many authenticators, so it would be better to handle claim resolving from a central place, such as the authentication framework.
• Consider the fix implemented in [1] when providing a solution for this issue.

Potential solution: Perform the local user associations and resolving user claims, which currently happens post JIT provisioning authentication, after the authentication flow is successfully completed. These claims and the associated local user are required for MFA authentication scenarios.

[1]. wso2-extensions/identity-event-handler-notification#238