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

[Dmitry Telegin]

Hi Hynek,
Thanks for the OSGi fragment tip, it worked perfectly. Also glad to
hear the HTTP Components dependency issue has been resolved.
So OK for JIRA/PR for servlet filter adapter OSGi bundling? And, by the
way, should we document how to use this adapter on OSGi? Installing a
bundle is not sufficient, the filter should be registered with OSGi
HTTP Service, and there are at least two ways of doing it (via
BundleContext::registerService or via a @Component that extends the
filter class). What do you think?
Dmitry
On Thu, 2018-07-12 at 11:10 +0200, Hynek Mlnarik wrote:
> 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/und
> ertow-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