Yes, that makes sense.In the way I use the admin client, I created a challenge in my application. Every time someone logs in, I simply check delegate that attempt to Keycloak. I won't know if the user was deleted and recreated in the mean time. Pretty likely, the credentials will have changed, but that's not a good indicator to determine if the user attributes that I store in my app should be purged.For now, all user management will be done in my app (propagating all changes to Keycloak), but at some point, this is going to hurt me...On 12 April 2016 at 09:04, Stian Thorgersen <sthorger@redhat.com> wrote:BTW this is main reason token subject is User ID not username, to guarantee uniqueness over time.On 12 April 2016 at 09:03, Stian Thorgersen <sthorger@redhat.com> wrote:On 12 April 2016 at 08:58, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:Hmm... that rename route is disabled by default though?YesAlso, when deleting a user, are we guaranteed that all user artifacts are removed? I'd hate to see another user (years later) have access to things simply because he picked a previously used name. Then again, most artifacts (if not all) will probably be linked through the ID, not username.Everything in Keycloak is linked through ID, not username. Obviously you may use username in your app rather than ID, in which case that may be a problem in your app. In that case you should probably disable a decommissioned user rather than disable or change your app.On 12 April 2016 at 06:32, Stian Thorgersen <sthorger@redhat.com> wrote:There's an option to enable users to change their username. Enabling that could result in a user renaming the username, then another user taking the same username. There's also the situation where a user with a specific username is deleted, then another user is created with the same username (maybe years after).On 12 April 2016 at 01:31, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:Thanks for the feedback, Niels,I am primarily concerned about the email address, but as another attribute than the username is used to identify things, I thought I'd make sure and include that in the question too.At some point, my customer will probably want non-unique email addresses. It's good to know it's at least on the roadmap.Regards,GuusOn 12 April 2016 at 00:50, Niels Bertram <nielsbne@gmail.com> wrote:Hi Guus,I can't see how you could manage non-uniqueness of the username as you will need at least one user side unique identifier to drive forget password flow. But the option to have email non-unique has been discussed a while back in the user forum and there is this open Jira https://issues.jboss.org/browse/KEYCLOAK-2141.We have been looking at non-unique emails and essentially one will have to remove the functionality of using email as a form of login from the login flow leaving the user to only be able to use their assigned or selected username as option. We have been trying to "hack" the codebase a bit but have not been too successful in getting keycloak to work properly with non-unique emails :( ...Cheers,NielsOn Tue, Apr 12, 2016 at 3:08 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:_______________________________________________Hello,Keycloak uses a UUID value to identify a uses. Basic questions: through some form of configuration:
- Can more than two users exist that have an identical username?
- Can more than two users exist that have an identical email address?
Regards,Guus
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user