-
Notifications
You must be signed in to change notification settings - Fork 718
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Email OTP locale doesn't work for federated users even with 'Assert identity using mapped local subject identifier' toggled on #20606
Comments
The fix is not straightforward and solution may have higher complexity. The following considerations should be taken into account:
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 |
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:
Expected behavior:
The emails or SMS sent triggered by a federated authentication flow should honour the user's locale.
Environment information:
The text was updated successfully, but these errors were encountered: