Hey guys,
Just a remark on the idea of relaxing the email uniqueness requirement since Marek asked
if there was a good use case. In my organization, we are using Active Directory as the
federation provider and there is no easy way to enforce email uniqueness natively in AD.
For various reasons, we have some users being created directly in AD by another team
within our organization and they routinely create users that have the same email address.
Our customers apparently want some generic organization accounts with generic organization
email addresses. It has actually been one of the biggest pain points for us and our use of
Keycloak since we have to manually resolve the issue when it happens. I personally
strongly prefer that the emails are unique because it makes things simpler throughout our
internal application, but not having the option to relax this requirement has been a bit
of a hassle for us with Active Directory and account registrations that occur outside of
Keycloak.
Cory Snyder
software engineer
USA +1.419.731.3479 UK +44.20.7096.0149
iland.com<http://www.iland.com/>
On Oct 7, 2015, at 7:28 AM, Marek Posolda
<mposolda@redhat.com<mailto:mposolda@redhat.com>> wrote:
On 06/10/15 09:50, Stian Thorgersen wrote:
We've have someone from the community that wants to use mobile number as the username,
as well as verify mobile number by sending a code via SMS. See "Login by mobile
number" thread in user mailing list for more details. They are also willing to
contribute this back to the community.
That made me think it may be nice to be able to configure the behavior of the username
"field" for a realm. We could have a simple drop-down in the admin console to
configure username mode, with the following options:
* Username/email - default behavior where a user provides both a username and email, and
the user can login with either. In this mode email has to be unique.
* Username - a user can only login with a username. In this mode we could relax the
requirement that email has to be unique (that may be difficult though as it would require
not using a database constraint, which may make it rather difficult to guarantee
uniqueness in other modes)
Even if we add the option, I wouldn't remove email uniqueness. Admin can decide to
change the mode back to "Username" to "Email" and then some users
won't be able to login due to many users with same email. Also is there usecase when
there are 2 different users in realm with same email?
* Email - in this mode only email can be used to login. In this mode username field would
not be displayed on the registration form or account management console. In the token the
username would be set to email. In this mode verify email address should be enabled by
default.
* Mobile - user logs in with a mobile number. We can either just add mobile number to the
username field or add a new mobile field and require uniqueness on that field. In this
mode verify mobile number should be enabled by default.
For the "Mobile" support, isn't an option to remove default
username/password Authenticator and add new Authenticator based on mobile number? Also
registration screen can be customized and account management as well. Also user can
already use protocol mapper to map "mobile_number" attribute to
"preferred_username" or whatever he wants into access token.
TBH advantages of introducing new option are bit unclear to me. It looks like adding
another complexity, which is not needed as authentication with mobile can be done with the
SPIs we have now IMO.
Marek
With regards to implementation I think it would be easier to make the existing
username/password authenticator, registration form and account management adopt to the
mode rather than have separate authenticators, etc.. for each mode.
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org<mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev