You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Tom Samplonius <to...@samplonius.org> on 2007/06/03 00:29:25 UTC
Getting Stomp support to a usable state...
How much more work needs to occur to get Stomp protocol support to a usable state? The biggest issue is lack of any authentication support for Stomp, so anyone with access to the Stomp port can get and send anything. I can't imagine that anyone is using Stomp in production yet.
But is anyone working on this? I've looked into the JAAS stuff, and the Stomp code in ActiveMQ. It would take me a week to figure out how to wrap Stomp with JAAS, as I have never worked with JAAS before. I assume the original author of the Stomp support probably skipped authentication. Does anyone have any patches? Or any insight on how to fix this? I really want usable Stomp support in ActiveMQ.
The Web Console has similar issues. There is no easy way to password protect it. But if you password protect JMX access, it will break the Web Console.
I assume that everyone that uses ActiveMQ in production today, is using just OpenWire and JMX, and not the Web Console or Stomp. Is that the case? Or, are users not aware of the default-open security configuration of ActiveMQ?
Tom
Re: Actually getting Stomp support to a usable state...
Posted by PieterN <se...@internethoofdkantoor.nl>.
James.Strachan wrote:
>
>> All of the wire protocols tie back to some sort of core, where auth is
>> evaluated. And that is supposed to flow back to the wire protocol again.
>>
>> And the ActiveMQ core just depends on the protocol to do the right
>> thing. If the auth failed, it will still take successive commands.
>
> Yeah, that sounds an easy one to fix; we just need to disconnect the
> socket if a connection fails I guess? Fancy taking a stab at it? Am
> thinking some code in ProtcolConverter if an exception occurs on the
> response, to just close the connection (after the ERROR is sent back).
>
This is more or less what my patch does posted elsewhere in this thread.
It's a bit of a hack however, it doesn't send an error frame. This is (I
think) because the connection isn't set up properly, the function just bails
out. A proper solution (which sends an ERROR frame) probably requires a bit
of rewriting of the onStompConnect method.
BTW, Tom reported in this thread this patch didn't work for him. I have no
idea why, it did for me. It is against a 4.2 snapshot from ~ 1 month old I
think. I think it doesn't work for 4.1, I believe there were some changes
after that upstream in the code flow to actually throw the Exception.
This is the patch I was talking about:
---
src/activemq-core/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java
2007-05-11 02:02:04.000000000 +0200
+++
src/activemq-core/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java
2007-05-22 12:41:32.000000000 +0200
@@ -36,6 +36,7 @@
import org.apache.activemq.command.ConnectionInfo;
import org.apache.activemq.command.ConsumerId;
import org.apache.activemq.command.ConsumerInfo;
+import org.apache.activemq.command.ExceptionResponse;
import org.apache.activemq.command.LocalTransactionId;
import org.apache.activemq.command.MessageAck;
import org.apache.activemq.command.MessageDispatch;
@@ -413,7 +414,18 @@
connectionInfo.setPassword(passcode);
sendToActiveMQ(connectionInfo, new ResponseHandler(){
- public void onResponse(ProtocolConverter converter, Response response)
throws IOException {
+ public void onResponse(ProtocolConverter converter, Response response)
throws IOException, ProtocolException {
+
+ /* PN: if the response is an exception, propagate the exception to send
an ERROR frame */
+ if (response.isException()) {
+ ExceptionResponse exception = (ExceptionResponse) response;
+ // apparently, other (non-fatal) exceptions are generated as well (see
debug log)
+ if (exception.getException() instanceof SecurityException) {
+ // FIXME: should set up connection, send an ERROR frame, and
disconnect
+ // this disconnects immediately
+ throw new ProtocolException(exception.getException().getMessage());
+ }
+ }
final SessionInfo sessionInfo = new SessionInfo(sessionId);
sendToActiveMQ(sessionInfo,null);
Hope this helps.
Regards,
Pieter Naaijkens
--
View this message in context: http://www.nabble.com/Getting-Stomp-support-to-a-usable-state...-tf3858629s2354.html#a11248423
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Actually getting Stomp support to a usable state...
Posted by James Strachan <ja...@gmail.com>.
On 6/21/07, Tom Samplonius <to...@samplonius.org> wrote:
>
> ----- "James Strachan" <ja...@gmail.com> wrote:
> ...
> > Just use the JAAS plugin in ActiveMQ and you're good to go; the Stomp
> > code uses whatever security plugin you're using
>
>
> As has been discussed, this is broken, and has been since 4.1.1 or earlier.
>
> Is there any sort of roadmap to the ActiveMQ internals,
We use JIRA for the roadmap...
http://issues.apache.org/activemq/browse/AMQ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
> so I can take a stab at fixing this without having to start from scratch?
Awesome! We *love* contributions....
http://activemq.apache.org/contributing.html
> All of the wire protocols tie back to some sort of core, where auth is evaluated. And that is supposed to flow back to the wire protocol again.
>
> And the ActiveMQ core just depends on the protocol to do the right thing. If the auth failed, it will still take successive commands.
Yeah, that sounds an easy one to fix; we just need to disconnect the
socket if a connection fails I guess? Fancy taking a stab at it? Am
thinking some code in ProtcolConverter if an exception occurs on the
response, to just close the connection (after the ERROR is sent back).
> > I know lots of folks using both the Web Console and Stomp in
> > production with security
>
> But I don't know how this could be possible, unless people just haven't tried with a mis-spelled password. And there isn't a release version of ActiveMQ that doesn't lose Stomp messages one way or another. So I have to assume that they production sites are using snapshots too.
Which message loss thing is that? Is there a JIRA?
> But Stomp support is as buggy as hell in ActiveMQ.
Thats a little strong, AFAIK there's only a couple of bugs...
> It seems that the ActiveMQ project operates in some sort of twilight mode. Most projects would have issued a security advisory. Doesn't the Apache Foundation require its projects to issue security advisories for serious security problems? Doesn't the "Apache Way" include, "security as a mandatory feature"?
FWIW most JMS providers come with no security at all out of the box;
as MOMs are typically run inside the firewall & security is usually
enabled by changing the default configuration.
But you are right, we should log a warning that security in STOMP does
not work properly, so a mis-behaving stomp client could actually do
bad things.
> If no one can fix Stomp, that's fine, but it should be at least be disabled on default configuration.
We may as well fix this bug before the next release, rather than doing
a release just to disable stomp support
--
James
-------
http://macstrac.blogspot.com/
Re: Getting Stomp support to a usable state...
Posted by Mario Siegenthaler <ma...@gmail.com>.
I've added some documentation about the webconsole and I included a
section about how to password protect it (although only on jetty, but
I hope the folks will figure out how to 'translate'' that to tomcat by
themself :).
And for the JMX-password issue there is a patch by Andrew Deason
(https://issues.apache.org/activemq/browse/AMQ-1260).
Mario
On 6/7/07, Tom Samplonius <to...@samplonius.org> wrote:
> By all means, tell me how. Web Console can be protected with servlet security, which is fine.
>
> But I assume I'm correct, that the only way to protect JMX, is to the use the Sun JMX
Re: Getting Stomp support to a usable state...
Posted by Tom Samplonius <to...@samplonius.org>.
----- "PieterN" <se...@internethoofdkantoor.nl> wrote:
> Patch:
> ---
> ../../../activemq-snapshot/src/activemq-core/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java
>
...
I've tried this patch, and it doesn't change anything. Stomp clients can still connect with any username, and subscribe to any queue, and get messages, or send messages to any queue.
I've set the log level to Debug, and I don't see anything special in the logs either.
I don't know what the plans are for ActiveMQ 5.0, which is supposed to ship "soon", but I hope Stomp support is fixed by then.
Tom
Re: Getting Stomp support to a usable state...
Posted by PieterN <se...@internethoofdkantoor.nl>.
Tom Samplonius-2 wrote:
>
> Actually, it appears that the username and password are ignored. I
> fought with JAAS for about four hours before decided to try to read the
> code, and the comments say that the password is ignored. There appears to
> be no way to get a config that doesn't
> check the password. From ProtocolConvertor.java:
>
> // allow anyone to login for now
> String login = (String)headers.get(Stomp.Headers.Connect.LOGIN);
> String passcode =
> (String)headers.get(Stomp.Headers.Connect.PASSCODE);
> String clientId =
> (String)headers.get(Stomp.Headers.Connect.CLIENT_ID);
>
> There is no indication there is any attempt to validate the username and
> password via any sort of auth plugin. I assume based on the "for now"
> comment, that someone is working on this.
>
The authentication is done elsewhere, not in the Stomp protocol code. A
security exception is cast when this fails (this is shown in the log if
debugging is enabled). However, this exception isn't dealt with properly:
the stomp code just continues and the connection stays open. A quick and
dirty patch is below. A better way to handle is to send a Stomp ERROR frame,
and then disconnect. Unfortunately I don't have any time to fix a proper
patch.
Regards,
Pieter
Patch:
---
../../../activemq-snapshot/src/activemq-core/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java
2007-05-11 02:02:04.000000000 +0200
+++
activemq-core/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java
2007-05-22 12:41:32.000000000 +0200
@@ -36,6 +36,7 @@
import org.apache.activemq.command.ConnectionInfo;
import org.apache.activemq.command.ConsumerId;
import org.apache.activemq.command.ConsumerInfo;
+import org.apache.activemq.command.ExceptionResponse;
import org.apache.activemq.command.LocalTransactionId;
import org.apache.activemq.command.MessageAck;
import org.apache.activemq.command.MessageDispatch;
@@ -413,7 +414,18 @@
connectionInfo.setPassword(passcode);
sendToActiveMQ(connectionInfo, new ResponseHandler(){
- public void onResponse(ProtocolConverter converter,
Response response) throws IOException {
+ public void onResponse(ProtocolConverter converter,
Response response) throws IOException, ProtocolException {
+
+ /* PN: if the response is an exception,
propagate the exception to send an ERROR frame */
+ if (response.isException()) {
+ ExceptionResponse exception =
(ExceptionResponse) response;
+ // apparently, other (non-fatal)
exceptions are generated as well (see debug log)
+ if (exception.getException()
instanceof SecurityException) {
+ // FIXME: should set up
connection, send an ERROR frame, and disconnect
+ // this disconnects
immediately
+ throw new
ProtocolException(exception.getException().getMessage());
+ }
+ }
final SessionInfo sessionInfo = new
SessionInfo(sessionId);
sendToActiveMQ(sessionInfo,null);
--
View this message in context: http://www.nabble.com/Getting-Stomp-support-to-a-usable-state...-tf3858629s2354.html#a11060452
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Getting Stomp support to a usable state...
Posted by Tom Samplonius <to...@samplonius.org>.
----- "James Strachan" <ja...@gmail.com> wrote:
> On 6/2/07, Tom Samplonius <to...@samplonius.org> wrote:
> >
> > How much more work needs to occur to get Stomp protocol support to
> a usable state?
>
> Huh? :) Its very useable right now
>
>
> > The biggest issue is lack of any authentication support for Stomp,
> so anyone with access to the Stomp port can get and send anything. I
> can't imagine that anyone is using Stomp in production yet.
>
> Stomp has always supported authentication (on the CONNECT) which
> plugs
> into the underlying message brokers security & authentication
> mechanism.
Actually, it appears that the username and password are ignored. I fought with JAAS for about four hours before decided to try to read the code, and the comments say that the password is ignored. There appears to be no way to get a config that doesn't
check the password. From ProtocolConvertor.java:
// allow anyone to login for now
String login = (String)headers.get(Stomp.Headers.Connect.LOGIN);
String passcode = (String)headers.get(Stomp.Headers.Connect.PASSCODE);
String clientId = (String)headers.get(Stomp.Headers.Connect.CLIENT_ID);
There is no indication there is any attempt to validate the username and password via any sort of auth plugin. I assume based on the "for now" comment, that someone is working on this.
Interestingly, I check StompConnect, and it has very similar code to ActiveMQ, and it appears to actually pass the username and password over to JMS. I suppose using StompConnect in front of ActiveMQ would result in a working configuration, but would be, frankly, bizarre.
> > But is anyone working on this? I've looked into the JAAS stuff,
> and the Stomp code in ActiveMQ. It would take me a week to figure out
> how to wrap Stomp with JAAS, as I have never worked with JAAS before.
> I assume the original author of the Stomp support probably skipped
> authentication. Does anyone have any patches? Or any insight on how
> to fix this? I really want usable Stomp support in ActiveMQ.
>
>
> Just use the JAAS plugin in ActiveMQ and you're good to go; the Stomp
> code uses whatever security plugin you're using
Have you actually tried this? I've setup JAAS, and it all appears good, but it is a bit concerning when you change the password on a consume, and it still works...
> > The Web Console has similar issues. There is no easy way to
> password protect it. But if you password protect JMX access, it will
> break the Web Console.
>
> Thats more of a JMX thing really; you can enable security on JMX. The
> web console is also a WAR; so you can use the normal servlet security
> stuff too
I imagine so. JMX is a pain in general.
> > I assume that everyone that uses ActiveMQ in production today, is
> using just OpenWire and JMX, and not the Web Console or Stomp. Is
> that the case? Or, are users not aware of the default-open security
> configuration of ActiveMQ?
>
> I know lots of folks using both the Web Console and Stomp in
> production with security
By all means, tell me how. Web Console can be protected with servlet security, which is fine.
But I assume I'm correct, that the only way to protect JMX, is to the use the Sun JMX connector? I documented how I did it, on the JMX page on the Wiki.
And ActiveMQ does ship in a completely wide-open configuration. That is definitely a throw-back to an previous time. I'd post a activemq.xml with everything locked down, for inclusion in the next release, if I could figure it out.
> --
> James
> -------
> http://macstrac.blogspot.com/
Tom
Actually getting Stomp support to a usable state...
Posted by Tom Samplonius <to...@samplonius.org>.
----- "James Strachan" <ja...@gmail.com> wrote:
...
> Just use the JAAS plugin in ActiveMQ and you're good to go; the Stomp
> code uses whatever security plugin you're using
As has been discussed, this is broken, and has been since 4.1.1 or earlier.
Is there any sort of roadmap to the ActiveMQ internals, so I can take a stab at fixing this without having to start from scratch? All of the wire protocols tie back to some sort of core, where auth is evaluated. And that is supposed to flow back to the wire protocol again.
And the ActiveMQ core just depends on the protocol to do the right thing. If the auth failed, it will still take successive commands.
...
> I know lots of folks using both the Web Console and Stomp in
> production with security
But I don't know how this could be possible, unless people just haven't tried with a mis-spelled password. And there isn't a release version of ActiveMQ that doesn't lose Stomp messages one way or another. So I have to assume that they production sites are using snapshots too.
But Stomp support is as buggy as hell in ActiveMQ. It seems that the ActiveMQ project operates in some sort of twilight mode. Most projects would have issued a security advisory. Doesn't the Apache Foundation require its projects to issue security advisories for serious security problems? Doesn't the "Apache Way" include, "security as a mandatory feature"?
If no one can fix Stomp, that's fine, but it should be at least be disabled on default configuration.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
Re: Getting Stomp support to a usable state...
Posted by Tom Samplonius <to...@samplonius.org>.
----- "James Strachan" <ja...@gmail.com> wrote:
> On 6/2/07, Tom Samplonius <to...@samplonius.org> wrote:
> >
> > How much more work needs to occur to get Stomp protocol support to
> a usable state?
>
> Huh? :) Its very useable right now
James,
Another component of getting Stomp to a usable state, is releasing an ActiveMQ release with Stomp support that doesn't have a serious bug(s). 4.1.1 loses un-acked Stomp messages. This is fixed in the 4.2-SNAPSHOT releases (at least the more current ones).
To really get Stomp out there, we need a release of ActiveMQ with robust Stomp support. I hope this change to calling the next release 5.0 doesn't indicate that release of the next version will be delayed.
And the effort to get the PHP Stomp client fixed so it doesn't use deprecated socket functions, and get it listed on PECL is good. The Perl Net::Stomp library is good already, and available on CPAN. It is kind of a dis-service to Stomp that http://stomp.codehaus.org/Perl recommends an older non-CPAN listed module.
Also, how about your proposal to make persistent messages the default for Stomp? I saw a message from you in the mailing list archives about this? I think this would be perfect for the 5.0 release.
Tom
Tom
Re: Getting Stomp support to a usable state...
Posted by James Strachan <ja...@gmail.com>.
On 6/2/07, Tom Samplonius <to...@samplonius.org> wrote:
>
> How much more work needs to occur to get Stomp protocol support to a usable state?
Huh? :) Its very useable right now
> The biggest issue is lack of any authentication support for Stomp, so anyone with access to the Stomp port can get and send anything. I can't imagine that anyone is using Stomp in production yet.
Stomp has always supported authentication (on the CONNECT) which plugs
into the underlying message brokers security & authentication
mechanism.
> But is anyone working on this? I've looked into the JAAS stuff, and the Stomp code in ActiveMQ. It would take me a week to figure out how to wrap Stomp with JAAS, as I have never worked with JAAS before. I assume the original author of the Stomp support probably skipped authentication. Does anyone have any patches? Or any insight on how to fix this? I really want usable Stomp support in ActiveMQ.
Just use the JAAS plugin in ActiveMQ and you're good to go; the Stomp
code uses whatever security plugin you're using
> The Web Console has similar issues. There is no easy way to password protect it. But if you password protect JMX access, it will break the Web Console.
Thats more of a JMX thing really; you can enable security on JMX. The
web console is also a WAR; so you can use the normal servlet security
stuff too
> I assume that everyone that uses ActiveMQ in production today, is using just OpenWire and JMX, and not the Web Console or Stomp. Is that the case? Or, are users not aware of the default-open security configuration of ActiveMQ?
I know lots of folks using both the Web Console and Stomp in
production with security
--
James
-------
http://macstrac.blogspot.com/
Re: Getting Stomp support to a usable state...
Posted by Tom Samplonius <to...@samplonius.org>.
----- "Tom Samplonius" <to...@samplonius.org> wrote:
> The Web Console has similar issues. There is no easy way to
> password protect it. But if you password protect JMX access, it will
> break the Web Console.
...
I was wrong here. I based my comment on this bug report:
http://www.nabble.com/-jira--Created%3A-%28AMQ-1260%29-web-console-cannot-connect-to-basic-auth-JMX-tf3853700s2354.html#a10917653
But I just setup password protected JMX access, and I had no problems with the Web Console. I assume it must be a Web Console running in a different VM than the broker.
I also documented how to password protect JMX access at: http://activemq.apache.org/how-can-i-monitor-activemq.html
Tom