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

Wed Mar 11 08:41:39 EDT 2015

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.

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 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?

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.

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 at redhat.com>
>> To: "Vlastimil Elias" <velias at redhat.com>
>> Cc: keycloak-dev at 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 at redhat.com>
>>> To: keycloak-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team