Re: [keycloak-dev] Improvements of registration over Social Login providers

----- Original Message ----- > From: "Vlastimil Elias" <velias(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Wednesday, 11 March, 2015 1:41:39 PM > Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers > > Hi > > I see your points and understand them if you take KC as primary system > for identity. > > But things change a bit if you use UserFederationProvider SPI and > primary user database is some other backend, and KC is used primarily to > add some missing features (eg social logins, modern SSO protocols) at > top of this backend. I'm in this position and I have to propagate new > users to the backend (even one created due social login) and must > reflect some constraints from the backend (like username must be email > in my case). > > Feature proposal from point 1 is not critical for me, I think it should > be useful for some KC installations to be able to disable social > registrations, but I do not need it, so we can let it be. If you don't need it I suggest we don't add it, as we haven't had anyone else request it.

> Feature proposal 2 is more important for me. > I need email to be used as username in KC due my backend restrictions, > so I implemented some basic solution as part of KEYCLOAK-1074 pull > request. If you accept it and keep it in the code then I can use KC for > my project (or we have to find some other solution, eg some extension of > UserFederationProvider SPI to allow it to select username in case of > social registration). > > But this solution is only partial and I want to help you make KC > generally better for all use cases, so I did this proposal. I appreciate it, but if possible IMO it would be better to make it work by default rather than introducing configuration options.

> I also think that current way how KC reuses username from social > providers is wrong as it may prevent some users from login, so what to > do with this? Create a bug in JIRA? Agree - using username from social providers isn't a good approach. > But I don't think solution with some randomly generated username, which > will be changed later, is a good one. > This may bring problems to other systems which use KC for SSO and store > data related to users. They typically rely on usernames to store these > data, but change of username in KC may break data integrity (hide data > for the user who changed username). How do you plan to prevent those > problems if you implement username change in KC? > > I understand that correct solution should be using 'User ID' in these > systems instead of username, but I fear it is not possible in many cases. > From my experience integration of existing applications like Atlassian > JIRA into SSO system may be problematic in this area, you are forced to > use usernames there, username changes are typically a problem. > So I think that username changes should be possible in KC for systems > who need it, but no any important feature like social registrations > should rely on them so heavily. Yeah, you're right we need a solution to this that doesn't require allowing usernames to be changed. How about: 1. We allow username to be null and users created through social login has a null username - this would change the login with email only feature you're implementing slightly 2. We add validation support to user profiles and if any required attributes are missing the user is required to add the missing attributes on login (before redirecting to application) 3. We add a require username/password option on social login - if this is enabled the user will have to add a username/password on first login. If not enable the same feature will be available through account management. In your use-case it would work by: * On social login if user is missing email (for example twitter) the user is shown a insert your email form as email would be marked as required. This would also work if you need other required attributes that are not available from social, for example a DOB * In the case of applications that require a username you can use the new claim mapping feature to map email to the username claim, or just make sure the application uses the email claim

> Thanks > > Vlastimil > > On 11.3.2015 11:30, Stian Thorgersen wrote: >> We can also add some more required actions: >> >> * Set email if missing >> * Set username/password >> >> It would then be possible to set one or more required actions for a first >> social login. >> >> ----- Original Message ----- >>> From: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> To: "Vlastimil Elias" <velias(a)redhat.com&gt; >>> Cc: keycloak-dev(a)lists.jboss.org >>> Sent: Wednesday, 11 March, 2015 11:24:53 AM >>> Subject: Re: [keycloak-dev] Improvements of registration over Social Login >>> providers >>> >>> >>> >>> ----- Original Message ----- >>>> From: "Vlastimil Elias" <velias(a)redhat.com&gt; >>>> To: keycloak-dev(a)lists.jboss.org >>>> Sent: Wednesday, 11 March, 2015 10:45:06 AM >>>> Subject: [keycloak-dev] Improvements of registration over Social Login >>>> providers >>>> >>>> Hi great Keycloak dev team, >>>> >>>> during implementation of https://issues.jboss.org/browse/KEYCLOAK-1074 I >>>> found few things which should be improved in area of registration over >>>> Social Login providers. >>>> I'd like to discuss them here before creating JIRAs. I believe I should >>>> implement these changes if you will be interested. >>>> >>>> 1. It is not possible to disable registration over Social provider >>>> ====================================== >>>> Once provider is created then it is always possible to register over it, >>>> even >>>> if "User registration" is disabled in realm "Login Settings". I think it >>>> should be possible to disable social registrations and allow only to link >>>> social logins to existing accounts (eg. loaded from other system). >>>> >>>> Marek Posolda pointed me to https://issues.jboss.org/browse/KEYCLOAK-1036 >>>> which is rejected without any comment. I understand that this global >>>> setting >>>> is probably not a good solution, so my proposal is to add independent >>>> "User >>>> registration" switch into configuration of each Identity provider, so >>>> admin >>>> will get fine grained control. >>> -1 >>> >>> IMO when you add a identity broker (or social provider) you are allowing >>> all >>> those users to login. When a user logs in the first time using a identity >>> broker we're not really registering the user, just creating an internal >>> representation. >>> >>>> 2. Username from Social provider is used as Keycloak username during >>>> registration >>>> =================================================== >>>> This can lead to the situation that user registering eg. over Twitter >>>> will >>>> not be able to register as other user eg. from Facebook will use same >>>> username there and occupy it in Keycloak as first. >>>> My proposal is to extend configuration of each Identity provider by new >>>> option "Username type" which will be select from these options: >>>> >>>> >>>> * provided username exact - works as now, username is got from >>>> provider, >>>> user can't register if occupied in KC already >>>> * provided username unique - KC will take username from provider, if >>>> occupied then it adds some random number to it to create unique >>>> username >>>> and allow user to register >>>> * provided email - this is related to KEYCLOAK-1074, I need this >>>> option >>>> for my project. I know that email is not provided by some providers >>>> (eg >>>> Twitter) so I can't use them until KEYCLOAK-1053 is resolved somehow >>>> >>>> So let me know what you think about my proposals, can I implement them? >>> -1 >>> >>> If it's using the username from the identity provider that's not correct, >>> it >>> should just be set to something unique (could be set to same as user id), >>> that's how it used to be before the identity brokering was introduced. >>> >>> We have an open issue to allow users to change their username. This would >>> then be used by a user that wants to enable regular logins in the above >>> scenario. We could improve the account management around this, for example >>> it should not display username if it's the same as user id, but have an >>> option for a user to "enable regular login" by providing a username and >>> password. >>> >>>> Cheers >>>> >>>> Vlastimil >>>> >>>> -- >>>> Vlastimil Elias >>>> Principal Software Engineer >>>> jboss.org Development Team >>>> >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> > -- > Vlastimil Elias > Principal Software Engineer > jboss.org Development Team > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >