-
1. Re: Topic connection authentication
wdfink Oct 1, 2010 6:53 AM (in response to asterisk)Hi Kay,
in your example is code to get a connection and use a SLSB.
But for me it is unclear whether this is the 'real' code and what happen.
A SecurityException might thrown if you Ejb2TestBean is secured.
Please provide mor information.
-
2. Re: Topic connection authentication
asterisk Oct 1, 2010 8:20 AM (in response to wdfink)Hi,
thanks for your reply!
The code is from my test bean. So it is real test code. I (want) to create a connection to JMS and send messages to a specific topic. Only the code that causes my problem is in the test bean, because I want to isolate the problem.
After that I want to instanciate another bean, but this fails with a SecurityException. The SecurityException is thrown because JBoss tries to auhtenticate my user (works) and the JMS connection (fails) again. The auhtentication for the JMS connection fails, because the credentails are null now and not "user"/"password". So the authentication against the "messaging" realm from login-config.xml fails. I can see this from the trace output of JBoss. It seems that the JMS credentials are valid only for the bean where I created the connection and not for subsequent beans. The user authentication works fine. There is no Exception if I do not execute the line where I connect to JMS. So I can open the JMS connection XOR instanciate another bean, but not both.
I have attached the code of the test bean.
Kind regards
-
TestBean.java.zip 932 bytes
-
-
3. Re: Topic connection authentication
wdfink Oct 1, 2010 9:04 AM (in response to asterisk)So I suppose your TestBean is called from a remote client with authentication, eg. myUser/myPasswd.
In your method you set new credentials by creating the connection (here user/password).
This will overwrite the security settings.
You should allow the topic access for the initial user and do not create a connection with (different) credentials.
-
4. Re: Topic connection authentication
asterisk Oct 1, 2010 10:21 AM (in response to wdfink)Yes, the TestBean is called by a remote client with authentication.
The problem still occurs if I change the call
tcf.createConnection("user", "password") to
tcf.createConnection(). I have attached two log file snippets. jboss_log_1.txt contains the trace log snipped with the Exception in case that I use a user and password for the JMS connection. The file jboss_log_2.txt contains the log in the case that I do not use a user/password. It is only a short snippet, because everything else is more or less the same. The problem is that the principal is null for the connection authentication.
Kind regards
-
jboss_log_2.txt.zip 1.0 KB
-
jboss_log_1.txt.zip 3.1 KB
-
-
5. Re: Topic connection authentication
wdfink Oct 1, 2010 12:04 PM (in response to asterisk)Do you have the topic configured that 'guest' can be use it?
How you topic is configured?
I've looked to my example and:
jndiContext = new InitialContext();
topicConnFactory = (TopicConnectionFactory)jndiContext.lookup(mqFactory);
topic = (Topic)jndiContext.lookup(mqTopic);topicConn = topicConnFactory.createTopicConnection();
topicSession = topicConn.createTopicSession(transactional, javax.jms.Session.AUTO_ACKNOWLEDGE);
topicPublisher = topicSession.createPublisher(topic);ObjectMessage objMessage = topicSession.createObjectMessage();
objMessage.setObject(message);objMessage.setStringProperty(property, value);
topicPublisher.publish(objMessage);this code will work within a SLSB with security.
-
6. Re: Topic connection authentication
asterisk Oct 1, 2010 2:24 PM (in response to wdfink)Hi,
guest only has read access. But the topic itself is not the problem. The code you provided works for me, too. Even if I use user/password for the JMS connection. But what happens if you try to access another bean via local interface after you have created the JMS connection? In my case I get this SecurityException. This happens with the code I have provided above. No need to publish anything. Just connect to JMS and instanciate another bean after that.
As I wrote before, JMS connection XOR bean instanciation works, but not both at the same time. The problem is the combination. So in your code example the bean instanciation is missing. This is what causes my problem.
Kind regards
-
7. Re: Topic connection authentication
wdfink Oct 1, 2010 2:58 PM (in response to asterisk)In my case the Bean was instanciated later, and it works.
I know that change of user/passwd will have such effects (but indeed not with a JMS message).
So ATM I have no idea, I'll look for an example and try to test ...
What comes back to my mind:
Do you test with equal user/passwd for Topic and EJB as I wrote before?
-
8. Re: Topic connection authentication
asterisk Oct 1, 2010 3:24 PM (in response to wdfink)Hi,
thank you very much for your investigation!
Do you use EJB2 or EJB3? I assume that there is a problem in my configuration. But I wonder which part of the configuration this could be. The destination configuration should not be the problem, because I do not use or mention any topic/queue, I just create a connection to JMS. Or it is the deployment descriptor for the bean. But I cant see anything special there.
The code was working on JBoss 4, but not on JBoss 5.
Kind regards
-
9. Re: Topic connection authentication
wdfink Oct 2, 2010 11:16 AM (in response to asterisk)I use EJB2, but we migrate the app to EJB3 and I'm currently investigate the problems, also problems with JB4.3 vs. JB5.x.
I think you found another thing that is something different between the two JBoss versions.
If I find time I'll look after this.
Do you have tested that user/password within JMS can be the same?
Maybe it is a difference if you use TopicConnection instead the general one?
-
10. Re: Topic connection authentication
asterisk Oct 5, 2010 8:47 AM (in response to wdfink)I have tested several combinations of authentication configurations. Using user/pw or not in createConnection(), switching the security domain for JMS to the same as for user authentication, adding the application user as JMS user in the properties files etc. The result is always the same. I always receive a CreateException.
The TopicConnection was used initially. I have read that the generic Connection should be used. So I switched that, but no success.
There must the seomthing in the messaging/security configuration files ot in the deployment descriptor for the EJB2 bean.
-
11. Re: Topic connection authentication
asterisk Oct 6, 2010 5:37 AM (in response to wdfink)Is it possible that you send me your messaging configuration files and the login-config.xml? I would like to check my configuration files.
Thanks!
-
12. Re: Topic connection authentication
jaikiran Oct 6, 2010 6:45 AM (in response to asterisk)It's a known issue with JBoss AS 5.1 (integrated with JBoss Messaging 1.4.x) http://community.jboss.org/thread/44409?tstart=0. I'm trying to find the JIRA which tracks this issue.
-
13. Re: Topic connection authentication
jaikiran Oct 6, 2010 6:59 AM (in response to jaikiran)I haven't yet found that JIRA, but the users in these threads:
http://community.jboss.org/message/142089#142089
http://community.jboss.org/thread/110937?tstart=0
mention that upgrading to HornetQ seems to have solved the issue. (Note that they mention JBoss Messaging 2.0.0 as the upgrade version, which actually means HornetQ).
-
14. Re: Topic connection authentication
asterisk Oct 6, 2010 8:15 AM (in response to jaikiran)I'm not 100% sure that this is the same isse as I have. I added some output like mentioned in one of the threads.
{code}logger.error("Principal: " + mSessionCtx.getCallerPrincipal().getName());
logger.error("role execApplRgt " + mSessionCtx.isCallerInRole("execApplRgt"));
logger.error("role asyncActRgt " + mSessionCtx.isCallerInRole("asyncActRgt"));
logger.error("role userRole " + mSessionCtx.isCallerInRole("userRole"));{code}
With this I get
{code}Principal: myUser
role execApplRgt true
role asyncActRgt false
role userRole false{code}
before calling createTopicConnection("user", "password"); and
{code}Principal: myUser
Subject is null for isCallerInRole Check with role=execApplRgt
role execApplRgt false
Subject is null for isCallerInRole Check with role=asyncActRgt
role asyncActRgt false
Subject is null for isCallerInRole Check with role=userRole
role userRole false
{code}after the call. So there is definately some information lost. But I wonder why I get the SecurityException in the context of the messaging security domain.
Anyway, I think I will try to upgrade messaging like mentioned in the other threads and check whether this solves my problem.
Thank you!