[keycloak-dev] Keycloak servlet filter adapter on OSGi, first impressions
Dmitry Telegin
dt at acutus.pro
Sun Jul 15 20:54:07 EDT 2018
Hi,
https://issues.jboss.org/browse/KEYCLOAK-7858https://github.com/keycloa
k/keycloak/pull/5383
As for documentation, I'm experienced in technical writing, however
I'll still need supervisor/reviewer since I'll be contributing to
Keycloak docs for the first time.
Idea: we could have (one day) something kind of "OSGi extras" for
servlet filter adapter, containing bundle activator to install a filter
+ config resolver that would integrate with OSGi Config Admin Service.
WDYT?
Dmitry
On Fri, 2018-07-13 at 15:36 +0200, Hynek Mlnarik wrote:
> Excellent. JIRA + PR for OSGi bundling would be welcome. Re the
> documentation, yes please, it will be necessary. It looks like the
> way you would describe would be applicable to any OSGi-compliant
> container, correct? Which OSGi release?
> Thanks,
>
> --Hynek
> On Fri, Jul 13, 2018 at 2:24 AM Dmitry Telegin <dt at acutus.pro> wrote:
> > 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
> > > /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
More information about the keycloak-dev
mailing list