You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the issue:
The JIT provisioning handler always use the external user's subject identifier when creating an association with a local user. This creates an inconsistency with the adaptive authentication doAssociationWithLocalUser function which could lead to creating two association records in IDN_ASSOCIATED_ID table.
How to reproduce:
Configure a connector and set an attribute mapping to use as subject identifier (i.e. FederatedIDP send an UUID as the subject but the connector is configed use email address as the subject)
Enable JIT provisioning with consent.
Create an application and add the connection created in step 1 as the first login step.
Add the following adaptive authentication script (which checks if there’s a local user with the same email address and associates that user with the federated user):
var onLoginRequest = function (context) {
executeStep(1, {
onSuccess: function (context) {
var fedUser = context.currentKnownSubject;
var assocUser = getAssociatedLocalUser(fedUser);
if (assocUser == null) {
var claimMap = {};
claimMap["http://wso2.org/claims/emailaddress"] = fedUser.remoteClaims["email"];
var localUser = getUniqueUserWithClaimValues(claimMap, context);
if (localUser) {
Log.info("============== Local Username: " + localUser.username);
var userStoreDomain = localUser.userStoreDomain;
var localUsersEmail = localUser.localClaims["http://wso2.org/claims/emailaddress"];
Log.info("============== Local email: " + localUsersEmail);
doAssociationWithLocalUser(fedUser, localUser.username, "carbon.super", userStoreDomain);
} else {
Log.info("============== Local user not found");
}
}
}
});
}
Create a local user with the same email address as federated IDP user.
Log in to the application using the connection with the user who has the same email address as the locally created user.
The adaptive authentication script will associate the federated user with the local user created in step 5.
The consented JIT provisioning screen will appear, and if the user completes the fields (e.g., password), a new user will be created.
Expected behavior:
If the adaptive authentication script creates an association with a local user, JIT provisioning flow should not trigger again.
Environment information:
Product Version: 7.0.0
With the improvment done in [1][2], adaptive authentication scripts are using the subject identifier configured in the connection for association. But the JIT provisioning handler still using the federated user's subject identifer.
Describe the issue:
The JIT provisioning handler always use the external user's subject identifier when creating an association with a local user. This creates an inconsistency with the adaptive authentication
doAssociationWithLocalUser
function which could lead to creating two association records inIDN_ASSOCIATED_ID
table.How to reproduce:
Expected behavior:
If the adaptive authentication script creates an association with a local user, JIT provisioning flow should not trigger again.
Environment information:
With the improvment done in [1][2], adaptive authentication scripts are using the subject identifier configured in the connection for association. But the JIT provisioning handler still using the federated user's subject identifer.
[1] - #11586
[2] - wso2-extensions/identity-conditional-auth-functions#68
The text was updated successfully, but these errors were encountered: