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(a)redhat.com>
> To: "Vlastimil Elias" <velias(a)redhat.com>
> 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>
>> 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