handling duplicatemodel in direct grant authentication flow
by Vyedyeneyev, Andriy (AMOS Austria GmbH)
Hello,
I will start with a short background. We have requirement to support accounts with duplicated email, so in that case user should be notified to use username as credential to login.
So far we have no problems with it while using login form for webapp we have used browser authentication flow, and there UserNameFormValidator handles it this way:
UserModel user = null;
try {
user = KeycloakModelUtils.findUserByNameOrEmail(context.getSession(), context.getRealm(), username);
} catch (ModelDuplicateException mde) {
ServicesLogger.LOGGER.modelDuplicateException(mde);
// Could happen during federation import
if (mde.getDuplicateFieldName() != null && mde.getDuplicateFieldName().equals(UserModel.EMAIL)) {
setDuplicateUserChallenge(context, Errors.EMAIL_IN_USE, Messages.EMAIL_EXISTS, AuthenticationFlowError.INVALID_USER);
} else {
setDuplicateUserChallenge(context, Errors.USERNAME_IN_USE, Messages.USERNAME_EXISTS, AuthenticationFlowError.INVALID_USER);
}
return false;
}
With a new requirement we are handling login inside Mobile App, and we are using direct-grant instead browser authentication flow. At this point we have troubles with response code, since ValidateUsername implemented this way
UserModel user = null;
try {
user = KeycloakModelUtils.findUserByNameOrEmail(context.getSession(), context.getRealm(), username);
} catch (ModelDuplicateException mde) {
logger.error(mde.getMessage(), mde);
Response challengeResponse = errorResponse(Response.Status.UNAUTHORIZED.getStatusCode(), "invalid_request", "Invalid user credentials");
context.failure(AuthenticationProcessor.Error.INVALID_USER, challengeResponse);
return;
}
Well I have reported this as bug, but seems like it's working as designed, with a reason "We do not want to leak if a username or email is linked to a real user or not.".
So my point is we need consistent error handling behavior independent which flow browser/direct-grant/something-else client using. The intruder can link response body {"invalid_request": "Invalid user credentials"} to this error anyway, so there is no point to use cryptic response codes here.
I would like to hear from you arguments against my proposal, many thanks in advance :)
Kind regards,
Andriy Vyedyeneyev
AMOS Austria GmbH
1130 Wien, Hietzinger Kai 101-105
FN 365014k, Handelsgericht Wien
UID: ATU 66614737
http://www.allianz.at
********************************************************
Dieses E-Mail und allfaellig daran angeschlossene Anhaenge
enthalten Informationen, die vertraulich und
ausschliesslich fuer den (die) bezeichneten Adressaten
bestimmt sind.
Wenn Sie nicht der genannte Adressat sind, darf dieses
E-Mail samt allfaelliger Anhaenge von Ihnen weder anderen
Personen zugaenglich gemacht noch in anderer Weise
verwertet werden.
Wenn Sie nicht der beabsichtigte Empfaenger sind, bitten
wir Sie, dieses E-Mail und saemtliche angeschlossene
Anhaenge zu loeschen.
Please note: This email and any files transmitted with it is
intended only for the named recipients and may contain
confidential and/or privileged information. If you are not the
intended recipient, please do not read, copy, use or disclose
the contents of this communication to others and notify the
sender immediately. Then please delete the email and any
copies of it. Thank you.
********************************************************
