Unable to proceed Federation Flow when JIT Provisioning enabled with "Prompt for password and consent" option or "Prompt for consent" option

[NilukaSripalim]

Describe the issue:

When attempting to proceed with the Federation flow with Just-in-Time (JIT) provisioning enabled, specifically with the options "Prompt for password and consent" and "Prompt for consent," users are encountering an error: "invalid user name. Please pick a valid username." This error prevents users from successfully completing the Federation flow.

How to reproduce: Initiate the Federation flow with JIT provisioning enabled. Select the options "Prompt for password and consent" or "Prompt for consent."

Ex: setup Google / Federated Authentication with Asgardeo

Expected behavior: Users should be able to complete the Federation flow seamlessly, even with JIT provisioning

Environment information (Please complete the following information; remove any unnecessary fields) :

• Product Version: wso2is-7.0.0-alpha-SNAPSHOT
• OS: Mac -
• Database: Mysql - 8.1.0
• Userstore: JDBC
• Browse - Safari, Firefox

---

jitissue.webm

[UdeshAthukorala]

This is not reproducible with Google. This issue is only reproducible with Federated Authentication with Asgardeo.

[UdeshAthukorala]

Analysis

When the Jit provisioning was enabled with the options "Prompt for password and consent" or "Prompt for consent" options, after the user was authenticated from the federated IDP, user was redirected to user creation page[1] to get the user consent.In this user creation page we are doing the username validation[2]. When we using asgardeo as a federated IDP, Unique identifier is returned as subject identifier(UUID) for a federated user during JIT provisioning. For federated users. if the username is not specified, we are using subject identifier as the default username for federated users[3]. So we have a UUID as the username of this federated user and username validation was failed at the user creation page since uuid is not match with our username regex pattern.

But we have configured the silent JIT provisioning we didn't encounter this issue and user provisioning happened successfully. This provisioned user even also has a UUID as the username. The reason for this behaviour is when the silent JIT provisioning was enabled user was, not redirected to the user creation page and hence the FE username validation not happened. And also when the user was creating, we are skipping the username validation for JIT provisioned users here.[4] We have done this improvement[5] purposefully for fix a similar issue occured in the jit provisioning. More details on this can be find out from here[6].

[1] https://github.com/wso2/carbon-identity-framework/blob/b2c108308182f3ba21bc2bd401da99f32e105fea/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/request/impl/JITProvisioningPostAuthenticationHandler.java#L343-L352 [2] https://github.com/wso2/identity-apps/blob/344986b75d91404040d8c3c91c3a3e0abf58c7f9/identity-apps-core/apps/recovery-portal/src/main/webapp/self-registration-process.jsp#L170 [3] https://github.com/wso2/carbon-identity-framework/blob/622bf35b46c3ccf972dcb71ba558ecd2155255a3/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/step/impl/DefaultStepHandler.java#L754-L758 [4] https://github.com/wso2/carbon-identity-framework/blob/8bbdd740f4d035ab7fd6ced3523bc775eca7ce52/components/authentication-framework/org.wso2.carbon.identity.application.authentication.framework/src/main/java/org/wso2/carbon/identity/application/authentication/framework/handler/provisioning/impl/DefaultProvisioningHandler.java#L239 [5] https://github.com/wso2/carbon-identity-framework/pull/4011 [6] Jit Provisioning Username Regex Validation

[UdeshAthukorala]

After having a discussion with @madurangasiriwardena decided to provide a documentation improvement to mandate username claim mapping for this scenario. Exact solution is not yet finalyzed.

[malithie]

This is my understanding on this. We already have introduced a claim as "externalId" and unless specified by default 'sub should' be mapped for that internally.

In addition to above, by default 'sub' should be mapped to usename claim and the user should have the choice to change it

FYI: @ayshsandu can you review this with Asgardeo behaviour and comment if above needs to be changed FYI: @darshanasbg

[Thisara-Welmilla]

Doc issue: https://github.com/wso2/product-is/issues/18594

[NilukaSripalim]

This issue is reopened , can be reproduced RC5 pack as well Followed the same steps.

toml

[server]
hostname = "wso2.iam.com"
node_ip = "127.0.0.1"
base_path = "https://$ref{server.hostname}:${carbon.management.port}"
offset = 1
[super_admin]
username = "admin@wso2.com"
password = ""
create_admin_account = true

[authentication.jit_provisioning]
skip_username_pattern_validation = true

[user_store]
type = "database_unique_id"
user_name_attribute = "mail"
username_java_script_regex = '^[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$'
username_java_regex = '^[a-zA-Z0-9.-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}'

[keystore.primary]
file_name = "wso2carbon.jks"
password = ""
type="JKS"

[truststore]
file_name="client-truststore.jks"
password=""
type="JKS"

[account_recovery.endpoint.auth]
hash= "66cd9688a2ae068244ea01e70f0e230f5623b7fa4cdecb65070a09ec06452262"

[identity.auth_framework.endpoint]
app_password= "dashboard"

[database.identity_db]
type = "postgre"
hostname = "localhost"
name = ""
username = ""
password = ""
port = "5432"

[database.shared_db]
type = "postgre"
hostname = "localhost"
name = ""
username = ""
password = ""
port = "5432"

[[resource.access_control]]
context="(.*)/oauth2/authn(.*)"
secure=false
http_method = "all"

[fido.trusted]
origins=["https://localhost:9443", "https://localhost:8443"]

[output_adapter.email]
from_address= ""
username= ""
password= ""
hostname= "smtp.gmail.com"
port= 587
enable_start_tls= true
enable_authentication= true

JITIssue.webm

[mpmadhavig]

Closing the issue as this is not reproducible in latest IS pack.