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

Dmitry Telegin dt at acutus.pro
Mon Jul 16 19:54:56 EDT 2018 

Hi Hynek,
Thx, got it, will submit the draft soon. 
And I'm sorry for having forgotten to answer to your previous question:
> > > > It looks like the way you would describe would be applicable to
> > > > any OSGi-compliant container, correct? Which OSGi release?

In theory that should be suitable for every OSGi-compliant runtime with
HttpService. We have yet tested it on Apache Felix 5.6.10 (both
standalone and as a part of Apache Karaf 4.2.0), so that's OSGi
R6.Haven't tested on either Equinox or Knopflerfish though, will
probably need volunteers for that.
Dmitry
On Mon, 2018-07-16 at 08:56 +0200, Hynek Mlnarik wrote:
> Thanks for the PR.
> Ad the documentation - the best suitable place would be [1]. Since
> this would currently be for community only, please enclose it into
> similar if-endif like here [2]. The PR would be submitted under the
> same KEYCLOAK issue as implementation, i.e. KEYCLOAK-7858. And no
> worries, we will be happy to help shaping up the documentation in the
> PR, just send what you would have and we'll help out.
> 
> Thank you
> 
> --Hynek
> 
> [1] https://github.com/keycloak/keycloak-documentation/blob/master/se
> curing_apps/topics/oidc/java/servlet-filter-adapter.adoc
> [2] https://github.com/keycloak/keycloak-documentation/blame/master/s
> ecuring_apps/topics/oidc/java/application-clustering.adoc#L4
> On Mon, Jul 16, 2018 at 2:54 AM Dmitry Telegin <dt at acutus.pro> wrote:
> > Hi,
> > https://issues.jboss.org/browse/KEYCLOAK-7858https://github.com/key
> > cloak/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