[keycloak-dev] Profile SPI

Stian Thorgersen sthorger at redhat.com
Thu Mar 16 06:36:28 EDT 2017


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


More information about the keycloak-dev mailing list