[GLASSFISH-18715] Cannot deny user(s) from producing messages for queues Created: 10/May/12  Updated: 21/Sep/15

Status: Open
Project: glassfish
Component/s: jms
Affects Version/s: 3.1.2
Fix Version/s: 4.1.1

Type: Bug Priority: Major
Reporter: ashie1287 Assignee: David Zhao
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL5, OpenMQ 4.5, PostgreSQL as persistent store, OpenLDAP as user repository


Issue Links:
Dependency
depends on GLASSFISH-21082 For GlassFish standalone client witho... Open
depends on MQ-308 accesscontrol: produce.allow with '*'... Resolved
depends on MQ-354 embedded broker: destination accessc... Resolved
depends on MQ-307 username/password parameters in Conne... Closed
Related
is related to MQ-355 embedded broker: does not take global... Resolved
Tags: 4_0_1-reviewed

 Description   

My broker has the following in etc/accesscontrol.properties

###
version=JMQFileAccessControlModel/100
connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admins

queue..produce.allow.user=
queue..consume.allow.user=

queue.queuename.produce.deny.user=someone
###

What happens:

  • the user 'someone' is allowed to create a producer for queue 'queuename'

What was expected:

  • the user 'someone' should be denied when trying to create a producer for queue 'queuename'

Other notes:

  • if this same type of scenario is repeated for a topic, things work as expected
  • if instead we deny consuming of a queue (e.g. queue.queuename.consume.deny.user=someone) instead of producing of a queue, things work as expected

Seems odd that just this one scenario causes a problem, so it may be worth trying similar ones.



 Comments   
Comment by ashie1287 [ 10/May/12 ]

Did not know that the summary field of the bug uses some kind of markup. Here is what I meant for the accesscontrol.properties file:

###
version=JMQFileAccessControlModel/100
connection.NORMAL.allow.user=*
connection.ADMIN.allow.group=admins

queue.*.produce.allow.user=*
queue.*.consume.allow.user=*

queue.queuename.produce.deny.user=someone
###

Comment by David Zhao [ 06/Jun/13 ]

This partially depends on MQ-307 for applying custom username/password to create connection/producer.

Comment by David Zhao [ 06/Jun/13 ]

Add dependency on MQ-308

Comment by amyk [ 09/Jun/14 ]

Another issue related to this case, discovered by David Zhao, is if a GlassFish JMS connection factory resource is accessed through the following non-standard path, the username/password in ConnectionFactory.createConnection(username, password) doesn't take effect. In this access path, GlassFish connector accesses JMSRA neither in AppClient container nor in EJB/Web container, David, it maybe necessary to require the sign-on information be specified in the JMS resource itself, that is via 'asadmin create-jms-resource --property UserName=username:Password=password' ? - at least that's a workaround.

---------------------------------------
"
Use a standalone GF server with JMS Service of EMBEDDED or LOCAL.
Add a new imq user "imqusermgr add -u myuser -p mypass -g user"
In imq's accesscontrol.properties, add a line "connection.NORMAL.deny.user=guest" to deny guest for getting connection.
Start GF domain
Create JMS connection factory "asadmin create-jms-resource --target server --restype javax.jms.QueueConnectionFactory jms/myFactory ".
Create a JavaSE JMS client application,

Properties jndiProps = new Properties();
jndiProps.put("java.naming.factory.initial", "com.sun.enterprise.naming.impl.SerialInitContextFactory");
jndiProps.put("java.naming.factory.url.pkgs", "com.sun.enterprise.naming");
jndiProps.put("java.naming.factory.state", "com.sun.corba.ee.impl.presentation.rmi.JNDIStateFactoryImpl");
jndiProps.setProperty("org.omg.CORBA.ORBInitialHost", "localhost");
jndiProps.setProperty("org.omg.CORBA.ORBInitialPort", "3700");

ctx = new InitialContext(jndiProps);
qconFactory = (ConnectionFactory) ctx.lookup("jms/myFactory");

Connection qcon = qconFactory.createConnection("myuser", "mypass");
System.out.println(qcon);

Run the client application which is remotely to GF server, then you will get the following security exception that shows the user being authenticated is guest instead of expected myuser which we specified in ConnectionFactory.createConnection(String username, String password) API.

SEVERE: MQJMSRA_MC4001: constructor:Aborting:JMSException on createConnection=[C4084]: User authentication failed: user=guest, broker=localhost:7676(58859), error code: C4084
com.sun.messaging.jms.JMSSecurityException: [C4084]: User authentication failed: user=guest, broker=localhost:7676(58859)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.authenticate(ProtocolHandler.java:1124)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:1041)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:932)
...
Caused by: com.sun.messaging.jms.JMSSecurityException: [C4084]: User authentication failed: user=guest, broker=localhost:7676(58859)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.authenticate(ProtocolHandler.java:1124)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:1041)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:932)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.hello(ConnectionImpl.java:590)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.openConnection(ConnectionImpl.java:2500)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.init(ConnectionImpl.java:1156)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.<init>(ConnectionImpl.java:468)
at com.sun.messaging.jmq.jmsclient.UnifiedConnectionImpl.<init>(UnifiedConnectionImpl.java:66)
at com.sun.messaging.jmq.jmsclient.XAConnectionImpl.<init>(XAConnectionImpl.java:64)
at com.sun.messaging.XAConnectionFactory.createXAConnection(XAConnectionFactory.java:110)
at com.sun.messaging.jms.ra.ManagedConnection.<init>(ManagedConnection.java:204)
... 21 more

"

and David Zhao also commented - 04/Jun/14 07:12 AM (copy/paste from MQ-307) - pointing to GlassFish server code

"
The bug is inside ConnectionManagerImpl.internalGetConnection(...), here is the code snippet.

{format}
} else {
if (prin == null) { <--- should it be "if (cxRequestInfo != null)" ? info = new ClientSecurityInfo(cxRequestInfo); } else {
info = new ClientSecurityInfo(prin);
if (prin.equals(defaultPrin)) {{format}

"
---------------------

Generated at Sat Dec 03 09:39:03 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.