[keycloak-dev] Profile SPI

[Marek Posolda]

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 :)

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.

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.

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>
>
>
>
>