[keycloak-dev] Profile SPI

[Marek Posolda]

On 16/03/17 14:35, Stian Thorgersen wrote:
>
>
> On 16 March 2017 at 13:08, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     On 16/03/17 11:34, Stian Thorgersen wrote:
>>
>>
>>     On 14 March 2017 at 12:21, Marek Posolda <mposolda at redhat.com
>>     <mailto:mposolda at redhat.com>> wrote:
>>
>>         Few things:
>>         - It will be good to have some OOTB support for multivalued
>>         attributes. You will be able to define if attribute is
>>         multivalued and then in registration/account pages, users
>>         will see something like we have in admin console for
>>         "redirect uris" or "web origins" in client detail page.
>>
>>
>>     Any multi valued attributes would have to be done through custom
>>     extension to the account management console and login pages. The
>>     built-in properties we'll provide just don't need multi values
>>     (first name, dob, etc..)
>     I guess it is not big priority, but IMO it will be useful to have
>     some built-in support for multivalued attributes. I know some
>     people from community asked for it. You can have more mobile
>     phones, you can have more children etc :)
>
>
> Sure we can have built-in support for multiple values - but those 
> would require custom forms IMO.
We already have that at model level and at mappers level. The UI is the 
only missing piece, which we don't have. Which I was thinking that 
profile SPI can help with.

Anyway, it all depends on priorities. Maybe we can just await feedback 
from community/customers and add that later. Not sure...
>
>
>     We can require them to always override theme if they need
>     multivalued support in UI, but if we can have something OOTB it
>     would be nice IMO.
>>
>>
>>         - Besides validation, it may be useful to add some "actions"
>>         when attribute is changed? For example if user changes email,
>>         there will be the optional action, which will switch
>>         "emailVerified" to false and put the "VerifyEmail" required
>>         action on him. When he changes mobile number, it will send
>>         him SMS and he will need to confirm it somehow (perhaps again
>>         through required action), etc.
>>
>>
>>     Yes, not quite sure how to do that though. There's a few built-in
>>     providers we'd like (make email not verified if changed, etc.),
>>     but users should also be able add their own.
>>
>>
>>         - It will be probably useful to allow admin to skip
>>         validation (and actions) for certain attributes. Maybe
>>         validators could have an option like "Skip admin" or
>>         something like that? Or should we always skip the validations
>>         for admin?
>>
>>
>>     Dunno - why should an admin be allowed to bypass validation?
>>     Validation is there to make sure the details in the DB is accurate.
>     Not sure. Currently the fields like firstName/lastName/email are
>     mandatory for users, but not for admins. I can think of some
>     corner cases.
>
>
> True - maybe just have an option on admin console/endpoints to skip 
> validation?
+1
>
>
>     For example: User was registered through Twitter identityProvider
>     and hence he doesn't have email filled. Now admin won't be able to
>     edit the user unless he fills some fake email.
>
>
> I agree that would be annoying for the admin.
>
> In that case it would be nice to detect "missing properties" and popup 
> the update profile form for the user to require the user to fill in 
> missing properties.
Yeah, requiredActions already have "evaluateTriggers", which is 
triggered at every login. So doing this will be quite easy though.

Marek
>
>
>
>     Marek
>
>>
>>
>>         Marek
>>
>>
>>
>>         On 14/03/17 10:13, Stian Thorgersen wrote:
>>
>>             At the moment there is no single point to define
>>             validation for a user.
>>             Even worse for the account management console and admin
>>             console it's not
>>             even possible to define validation for custom attributes.
>>
>>             Also, as there is no defined list of attributes for a
>>             user there the
>>             mapping of user attributes is error prone.
>>
>>             I'd like to introduce a Profile SPI to help with this. It
>>             would have
>>             methods to:
>>
>>             * Validate users during creation and updates
>>             * List defined attributes on a user
>>
>>             There would be a built-in provider that would delegate to
>>             ProfileAttribute
>>             SPI. ProfileAttribute SPI would allow defining
>>             configurable providers for
>>             single user attributes. I'm also considering adding a
>>             separate Validation
>>             SPI, so a ProfileAttribute provider could delegate
>>             validation to a separate
>>             validator.
>>
>>             Users could also implement their own Profile provider to
>>             do whatever they
>>             want. I'd like to aim to make the SPI a supported SPI.
>>
>>             First pass would focus purely on validation. Second pass
>>             would focus on
>>             using the attribute metadata to do things like:
>>
>>             * Have dropdown boxes in mappers to select user attribute
>>             instead of
>>             copy/pasting the name
>>             * Have additional built-in attributes on registration
>>             form, update profile
>>             form and account management console that can be
>>             enabled/disabled by
>>             defining the Profile. I'm not suggesting a huge amount
>>             here and it will be
>>             limited to a few sensible attributes. Defining more
>>             complex things like
>>             address would still be done through extending the forms.
>>             _______________________________________________
>>             keycloak-dev mailing list
>>             keycloak-dev at lists.jboss.org
>>             <mailto:keycloak-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>             <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>>
>>
>>
>>
>
>