Artemis Rest Interface JAAS

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Artemis Rest Interface JAAS

shumin
I followed
http://activemq.2283324.n4.nabble.com/Artemis-and-RESTeasy-jar-files-td4736865.html
to add a war to Artemis server to enable Rest Interface.  The war is
configured to use vm://0 as the default.  The idea is to allow clients to
post messages via REST.  I am having trouble once the security of Artemis
server is turned on.  The server complains with exception showing at the end
of this post.  The server is configured with a security realm using
properties files for users and roles.  In there I used a filter (after
failed attempt to configure the war to use Jetty jetty-web.xml for basic
authentication due to some libraries mismatched, that requires a separated
post by its own) to do basic authentication using the existing realm at the
server.

Going through the exception, I see it calling following at
org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.findQueue(QueueDestinationsResource.java:102)

         ClientSession session =
manager.getSessionFactory().createSession(false, false, false);

It in turn passing null for both username and password, hence the exception.
I realized that it does not matter if it is authenticated or not since null
username and password are hard-coded inside Artemis-Rest.

What is the proper way to pass credential?  Or what is the proper way to
secure Rest Interface using the existing JAAS configuration?  Is there any
test cases with security turned on that I can study?  I went through
document and searched forum and internet and could not find a way.  Please
help.

Thanks a lot!
 

[org.eclipse.jetty.server.HttpChannel] /rest/queues/cs-updates:
org.jboss.resteasy.spi.UnhandledException:
ActiveMQSecurityException[errorType=SECURITY_EXCEPT
ION message=AMQ119031: Unable to validate user from invm:0. Username: null;
SSL certificate subject DN: unavailable]
        at
org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
        at
org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
        at
org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:247)
        at
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:225)
        at
org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:62)
        at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:50)
        at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1613)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:541)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1593)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:481)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1141)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at org.eclipse.jetty.server.Server.handle(Server.java:564)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:110)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at
org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
[jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
        at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_91]
Caused by: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION
message=AMQ119031: Unable to validate user from invm:0. Username: null; SSL
certificate subject DN: unavailable]
        at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:423)
[artemis-core-client-2.6.3.jar:2.6.3]
        at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:319)
[artemis-core-client-2.6.3.jar:2.6.3]
        at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:288)
[artemis-core-client-2.6.3.jar:2.6.3]
        at
org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:237)
[artemis-core-client-2.6.3.jar:2.6.3]
        at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1327)
[artemis-core-client-2.6.3.jar:2.6.3]
        at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:672)
[artemis-core-client-2.6.3.jar:2.6.3]
        at
org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:332)
[artemis-core-client-2.6.3.jar:2.6.3]
        at
org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.findQueue(QueueDestinationsResource.java:102)
[artemis-rest-2.6.3.jar:2.6.3]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[rt.jar:1.8.0_91]
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[rt.jar:1.8.0_91]
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_91]
        at java.lang.reflect.Method.invoke(Method.java:498)
[rt.jar:1.8.0_91]
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58)
        at
org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
        at
org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)




--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Artemis Rest Interface JAAS

jbertram
I think that you'll need to secure the URLs via web.xml as the
documentation [1] points out.


Justin

[1]
https://activemq.apache.org/artemis/docs/latest/rest.html#security-in-other-environments

On Mon, Oct 29, 2018 at 11:19 AM shumin <[hidden email]> wrote:

