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
>