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

[Stian Thorgersen]

On 29 September 2017 at 15:29, Bill Burke <bburke at redhat.com> wrote:

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

That only works if you have a custom authenticator and custom template. It
doesn't work if you just want to expose additional attributes to a custom
template.


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

Hence why I wouldn't want to expose KeycloakSession, AuthenticationSession,
etc. to templates ourselves, but rather allow custom providers to expose
additional attributes to templates if they want to.


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