> I followed
>
> http://activemq.2283324.n4.nabble.com/Artemis-and-RESTeasy-jar-files-td4736865.html
> to add a war to Artemis server to enable Rest Interface.  The war is
> configured to use vm://0 as the default.  The idea is to allow clients to
> post messages via REST.  I am having trouble once the security of Artemis
> server is turned on.  The server complains with exception showing at the
> end
> of this post.  The server is configured with a security realm using
> properties files for users and roles.  In there I used a filter (after
> failed attempt to configure the war to use Jetty jetty-web.xml for basic
> authentication due to some libraries mismatched, that requires a separated
> post by its own) to do basic authentication using the existing realm at the
> server.
>
> Going through the exception, I see it calling following at
>
> org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.findQueue(QueueDestinationsResource.java:102)
>
>          ClientSession session =
> manager.getSessionFactory().createSession(false, false, false);
>
> It in turn passing null for both username and password, hence the
> exception.
> I realized that it does not matter if it is authenticated or not since null
> username and password are hard-coded inside Artemis-Rest.
>
> What is the proper way to pass credential?  Or what is the proper way to
> secure Rest Interface using the existing JAAS configuration?  Is there any
> test cases with security turned on that I can study?  I went through
> document and searched forum and internet and could not find a way.  Please
> help.
>
> Thanks a lot!
>
>
> [org.eclipse.jetty.server.HttpChannel] /rest/queues/cs-updates:
> org.jboss.resteasy.spi.UnhandledException:
> ActiveMQSecurityException[errorType=SECURITY_EXCEPT
> ION message=AMQ119031: Unable to validate user from invm:0. Username: null;
> SSL certificate subject DN: unavailable]
>         at
>
> org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
>         at
>
> org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
>         at
>
> org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
>         at
>
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
>         at
>
> org.jboss.resteasy.core.SynchronousDispatcher.invokePropagateNotFound(SynchronousDispatcher.java:247)
>         at
>
> org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:225)
>         at
>
> org.jboss.resteasy.plugins.server.servlet.FilterDispatcher.doFilter(FilterDispatcher.java:62)
>         at
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1621)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> BasicAuthenticationFilter.doFilter(BasicAuthenticationFilter.java:50)
>         at
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1613)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:541)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:190)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1593)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:188)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1239)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:168)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:481)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1562)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:166)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1141)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.server.handler.HandlerList.handle(HandlerList.java:52)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:132)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at org.eclipse.jetty.server.Server.handle(Server.java:564)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:320)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:251)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.io
> .AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:279)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at org.eclipse.jetty.io
> .FillInterest.fillable(FillInterest.java:110)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
> org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:124)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:672)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:590)
> [jetty-all-9.4.3.v20170317-uber.jar:9.4.3.v20170317]
>         at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_91]
> Caused by: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION
> message=AMQ119031: Unable to validate user from invm:0. Username: null; SSL
> certificate subject DN: unavailable]
>         at
>
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:423)
> [artemis-core-client-2.6.3.jar:2.6.3]
>         at
>
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:319)
> [artemis-core-client-2.6.3.jar:2.6.3]
>         at
>
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:288)
> [artemis-core-client-2.6.3.jar:2.6.3]
>         at
>
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:237)
> [artemis-core-client-2.6.3.jar:2.6.3]
>         at
>
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1327)
> [artemis-core-client-2.6.3.jar:2.6.3]
>         at
>
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:672)
> [artemis-core-client-2.6.3.jar:2.6.3]
>         at
>
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:332)
> [artemis-core-client-2.6.3.jar:2.6.3]
>         at
>
> org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.findQueue(QueueDestinationsResource.java:102)
> [artemis-rest-2.6.3.jar:2.6.3]
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [rt.jar:1.8.0_91]
>         at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [rt.jar:1.8.0_91]
>         at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [rt.jar:1.8.0_91]
>         at java.lang.reflect.Method.invoke(Method.java:498)
> [rt.jar:1.8.0_91]
>         at
>
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:79)
>         at
>
> org.jboss.resteasy.core.ResourceLocatorInvoker.createResource(ResourceLocatorInvoker.java:58)
>         at
>
> org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:100)
>         at
>
> org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis Rest Interface JAAS

shumin
What I described in my previous post are securing all URLs via web.xml.  I am
using a Servlet filter to enforce basic authentication using the same
security realm as the Artemis server.  The issue is that the security
credential from war is not carried over to Artemis server as the server has
it own security turned on although they both use the same realm.  Here is
the sequence (and you can see it from the stacktrace)

1. curl --user user:password http://localhost:8161/queue/myQueue
2. the Servlet filter authenticated and authorized the access
3. artemis-reat creates session at
org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.java:102.  
4. It passes hard-coded null for both user and password at
org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.findQueue(QueueDestinationsResource.java:102)
5. Exception thrown from server that username is null.

I am hoping there is a way to pass authenticated credential from step 2 to
step 3, then 4.  Or better yet, avoid the 2nd authentication and
authorization at Artemis server (with security on) all together.

It seems to me that artemis-rest expects us to secure rest interface URLs
with Artemis server security turned off.  In my case, I am hoping to secure
both rest interface URLs and tcp:61616 so that client can post message via
rest or via normal JMS protocol.  Is it possible?



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Artemis Rest Interface JAAS

jbertram
> I am hoping there is a way to pass authenticated credential from step 2
to step 3, then 4.

Looking at the code I don't see where any credentials are taken from the
incoming HTTP requests and passed along to the messaging operations. As you
noted, everything is hard-code to not use security.

> Or better yet, avoid the 2nd authentication and authorization at Artemis
server (with security on) all together.

I believe the only way to accomplish that would be to completely rewrite
the REST interface.

> It seems to me that artemis-rest expects us to secure rest interface URLs
with Artemis server security turned off.

Yes, I believe that was an original design assumption of the REST interface
implementation.

> In my case, I am hoping to secure both rest interface URLs and tcp:61616
so that client can post message via rest or via normal JMS protocol.  Is it
possible?

That doesn't look to be possible at this point from what I can tell.

Out of curiosity, is there a reason you're wanting to use the REST
interface (which is not standardized) vs. a lightweight protocol like STOMP
(which is standardized)?


Justin

On Mon, Oct 29, 2018 at 10:37 PM shumin <[hidden email]> wrote:

> What I described in my previous post are securing all URLs via web.xml.  I
> am
> using a Servlet filter to enforce basic authentication using the same
> security realm as the Artemis server.  The issue is that the security
> credential from war is not carried over to Artemis server as the server has
> it own security turned on although they both use the same realm.  Here is
> the sequence (and you can see it from the stacktrace)
>
> 1. curl --user user:password http://localhost:8161/queue/myQueue
> 2. the Servlet filter authenticated and authorized the access
> 3. artemis-reat creates session at
> org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.java:102.
>
> 4. It passes hard-coded null for both user and password at
>
> org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.findQueue(QueueDestinationsResource.java:102)
> 5. Exception thrown from server that username is null.
>
> I am hoping there is a way to pass authenticated credential from step 2 to
> step 3, then 4.  Or better yet, avoid the 2nd authentication and
> authorization at Artemis server (with security on) all together.
>
> It seems to me that artemis-rest expects us to secure rest interface URLs
> with Artemis server security turned off.  In my case, I am hoping to secure
> both rest interface URLs and tcp:61616 so that client can post message via
> rest or via normal JMS protocol.  Is it possible?
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
Reply | Threaded
Open this post in threaded view
|

Re: Artemis Rest Interface JAAS

jbertram
FWIW, the username and password could theoretically be retrieved from the
HTTP request with a simple block of code [1], but using it in the REST
interface isn't completely straightforward as, for example, producers (and
their sessions) are pooled as it's not a good idea to create a session &
producer for every message sent.


Justin

[1]
https://stackoverflow.com/questions/16000517/how-to-get-password-from-http-basic-authentication

On Tue, Oct 30, 2018 at 8:43 AM Justin Bertram <[hidden email]> wrote:

> > I am hoping there is a way to pass authenticated credential from step 2
> to step 3, then 4.
>
> Looking at the code I don't see where any credentials are taken from the
> incoming HTTP requests and passed along to the messaging operations. As you
> noted, everything is hard-code to not use security.
>
> > Or better yet, avoid the 2nd authentication and authorization at Artemis
> server (with security on) all together.
>
> I believe the only way to accomplish that would be to completely rewrite
> the REST interface.
>
> > It seems to me that artemis-rest expects us to secure rest interface
> URLs with Artemis server security turned off.
>
> Yes, I believe that was an original design assumption of the REST
> interface implementation.
>
> > In my case, I am hoping to secure both rest interface URLs and tcp:61616
> so that client can post message via rest or via normal JMS protocol.  Is it
> possible?
>
> That doesn't look to be possible at this point from what I can tell.
>
> Out of curiosity, is there a reason you're wanting to use the REST
> interface (which is not standardized) vs. a lightweight protocol like STOMP
> (which is standardized)?
>
>
> Justin
>
> On Mon, Oct 29, 2018 at 10:37 PM shumin <[hidden email]> wrote:
>
>> What I described in my previous post are securing all URLs via web.xml.
>> I am
>> using a Servlet filter to enforce basic authentication using the same
>> security realm as the Artemis server.  The issue is that the security
>> credential from war is not carried over to Artemis server as the server
>> has
>> it own security turned on although they both use the same realm.  Here is
>> the sequence (and you can see it from the stacktrace)
>>
>> 1. curl --user user:password http://localhost:8161/queue/myQueue
>> 2. the Servlet filter authenticated and authorized the access
>> 3. artemis-reat creates session at
>> org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.java:102.
>>
>> 4. It passes hard-coded null for both user and password at
>>
>> org.apache.activemq.artemis.rest.queue.QueueDestinationsResource.findQueue(QueueDestinationsResource.java:102)
>> 5. Exception thrown from server that username is null.
>>
>> I am hoping there is a way to pass authenticated credential from step 2 to
>> step 3, then 4.  Or better yet, avoid the 2nd authentication and
>> authorization at Artemis server (with security on) all together.
>>
>> It seems to me that artemis-rest expects us to secure rest interface URLs
>> with Artemis server security turned off.  In my case, I am hoping to
>> secure
>> both rest interface URLs and tcp:61616 so that client can post message via
>> rest or via normal JMS protocol.  Is it possible?
>>
>>
>>
>> --
>> Sent from:
>> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>>
>