7:17 a.m.
Hi,
as part of planned persistence storage SPI changes we talked about on
f2f we should probably consider removing of first name, last name and
email from UserModel property, but implement them as normal user
attributes with predefined names.
This unification should simplify few things, for example separate
mappers for attributes and properties in Clients and Identity Providers
configuration, which may be hard to understand for beginners (questions
like "what the hell is difference between user properties and
attributes?", "What user properties are available there?").
This should also simplify implementation of User profile validation SPI
we talked about on f2f meeting.
What do you think?
Vl.
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
7:36 a.m.
+1 Makes sense to me. Especially the part of not having two different
mappers. It could still be useful to have a get/set for common attributes,
but they would just pass through to attributes rather than separate fields.
On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias(a)redhat.com> wrote:
Hi,
as part of planned persistence storage SPI changes we talked about on
f2f we should probably consider removing of first name, last name and
email from UserModel property, but implement them as normal user
attributes with predefined names.
This unification should simplify few things, for example separate
mappers for attributes and properties in Clients and Identity Providers
configuration, which may be hard to understand for beginners (questions
like "what the hell is difference between user properties and
attributes?", "What user properties are available there?").
This should also simplify implementation of User profile validation SPI
we talked about on f2f meeting.
What do you think?
Vl.
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
8:29 a.m.
Yep, only small drawback may be that email uniqueness is checked and
users are searched by email for login by email address. These DB queries
will be a bit more complicated.
Vl.
On 18.3.2016 13:36, Stian Thorgersen wrote:
+1 Makes sense to me. Especially the part of not having two different
mappers. It could still be useful to have a get/set for common
attributes, but they would just pass through to attributes rather than
separate fields.
On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias(a)redhat.com
<mailto:velias@redhat.com>> wrote:
Hi,
as part of planned persistence storage SPI changes we talked about on
f2f we should probably consider removing of first name, last name and
email from UserModel property, but implement them as normal user
attributes with predefined names.
This unification should simplify few things, for example separate
mappers for attributes and properties in Clients and Identity
Providers
configuration, which may be hard to understand for beginners
(questions
like "what the hell is difference between user properties and
attributes?", "What user properties are available there?").
This should also simplify implementation of User profile
validation SPI
we talked about on f2f meeting.
What do you think?
Vl.
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
8:41 a.m.
+1 for have unified mapper for properties and attributes. That's very
easy to do, we can just fallback to setAttribute/getAttribute if there
is not property . LDAP UserAttribute mapper is already unified and is
doing like that.
Having the basic attributes in separate table might theoretically have
some performance impact. For example if email is stored as attribute,
then each searching by email needs to join 2 tables instead of one.
There is also DB constraint to enforce unique email. So maybe at least
email worth to keep as it is?
Marek
On 18/03/16 13:36, Stian Thorgersen wrote:
+1 Makes sense to me. Especially the part of not having two different
mappers. It could still be useful to have a get/set for common
attributes, but they would just pass through to attributes rather than
separate fields.
On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias(a)redhat.com
<mailto:velias@redhat.com>> wrote:
Hi,
as part of planned persistence storage SPI changes we talked about on
f2f we should probably consider removing of first name, last name and
email from UserModel property, but implement them as normal user
attributes with predefined names.
This unification should simplify few things, for example separate
mappers for attributes and properties in Clients and Identity
Providers
configuration, which may be hard to understand for beginners
(questions
like "what the hell is difference between user properties and
attributes?", "What user properties are available there?").
This should also simplify implementation of User profile
validation SPI
we talked about on f2f meeting.
What do you think?
Vl.
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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
8:46 a.m.
+1 Primary or "login" email should be left on user entity. We need to
consider how we're going to support having more than one email associated
with one account as well as multiple accounts with same email. I'd say we'd
have a login email, but also contact emails.
On 18 Mar 2016 2:41 p.m., "Marek Posolda" <mposolda(a)redhat.com> wrote:
+1 for have unified mapper for properties and attributes. That's
very easy
to do, we can just fallback to setAttribute/getAttribute if there is not
property . LDAP UserAttribute mapper is already unified and is doing like
that.
Having the basic attributes in separate table might theoretically have
some performance impact. For example if email is stored as attribute, then
each searching by email needs to join 2 tables instead of one. There is
also DB constraint to enforce unique email. So maybe at least email worth
to keep as it is?
Marek
On 18/03/16 13:36, Stian Thorgersen wrote:
+1 Makes sense to me. Especially the part of not having two different
mappers. It could still be useful to have a get/set for common attributes,
but they would just pass through to attributes rather than separate fields.
On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias(a)redhat.com> wrote:
> Hi,
>
> as part of planned persistence storage SPI changes we talked about on
> f2f we should probably consider removing of first name, last name and
> email from UserModel property, but implement them as normal user
> attributes with predefined names.
>
> This unification should simplify few things, for example separate
> mappers for attributes and properties in Clients and Identity Providers
> configuration, which may be hard to understand for beginners (questions
> like "what the hell is difference between user properties and
> attributes?", "What user properties are available there?").
>
> This should also simplify implementation of User profile validation SPI
> we talked about on f2f meeting.
>
> What do you think?
>
> Vl.
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing
listkeycloak-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
8:52 a.m.
More emails for one account are simple, you need one to be main for
login purposes and to be used to send "forgot pwd" and similar emails
to, we have it now. Rest emails may be just in common attribute (it
allows to store more values). Question is if you want to support
validation/verification process for these additional emails and consider
them in uniqueness tests ;-)
More accounts with same email is more tricky ;-)
Vl.
On 18.3.2016 14:46, Stian Thorgersen wrote:
+1 Primary or "login" email should be left on user entity. We need to
consider how we're going to support having more than one email
associated with one account as well as multiple accounts with same
email. I'd say we'd have a login email, but also contact emails.
On 18 Mar 2016 2:41 p.m., "Marek Posolda" <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
+1 for have unified mapper for properties and attributes. That's
very easy to do, we can just fallback to setAttribute/getAttribute
if there is not property . LDAP UserAttribute mapper is already
unified and is doing like that.
Having the basic attributes in separate table might theoretically
have some performance impact. For example if email is stored as
attribute, then each searching by email needs to join 2 tables
instead of one. There is also DB constraint to enforce unique
email. So maybe at least email worth to keep as it is?
Marek
On 18/03/16 13:36, Stian Thorgersen wrote:
>
> +1 Makes sense to me. Especially the part of not having two
> different mappers. It could still be useful to have a get/set for
> common attributes, but they would just pass through to attributes
> rather than separate fields.
>
> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias(a)redhat.com
> <mailto:velias@redhat.com>> wrote:
>
> Hi,
>
> as part of planned persistence storage SPI changes we talked
> about on
> f2f we should probably consider removing of first name, last
> name and
> email from UserModel property, but implement them as normal user
> attributes with predefined names.
>
> This unification should simplify few things, for example separate
> mappers for attributes and properties in Clients and Identity
> Providers
> configuration, which may be hard to understand for beginners
> (questions
> like "what the hell is difference between user properties and
> attributes?", "What user properties are available there?").
>
> This should also simplify implementation of User profile
> validation SPI
> we talked about on f2f meeting.
>
> What do you think?
>
> Vl.
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Vlastimil Elias
Principal Software Engineer
Developer Portal Engineering Team
10:32 a.m.
On 18 Mar 2016 14:52, "Vlastimil Elias" <velias(a)redhat.com> wrote:
More emails for one account are simple, you need one to be main for login
purposes
and to be used to send "forgot pwd" and similar emails to, we have
it now. Rest emails may be just in common attribute (it allows to store
more values). Question is if you want to support validation/verification
process for these additional emails and consider them in uniqueness tests
;-)
No need for uniqueness as long as it's not the login email. Might need
support in account so users can pick contact email to be used for email
flows. Verify email would be nice as well.
More accounts with same email is more tricky ;-)
Is it not just adding contact email as attribute? Then not having login
email?
Vl.
On 18.3.2016 14:46, Stian Thorgersen wrote:
>
> +1 Primary or "login" email should be left on user entity. We need to
consider how we're going to support having more than one email associated
with one account as well as multiple accounts with same email. I'd say we'd
have a login email, but also contact emails.
>
> On 18 Mar 2016 2:41 p.m., "Marek Posolda" <mposolda(a)redhat.com>
wrote:
>>
>> +1 for have unified mapper for properties and attributes. That's very
easy to do, we can just fallback to setAttribute/getAttribute if there is
not property . LDAP UserAttribute mapper is already unified and is doing
like that.
>>
>> Having the basic attributes in separate table might theoretically have
some
performance impact. For example if email is stored as attribute, then
each searching by email needs to join 2 tables instead of one. There is
also DB constraint to enforce unique email. So maybe at least email worth
to keep as it is?
>>
>> Marek
>>
>>
>> On 18/03/16 13:36, Stian Thorgersen wrote:
>>>
>>> +1 Makes sense to me. Especially the part of not having two different
mappers. It could still be useful to have a get/set for common attributes,
but they would just pass through to attributes rather than separate fields.
>>>
>>> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias"
<velias(a)redhat.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> as part of planned persistence storage SPI changes we talked about on
>>>> f2f we should probably consider removing of first name, last name and
>>>> email from UserModel property, but implement them as normal user
>>>> attributes with predefined names.
>>>>
>>>> This unification should simplify few things, for example separate
>>>> mappers for attributes and properties in Clients and Identity
Providers
>>>> configuration, which may be hard to understand for
beginners
(questions
>>>> like "what the hell is difference between user
properties and
>>>> attributes?", "What user properties are available
there?").
>>>>
>>>> This should also simplify implementation of User profile validation
SPI
>>>> we talked about on f2f meeting.
>>>>
>>>> What do you think?
>>>>
>>>> Vl.
>>>>
>>>> --
>>>> Vlastimil Elias
>>>> Principal Software Engineer
>>>> Developer Portal Engineering 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
Developer Portal Engineering Team
8:47 a.m.
+1 to keep email directly in user as it has additional logic (but unify
it in mappers to have only one), but move name fields away as they are
just common attributes without additional logic. Some instances may even
work without them.
Vl.
On 18.3.2016 14:41, Marek Posolda wrote:
+1 for have unified mapper for properties and attributes. That's
very
easy to do, we can just fallback to setAttribute/getAttribute if there
is not property . LDAP UserAttribute mapper is already unified and is
doing like that.
Having the basic attributes in separate table might theoretically have
some performance impact. For example if email is stored as attribute,
then each searching by email needs to join 2 tables instead of one.
There is also DB constraint to enforce unique email. So maybe at least
email worth to keep as it is?
Marek
On 18/03/16 13:36, Stian Thorgersen wrote:
>
> +1 Makes sense to me. Especially the part of not having two different
> mappers. It could still be useful to have a get/set for common
> attributes, but they would just pass through to attributes rather
> than separate fields.
>
> On 18 Mar 2016 1:17 p.m., "Vlastimil Elias" <velias(a)redhat.com
> <mailto:velias@redhat.com>> wrote:
>
> Hi,
>
> as part of planned persistence storage SPI changes we talked about on
> f2f we should probably consider removing of first name, last name and
> email from UserModel property, but implement them as normal user
> attributes with predefined names.
>
> This unification should simplify few things, for example separate
> mappers for attributes and properties in Clients and Identity
> Providers
> configuration, which may be hard to understand for beginners
> (questions
> like "what the hell is difference between user properties and
> attributes?", "What user properties are available there?").
>
> This should also simplify implementation of User profile
> validation SPI
> we talked about on f2f meeting.
>
> What do you think?
>
> Vl.
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org <mailto:keycloak-dev@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
Developer Portal Engineering Team
2975
days inactive
2975
days old
7 comments
3 participants
participants (3)
-
Marek Posolda -
Stian Thorgersen -
Vlastimil Elias