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

From: "Vlastimil Elias" <velias(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Friday, March 13, 2015 11:50:36 AM Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers Hi, On 12.3.2015 10:36, Stian Thorgersen wrote: > > ----- 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. I agree > >> 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. Sure, I agree with this also. Use reasonable default if possible, not to add config options for everything. But if we have some more special requirements for our project which can't be solved by reasonable default, we have only few ways how to add them (as we can't fork KC for our project): - add common config option into admin app - reasonable if they can fit for more general use - add some hidden config option (eg. in keycloak.json) - reasonable if this option is raare use - find some other customization solution like extension of some SPI or so

> >> 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 null username is a bit courageous proposal, I'm not sure keycloak can live with it without any big rewrites of the code.

Some sensible default username should be used there I think (take it from social provider if it is free, try to prepare some unique if it is occupied in KC already). Or we can ask user to input his username, but it is less user friendly as it requires some user interaction (so finally we can do this as configurable option how system will behave ;-).

Our use of email as username is a bit more complicated as we use UserFedaretionProvider SPI with synchronizeRegistrations() enabled - we have to create user in backend system when it is created in KC, and we have to use email as username there. So claim mapping for client applications is not useful for us. Problem is that KC now provides only "after first login" user actions/screens which may be a bit late as account is created in KC already. I'll look at this problem a bit deeper in next few days and try to suggest some sensible solution. See also https://issues.jboss.org/browse/KEYCLOAK-1053

Cheers Vl. >> 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 >> -- Vlastimil Elias Principal Software Engineer jboss.org Development Team