10:13 a.m.
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.
10:40 a.m.
+1
OIDC standard claims seem like a great set of attributes to start with.
Perhaps out of scope, but unique attribute values per user would be really
nice. A generic way to add more identifiers to users.
On Tue, 14 Mar 2017 at 10:14 Stian Thorgersen <sthorger(a)redhat.com> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
10:59 a.m.
On 14 March 2017 at 10:40, Martin Hardselius <martin.hardselius(a)gmail.com>
wrote:
+1
OIDC standard claims seem like a great set of attributes to start with.
Perhaps out of scope, but unique attribute values per user would be really
nice. A generic way to add more identifiers to users.
That's far from trivial to add since it can't be guaranteed without a
constraint on the DB.
On Tue, 14 Mar 2017 at 10:14 Stian Thorgersen <sthorger(a)redhat.com> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
12:21 p.m.
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.
- 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.
- 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?
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:34 a.m.
On 14 March 2017 at 12:21, Marek Posolda <mposolda(a)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..)
- 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.
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
1:08 p.m.
On 16/03/17 11:34, Stian Thorgersen wrote:
On 14 March 2017 at 12:21, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>
2:35 p.m.
On 16 March 2017 at 13:08, Marek Posolda <mposolda(a)redhat.com> wrote:
On 16/03/17 11:34, Stian Thorgersen wrote:
On 14 March 2017 at 12:21, Marek Posolda <mposolda(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
3:58 p.m.
On 16/03/17 14:35, Stian Thorgersen wrote:
On 16 March 2017 at 13:08, Marek Posolda <mposolda(a)redhat.com
<mailto:mposolda@redhat.com>> wrote:
On 16/03/17 11:34, Stian Thorgersen wrote:
>
>
> On 14 March 2017 at 12:21, Marek Posolda <mposolda(a)redhat.com
> <mailto:mposolda@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(a)lists.jboss.org
> <mailto:keycloak-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>
2:52 p.m.
This would have to be a completely optional SPI. There are a lot of
keycloak users that are just mapping data from LDAP into our tokens and
don't care about validation.
On 3/14/17 5:13 AM, 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:35 a.m.
Actually it doesn't even come into play in that situation. Validation would
only be invoked if user or admin changes the profile directly through
Keycloak.
On 14 March 2017 at 14:52, Bill Burke <bburke(a)redhat.com> wrote:
This would have to be a completely optional SPI. There are a lot of
keycloak users that are just mapping data from LDAP into our tokens and
don't care about validation.
On 3/14/17 5:13 AM, 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
11:36 a.m.
For a new realm the default should be:
* Allow built-in attributes (similar to what we have now), but don't allow
any additional attributes
For migrated realms the default should be:
* Verify built-in attributes as we do now and allow any custom attributes
On 16 March 2017 at 11:35, Stian Thorgersen <sthorger(a)redhat.com> wrote:
Actually it doesn't even come into play in that situation.
Validation
would only be invoked if user or admin changes the profile directly through
Keycloak.
On 14 March 2017 at 14:52, Bill Burke <bburke(a)redhat.com> wrote:
> This would have to be a completely optional SPI. There are a lot of
> keycloak users that are just mapping data from LDAP into our tokens and
> don't care about validation.
>
>
>
> On 3/14/17 5:13 AM, 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(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
2597
days inactive
2599
days old
10 comments
4 participants
participants (4)
-
Bill Burke -
Marek Posolda -
Martin Hardselius -
Stian Thorgersen