Skip to content
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

Issue with Progressive Enrollment of Passkey for JIT-Provisioned Federated User #18774

Closed
AfraHussaindeen opened this issue Jan 2, 2024 · 2 comments · Fixed by wso2-extensions/identity-local-auth-fido#128

Comments

@AfraHussaindeen
Copy link
Contributor

AfraHussaindeen commented Jan 2, 2024

Describe the issue:

There is an issue in the progressive enrollment process for Passkey with JIT provisioned federated users. The issue arises when a JIT provisioned user, who hasn't yet enrolled a passkey, engages in the progressive enrollment during the Passkey authentication flow. Although the user successfully authenticates through a federated authenticator at an intermediate phase, the process encounters a failure immediately after the user consents to create a passkey.

At the point of failure, the following error is logged in the console.

Exception: ERROR {org.wso2.carbon.identity.application.authentication.framework.handler.step.impl.DefaultStepHandler} - Authentication failed exception! FIDO2 trusted origin: https://localhost:9443/ sent in the request is invalid.

This error points to a problem with the FIDO2 trusted origin in the request, which seems to be causing the breakdown of the Passkey enrollment flow.

How to reproduce:

  1. Log in to the WSO2 Identity Server Console.
  2. Configure Google as a federated authenticator (as per [1]).
  3. Set up the Passkey to support progressive enrollment (refer to [2]).
  4. Create an application in the console and add Passkey login. Ensure Passkey progressive enrollment is enabled and usernameless authentication is disabled (refer to [3]).
  5. Add Google as an additional authenticator for the first step in the sign-in method tab of the created application and save the changes.
  6. Attempt to log in to the application, which will redirect you to the multi-option sign-in page.
  7. Click on the Sign in with Passkey button.
  8. You will be redirected to a page to add a username. Enter the username and click Create a passkey.
  9. Then select Sign in with Google.
  10. Authenticate yourself following the steps provided by Google. (Ensure the user is already JIT provisioned.)
  11. You will then be redirected to a page stating no passkey found. Click on Create a passkey.

The issue arises in the final steps, where the system fails to redirect the user to perform the passkey creation .

References:
[1] https://is.docs.wso2.com/en/next/guides/authentication/social-login/add-google-login/
[2] https://is.docs.wso2.com/en/next/guides/authentication/passwordless-login/add-passwordless-login-with-passkey/#:~:text=usernameless%20authentication.-,Enable%20Passkey%20progressive%20enrollment,%C2%B6,-This%20feature%20allows
[3] https://is.docs.wso2.com/en/next/guides/authentication/passwordless-login/add-passwordless-login-with-passkey/

Environment information :

  • Product Version: IS 7.0.0-beta6
  • OS: Mac
  • Database: H2

@Thumimku
Copy link
Contributor

Root cause:

When doing JIT provisioning from google, User created with email type username, But the deployment is alphaNumeric username configured.

During the Passkey Enrollment flow we preprocess Username to get mappedLocalUsername which will add carbon.super (the tenant domain) to the username.

Later IS try to StartRegistrationOptions, IS tries to resolve the user's displayname. For that it passes the tenant qualified username to userstore which results user not found.

Screenshot 2024-01-24 at 15 32 28

@Thumimku
Copy link
Contributor

I tried to remove the preprocess procedure, but encountered following issue.

Here we retrieve user from username.

If we remove the preprocess procedure, retrieving user will fail cause we are trying to resolve tenant domain from the username.

Ideal soluction should be improving framework User Model to retrieve user from username and tenant domain passed seperately.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment