[keycloak-dev] Profile SPI

Stian Thorgersen sthorger at redhat.com
Thu Mar 16 09:35:10 EDT 2017


On 16 March 2017 at 13:08, Marek Posolda <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> 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 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?


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


>
>
> 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
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>
>>
>>
>
>


More information about the keycloak-dev mailing list