[keycloak-dev] Custom attributes on registration and account management

[Stian Thorgersen]

Password policies needs to be made into an SPI as well

On 6 November 2015 at 15:23, Stian Thorgersen <sthorger at redhat.com> wrote:

> You're right validation is required now. I feel a new Validation SPI
> coming up?
>
> On 6 November 2015 at 15:21, Marek Posolda <mposolda at redhat.com> wrote:
>
>> Sure, if it's not a blocker for jboss.org team to not have it in 1.0 ? I
>> guess dynamic templates can be postponed, but at least missing validation
>> for account mgmt and update profile is quite a gap IMO.
>>
>> I've discussed this with Vlasta a week or two ago (and that's one of main
>> reasons to write this email btv :-) )
>>
>> Marek
>>
>>
>> On 06/11/15 15:04, Stian Thorgersen wrote:
>>
>> I think this is something to look at next year. We don't have the
>> resources to do it properly now. My vote is to add it to the agenda for F2F.
>>
>> On 6 November 2015 at 14:36, Marek Posolda <mposolda at redhat.com> wrote:
>>
>>> On 05/11/15 17:11, Bill Burke wrote:
>>> >
>>> > On 11/5/2015 5:46 AM, Marek Posolda wrote:
>>> >> I wonder if we should improve handling of custom attributes in
>>> >> freemarker templates and their validation. Let's assume that I want to
>>> >> add custom attribute "birthday" and I want to add it to all screens
>>> >> where user can create/edit account. I can see those issues:
>>> >>
>>> >> - Admin will need to edit 3 separate freemarker templates
>>> (registration,
>>> >> account management, update profile page) to have this attribute
>>> >> displayed on all those places.
>>> >>
>>> > we've discussed this before. The problem is formatting in each of the
>>> > UIs. Often ordering of attributes is important. Grouping of attributes
>>> > is a must too.
>>> >
>>> > i.e. Address, State, Country, Postal Code
>>> >
>>> > These 4 attribute must be grouped together, and address must come
>>> before
>>> > state, and so on.
>>> >
>>> > You might also have a "Billing Address" group that needs to come after
>>> > Home Address group.
>>> I am not seeing an issue with ordering? The same order you configure in
>>> admin console, the same is used in template. It's classic sorted list,
>>> not special tricks needed IMO. The grouping some attributes can be
>>> easily addressed too IMO.
>>> >
>>> > So, we'd have an automatic way for displaying attributes, then the
>>> > developer would think "that looks like shit" and want to format things
>>> > himself.  Stian seems to think that CSS will solve this problem, but
>>> I'm
>>> > not convinced.
>>>
>>
>> CSS can do a hell of a lot more than you think it can ;)
>>
>> But, I agree it can't always cover everything - that's why I've been
>> saying we need to be able to define templates, but at a smaller
>> granularity. Having to define the whole update-profile page just to add an
>> attribute is not very elegant.
>>
>>
>>> I agree we can't address all possible sort of issues, but IMO it's good
>>> to have something, which will address 90% of cases? We can provide types
>>> (like combobox "Gender" with values "male" / "female" ). We can also
>>> handle multivalued attributes. And most importantly we can provide
>>> validations for all 3 screens. People won't need to write their own Java
>>> validators when they want something simple like ensure "mandatory" field
>>> present or validate with regex. They will still have possibility to
>>> inject the custom validator if they want it.
>>>
>>> At least validation is must IMO as there is no way to add custom
>>> validation for account mgmt or update profile right now.
>>>
>>> What we can't easily do is client-side validation and stuff for
>>> display/hide something based on value of other attributes (For example
>>> display attribute "Favourite car sign" just if selected gender is "male"
>>> ). But not sure if this is often requirement.
>>>
>>> I am seeing lot of similarity with your kc-provider-config directive in
>>> admin console. It can't address all "generic" sort of things and
>>> client-side stuff etc. But for most cases, it's sufficient.
>>> >
>>> > Also the look and feel could be quite different between registration,
>>> > update profile, account management, and the admin profile.  IMO, it
>>> > would end up being easier to just edit the freemarker pages directly
>>> > than to have to define each attribute and how it is grouped, ordered,
>>> > and displayed on each of the pages within an admin console UI.
>>> >
>>> >
>>> There could be 3 checkboxes where can admin select if he wants to add
>>> field on registration, account mgmt and update profile. I am not sure if
>>> we need anything for admin console as we already have "Attributes" tab
>>> for users, which is almost ok IMO (we don't have nice solution for
>>> multivalued attributes).
>>>
>>> Marek
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151106/5a7ef65f/attachment-0001.html