[keycloak-dev] Allow additional attributes to be pushed into Freemarker templates (login and account themes) by extension developers

[Bill Burke]

LoginFormsProvider has a setAttribute() method.   Isn't that enough?

We have to let authenticator plugins drive the forms as down the road
we might be required to build a SaaS which means our themes need to be
secure enough to run in a multi-tenant environment.

On Fri, Sep 29, 2017 at 7:30 AM, Stian Thorgersen <sthorger at redhat.com> wrote:
> Making the required methods protected is a simple way to work around the
> issue, but bear in mind that the FreeMarker providers are likely to change
> in the future.
>
> Another option could be to introduce an FreeMarkerAttributeProviderSPI, the
> current freemarker providers would call all available providers to allow
> them to add additional attributes. Something like:
>
> * registerAccountAttribute(FormContext..)
> * registerLoginAttribute(FormContext..)
>
> Where FormContext would have access to KeycloakSession,
> AuthenticationSession, etc..
>
> Slightly more work, but would be more future proof IMO.
>
>
> On 27 September 2017 at 15:20, Vlastimil Elias <velias at redhat.com> wrote:
>
>> Hi,
>>
>> I was asked by Stian to post my proposal around
>> https://issues.jboss.org/browse/KEYCLOAK-2671 to be discussed here with
>> wider KC dev team.
>>
>> What we need is to pass some additional attributes into Login and
>> Account freemarker templates as part of our extensions  - eg. to
>> configure client side validations for registration form based on actual
>> authentication session. Other use case we need is selection of Theme
>> based on calling client.
>>
>> There are already Login and Account Form providers which may be
>> customized (they are SPI), only problem is that current Freemarker
>> providers use private fields and methods, so it is hard to customize
>> them (I have to copy complete code which is hardly maintainable during
>> keycloak upgrades).
>>
>> I believe we should resolve the problem by small refactoring of existing
>> FreeMarkerLoginProvider and FreeMarkerAccountProvider providers similar
>> you already done in FreeMarkerEmailTemplateProvider. So things like:
>>
>>   * change fields and methods from private to protected to allow
>>     use/override in subclasses
>>   * refactor some features to protected methods (eg. Template loading
>>     from template provider - again, you did it in
>>     FreeMarkerEmailTemplateProvider provider already) to allow override
>>     in subclasses
>>   * add one protected callback method called just before template and
>>     attributes are passed to the freemarker engine for the processing -
>>     this allow subclass simply add additional attributes to be passed
>>     into template
>>
>> Only bigger change (and blocker for one of our important features) is
>> passing of current AuthenticationSessionModel to the LoginFormsProvider
>> instance at all places where the form provider is called. This is really
>> missing now to be able customize GUI based on current client and
>> authentication flow needs.
>>
>> I don't think those are big changes, but they will make life of
>> extension developers much easier.
>>
>> I believe I'm able to provide pull request for this change if no better
>> solution will be found there by experienced KC dev team.
>>
>> Thanks a lot in advance for any comments to my proposal.
>>
>> Vlastimil
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer, Middleware Engineering Services
>> Red Hat
>>
>> _______________________________________________
>> 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



-- 
Bill Burke
Red Hat