AuthorizationHandler not being called

Question

AuthorizationHandler not being called

Opened this issue 7 years ago · 6 comments

Hi All
Wanted to ask if anyone has the jax-rs-connector working properly in a Karaf 4.0.x environment?

Specifically the issue is with authentication and authorization handlers. There's a class implementing both interfaces.

With an http request arriving, the authentication seems to work, as the authenticate() method is called.
However, regardless of whether that method returns null or a Principal, the request does not get rejected and also the authorization handler is never called.

Does anyone have any suggestion on where to look further.

Answer 1 · 2017-09-13T13:10:09.000Z

It depends on how you are doing authentication and authorization in your REST service. If you are managing authentication and authorization on a per method basis, then it's up to you. If you are using the jax-rs annotations, then it should be managed by Jersey.

Answer 2 · 2017-09-13T13:47:19.000Z

I'm using the @RolesAllowed and @Denyall (for testing only) annotations, so that's the case you say Jersey should manage.

I double-checked my implementation of the AuthorizationHandler interface is also registered as an OSGi service. Still it's not called.

The AuthenticationHandler however is called via the following call stack:

at my.path.impl.SecurityHandlerImpl.authenticate(SecurityHandlerImpl.java:49)
at com.eclipsesource.jaxrs.provider.security.impl.SecurityAdmin.createSecurityContext(SecurityAdmin.java:38)
at com.eclipsesource.jaxrs.provider.security.impl.SecurityAdmin.getSecurityContext(SecurityAdmin.java:29)
at com.eclipsesource.jaxrs.provider.security.impl.ContainerRequestFilterImpl.filter(ContainerRequestFilterImpl.java:36)
at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:132)
at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:68)
at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197)
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:318)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271)
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267)
at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
at org.glassfish.jersey.internal.Errors.process(Errors.java:267)
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317)
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305)
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154)
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473)
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341)
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228)
at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:587)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:287)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:748)

Any place I could dig in to find out why authorization does not kick in?

Answer 3 · 2017-09-23T15:18:08.000Z

I faced a similar issue sometime back and it was resolved by making my REST Resource classes extend RolesAllowedDynamicFeature interface.

Answer 4 · 2017-10-30T16:23:20.000Z

Hi,
I have the same issue. I debugged it a little bit and for me it looks like to be a problem how javax.annotation is resolved.

For my bundle that implements the components that are annotated with @path and @RolesAllowed the javax.annotation is revolved to the Felix System Bundle with ID: 0

The jersey-min bundle contains an internal copy of javax.annotation that is used then automatically.
So the comparision of the annotations goes wrong in RolesAllowedDynamicFeature.configure()
It invokes org.glassfish.jersey.server.model.isAnnotationPresent
That one always returns false because the @RolesAllowed comes from two different OSGI class loaders and are therefore not considered to be the same.

Im no OSGI pro so I cannot tell for sure but for me it seems that jersey-min should not contain javax.annotation as a copy but resolve it the same way as "resource implementation" bundles do?

Or is there a way to force the resolving of my bundles to use the javax.annotation provided by jersey-min?

Best regards,

Bernd

Answer 5 · 2017-11-08T07:31:51.000Z

After some more research I stumbled uppon this.

https://www.osgi.org/portable-java-contract-definitions/

So I think jersey-min should define the dependency on javax.annotation via a contract instead of embedding it?

Bernd

Answer 6 · 2020-10-07T11:49:41.000Z

Hi

I'm currently facing the same issue on a Adobe Experience Manager (AEM) OSGi platform.

Making my REST resource extend RolesAllowedDynamicFeature unfortunately did not help in my case (the result was a HTTP 404 when calling the REST resource). Has anyone found a solution to this problem?

Best regards
Richard