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

Vlastimil Elias velias at redhat.com
Mon Oct 2 07:06:38 EDT 2017


Hi,


On 29.9.2017 15:29, Bill Burke wrote:
> LoginFormsProvider has a setAttribute() method.   Isn't that enough?

Use of this means that we have to rewrite all authenticators (and 
reconfigure all flows) and potential other code parts where the 
LoginFormsProvider is called from. May be used for some use cases, but 
it is not usable for our use case where we need to pass some additional 
attributes always.

Vl.

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

-- 
Vlastimil Elias
Principal Software Engineer, Middleware Engineering Services
Red Hat



More information about the keycloak-dev mailing list