[keycloak-dev] Keycloak servlet filter adapter on OSGi, first impressions

[Hynek Mlnarik]

Hi Dmitri,

thank you for the updates.

The 1. (dependencies on Apache HTTP Components) has been resolved in the
latest master already and the -thirdparty module has been removed.
Hopefully this addresses your concerns completely.

Ad 2. we have taken approach with OSGi fragment when resolving similar
situation with server-specific implementation, see e.g. [1]. This is
preferrable to moving classes to different packages. Could you take this
approach?

[1]
https://github.com/keycloak/keycloak/blob/master/adapters/spi/undertow-adapter-spi/pom.xml#L119


On Wed, Jul 11, 2018 at 7:36 PM Dmitry Telegin <dt at acutus.pro> wrote:

> Hi,
>
> We are working on integrating Apache Sling with Keycloak (see my
> posting from June 12). It was suggested that we'd stick to servlet
> filter adapter as the most generic one (unlike Keycloak OSGi
> adapter which is more of a JBoss Fuse adapter).
>
> The first step was to convert keycloak-servlet-filter-adapter and
> required keycloak-servlet-adapter-spi to OSGi bundles. This went OK,
> I've just added OSGi bundling to the respective POMs. However there
> were two major issues when deploying and running the code:
>
> 1. Bogus dependency on org.apache.http.*
>
> Several Keycloak modules the adapter depends on,
> namely keycloak-authz-client and keycloak-adapter-core, declare
> bogus "Import-Package: org.apache.http.*;version=4.5.2" dependency.
>
> This comes from the following lines in the POM:
>
>         <keycloak.osgi.import>
>             org.keycloak.*;version="${project.version}",
>             org.apache.http.*;version=${apache.httpcomponents.version},
>             ...
>         </keycloak.osgi.import>
>
> org.apache.http.* is exported by org.apache.httpcomponents:httpcore-osgi,
> which uses its own versioning scheme (4.4.9 is the latest version ATM).
> Thus, deploying the bundle to OSGi runtime fails due to unsatisfied
> dependency.
>
> Later, I've discovered there's keycloak-osgi-thirdparty bundle that
> provides required dependencies (however, they don't become less bogus
> because of that).
>
> I'm OK with this workaround, but generally speaking, is
> keycloak-osgi-thirdparty still needed?
> I've got an impression it was created at a time when not every dependency
> was available as OSGi bundle.
>
> Current version of keycloak-osgi-thirdparty contains merged httpclient and
> httpcore, which are available as org.apache.httpcomponents:httpclient-osgi
> and org.apache.httpcomponents:httpcore-osgi, respectively.
>
> So to me it seems like a candidate for deprecation and removal. If so, the
> bogus dependency issue, obviously, should be tackled with first.
>
> 2. Split package org.keycloak.adapters.servlet
>
> > In standard Java programming, packages are generally treated as
> > split; the Java class path  approach merges all packages from
> > different JAR files on the class path into one big  soup. This is
> > anathema to OSGi’s modularization model, where packages are treated
> > as atomic (that is, they can’t be split).
>
> http://web.ist.utl.pt/ist162500/?p=65
>
> In Keycloak, the package org.keycloak.adapters.servlet is split between
> keycloak-servlet-adapter-spi and keycloak-servlet-filter-adapter. This
> leads to seemingly inexplicable NoClassDefFoundError's, when e.g.
> KeycloakOIDCFilter cannot find its neighbor OIDCServletHttpFacade. The
> recipe provided by the above article (create dummy bundle, prohibit
> direct imports etc.) is rather cumbersome, so I've just created
> org.keycloak.adapters.servlet.spi package and moved there the two
> classes from keycloak-servlet-adapter-spi.
>
> After that, I was finally able to wire Keycloak filter to a test
> servlet, and it worked pretty well. There was a redirect to Keycloak's
> login screen, then redirect back, and the servlet was able to obtain
> valid KeycloakPrincipal with JWT token.
>
> To sum up, I'm eager to contribute changes required to make Keycloak
> servlet filter adapter a valid and working OSGi bundle. That would
> include OSGi bundling for two modules and split package refactoring.
> The first issue (bogus deps) IMO should require further discussion.
>
> Let me know what you think,
>
> Dmitry Telegin
> CTO, Acutus s.r.o.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev