----- Original Message -----
From: "Vlastimil Elias" <velias(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Sent: Friday, March 13, 2015 11:50:36 AM
Subject: Re: [keycloak-dev] Improvements of registration over Social Login providers
On 12.3.2015 10:36, Stian Thorgersen wrote:
> ----- Original Message -----
>> From: "Vlastimil Elias" <velias(a)redhat.com>
>> 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
>> 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
> 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.
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 don't like the idea of adding hidden things directly to Keycloak, if it's common
we can add it directly, if not it should be added through an SPI/extension-point. We can
rather work on adding more extension points, than hidden 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
null username is a bit courageous proposal, I'm not sure keycloak can
live with it without any big rewrites of the code.
Keycloak can live perfectly fine with a null username, it's just db constraints that
would prevent it.
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 ;-).
Setting it to username from social provider if free is fine. If it's not then we can
either set it to null or even easier would be to set it to users id as it wouldn't
require any changes elsewhere. We can then introduce an option to require user to specify
username if it's null or same as user id.
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
We have to create the user internally in Keycloak as we need to persist it somewhere. In
your UserFedaretionProvider you could create the user in register if the email is set,
otherwise you could wait until the email is set (and verified perhaps?!).
>> 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
>>>> ----- 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
>>>>> Hi great Keycloak dev team,
>>>>> during implementation of
>>>>> found few things which should be improved in area of registration
>>>>> Social Login providers.
>>>>> I'd like to discuss them here before creating JIRAs. I believe I
>>>>> 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
>>>>> if "User registration" is disabled in realm "Login
Settings". I think
>>>>> should be possible to disable social registrations and allow only
>>>>> social logins to existing accounts (eg. loaded from other system).
>>>>> Marek Posolda pointed me to
>>>>> which is rejected without any comment. I understand that this
>>>>> is probably not a good solution, so my proposal is to add
>>>>> registration" switch into configuration of each Identity
>>>>> will get fine grained control.
>>>> IMO when you add a identity broker (or social provider) you are
>>>> those users to login. When a user logs in the first time using a
>>>> broker we're not really registering the user, just creating an
>>>>> 2. Username from Social provider is used as Keycloak username
>>>>> This can lead to the situation that user registering eg. over
>>>>> not be able to register as other user eg. from Facebook will use
>>>>> username there and occupy it in Keycloak as first.
>>>>> My proposal is to extend configuration of each Identity provider by
>>>>> option "Username type" which will be select from these
>>>>> * provided username exact - works as now, username is got
>>>>> user can't register if occupied in KC already
>>>>> * provided username unique - KC will take username from
>>>>> occupied then it adds some random number to it to create
>>>>> and allow user to register
>>>>> * provided email - this is related to KEYCLOAK-1074, I need
>>>>> for my project. I know that email is not provided by some
>>>>> Twitter) so I can't use them until KEYCLOAK-1053 is
>>>>> So let me know what you think about my proposals, can I implement
>>>> If it's using the username from the identity provider that's
>>>> should just be set to something unique (could be set to same as user
>>>> that's how it used to be before the identity brokering was
>>>> We have an open issue to allow users to change their username. This
>>>> 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
>>>> it should not display username if it's the same as user id, but have
>>>> option for a user to "enable regular login" by providing a
>>>>> Vlastimil Elias
>>>>> Principal Software Engineer
>>>>> keycloak-dev mailing list
>>>> keycloak-dev mailing list
>> Vlastimil Elias
>> Principal Software Engineer
>> keycloak-dev mailing list
Principal Software Engineer