This content has been marked as final.
Show 2 replies
-
1. jbossmq with CallerIdentityLoginModule
philc Dec 8, 2004 11:52 AM (in response to philc)I am trying to get jbossmq to use my EJB's Security information to create, write and read topics. I have 2 Security Domains:
1. MyEJBSecurityDomain configured with an LdapLoginModule
2. jbossmq configured with<application-policy name="jbossmq"> <authentication> <login-module code="com.brockhousecooper.tw.ejb.server.authentication.CallerIdentityLoginModule" flag="required"> <module-option name = "managedConnectionFactoryName">jboss.jca:name=JmsXA,service=TxCM</module-option> </login-module> </authentication> </application-policy>
I use this code to login from within an MBean and create a TopicConnectionlc = new LoginContext("client-login", handler); lc.login(); log.info("principal before: " + SecurityAssociation.getPrincipal()); connection = conFactory.createTopicConnection();
the log prints "principal before: admin" before creating the topic, however, jbossmq's Security Interceptor reports:
[ServerSecurityInterceptor] Autenticating user null/null
and the calls GetPrincipalInfoAction.getPrincipal() and GetPrincipalInfoAction.getCredential() inside CallerIndentityLoginModule both return null.
Are my login modules badly configured or is this a bug in CallerIdentityLoginModule? -
2. 3851001
starksm64 Dec 8, 2004 11:52 AM (in response to philc)Ah, now I see what you're saying. Thanks.
I suppose there'd be no good way to cluster the injected abort state without doing an mbean lookup on every call rather than injecting to a static field in the interceptor from the jmx manager, though. That's dealable with, however, since in a cluster we'll presumably know what node the problem thread is running on.