[keycloak-dev] Profile SPI

[Stian Thorgersen]

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