[keycloak-dev] Profile SPI
mposolda at redhat.com
Thu Mar 16 10:58:06 EDT 2017
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
> 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.
>> 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
>> 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
>> 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>
More information about the keycloak-dev