I am trying to get declarative security working in JBoss 4.0.1 using Hibernate 3.0 final. In hibernate.cfg.xml I configured

where "ldap-easynet" is the name of a realm configured in JBoss' login-config.xml. When trying to insert a new net....SalesAct instance, JBoss' security subsystem tells me

i.e. I am logged in as user 'obergner' with the required role 'ewssales' assigned to me, just as the doctor ordered. Then

which seems to tell me that a PolicyConfiguration wit the contextId "ldap-easynet" has been created and in it the role "ewssales" has been granted the permission to do anything with entities of type "net....SalesAct".

Meanwhile, in Hibernate land:

which seems to mirror what is happening inside JBoss.

Still I get an exception when trying to insert a SalesAct instance:

Could someone tell me what I am doing wrong here? I have been trying to figure this out by myself for the last three days, but every time I look into the logs everything seems just fine, and then all of a sudden an exception is thrown.

Thx,

Olaf

Hibernate version: 3.0

Mapping documents: n/a

Code between sessionFactory.openSession() and session.close(): n/a

Full stack trace of any exception that occurs:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.AccessException: SecurityException; nested exception is:
java.security.AccessControlException: access denied HibernatePermission(net.easynet.de.ews.salesact.model.SalesAct:insert)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:325)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:595)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:118)
at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:163)
at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:103)
at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46)
at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55)
at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:97)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:91)
at $Proxy1.createSalesAct(Unknown Source)
at net.easynet.de.ews.salesact.ejb.SalesActServiceSBTest.testCreateSalesActSucceeds(SalesActServiceSBTest.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:474)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:342)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:194)
Caused by: java.rmi.AccessException: SecurityException; nested exception is:
java.security.AccessControlException: access denied HibernatePermission(net.easynet.de.ews.salesact.model.SalesAct:insert)
at org.jboss.ejb.plugins.LogInterceptor.handleException(LogInterceptor.java:370)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:196)
at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
at org.jboss.ejb.Container.invoke(Container.java:870)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:144)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:642)
at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
at sun.rmi.transport.Transport$1.run(Transport.java:153)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.security.AccessControlException: access denied HibernatePermission(net.easynet.de.ews.salesact.model.SalesAct:insert)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at org.hibernate.secure.JACCPreInsertEventListener.onPreInsert(JACCPreInsertEventListener.java:24)
at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:41)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:239)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:223)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:136)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:274)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:675)
at org.springframework.orm.hibernate3.SessionFactoryUtils$SpringSessionSynchronization.beforeCommit(SessionFactoryUtils.java:827)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.triggerBeforeCommit(AbstractPlatformTransactionManager.java:530)
at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:390)
at org.springframework.transaction.interceptor.TransactionAspectSupport.doCommitTransactionAfterReturning(TransactionAspectSupport.java:256)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:67)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
at $Proxy56.createSalesAct(Unknown Source)
at net.easynet.de.ews.salesact.ejb.SalesActServiceSB.createSalesAct(SalesActServiceSB.java:82)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:113)
at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:313)
at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:146)
at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:123)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
... 25 more


Name and version of the database you are using: Firebird 1.5

The generated SQL (show_sql=true): n/a

Debug level Hibernate log excerpt: see above

First, I'm happy to see someone using this, second, I'm sorry you wasted 3 days trying to get it to work, since it is just as likely to be a bug in this *very* new feature as in anything you've done.

Questions:

(1) From the stacktrace, it appears that you are trying to use this inside an EJB, but please just confirm this for me, it won't work outside of one

(2) What happens if you explicitly grant an insert permission instead of the * permission?

I'll go quiz Scott about this too.

First, I'm happy that you responded so quickly.


Yes, from inside a SLSB. Well, actually I'm using Spring to keep everything together, but my Spring beans context is wrapped in a SLSB.



Tried that already. Result is exactly the same, I'm afraid.

One possible hint: When inspecting the JBoss log with nearly everything promoted to 'trace' I can see that upon deploying my ear two other PolicyConfigurations are created, one with a contextId set to the name of the ear and the other with a contextId set to the name of the embedded ejb-jar file. Yet I suspect that this has got nothing to do with the problem at hand, since I don't reference this PolicyConfigurations and no permissions are registered. Very likely something JBoss does by default.

Thx for your efforts,

Olaf

OK, Scott and figured out the problem. I will commit a fix to CVS in about an hour. I'm not sure how long it will take before that is available via readonly CVS.

But please, please try it out and let me know....

I committed the change.

Thx, Gavin, for your efforts. I will check out CVS as soon as possible and try again. And yes, I will definitely let you know if it works. But please don't hold your breath, it'll take a little time.

Olaf

Sorry, Gavin, that didn't solve my problems. I can see in the logfiles the change from HibernatePermission to EJBMethodPermission, but the outcome is exactly the same. From a casual glance at the javadocs for EJBMethodPermission it _seems_ as if this concept is not applicable in this situation. There is no method on an EJB being called. In fact, the parties involved - the entity to persist and the Hibernate session - seem to be living - quite happily, as it seems - outside the EJB spec, i.e. JBoss has no concept by which to reference these objects.

That being said, I don't know anything about JACC and how it interacts with resources deployed inside an EJB container. If I understand its purpose correctly it _should_ be possible to achieve the desired behaviour. I'll try to figure out what's going wrong here myself, but since I am more of a J2EE application programmer it might take some time. I'll probably have to set up a decent debugging environment and see what's happening when that exception is thrown.

On a different note: am I the only one who's got the impression that many exceptions thrown by the Java runtime leave something to be desired in terms of detailed explanations of the circumstances that led to the error? The message

is completely useless when it comes to diagnosing the root cause of the error.

I just had a quick look at the code around line 264 in java.security.AccessControlContext (method checkPermission(Permission)) where the Exception is thrown (JDK 1.5 Update 2):



Given the exception message above this seems to imply that

(a) the correct Permission is passed into the method, and

(b) the Permission passed in is checked against a wrong set of Permissions (if context[] contains a non-HibernatePermission instance or a HibernatePermission for another entity an exception will be thrown).

Just trying to be helpful, might be completely off track, though.

Still, I would like to thank you for your prompt feedback.

Cheers,

Olaf

I have similar problem. It seems that nobody uses this functionality - no post covering this topic!

I run my application as single SLSB with declarative security configured. It runs on JBoss 4.0.2 . I tried to install any JACC listener and grant role "admin" to make "insert" action available to this role. "admin" is also defined in ejb-jar.xml and used in <method-permission> tag.
EJB client with "admin" role invokes secured EJB method without any problem (so it is authorized and authenticated properly) but saving model always ends with the following exception :



My hibernate.cfg.xml file (part of it) :

Oh, I forgot to write hibernate library version I used. It was the newest 3.0.3 version. I've also tested it on the newest CVS version - with no result.

Yes, I think we may safely say that JACC support is broken in Hibernate 3. I am still planning on finding out the root cause but right now I am buried in work. There will come a time when I get a chance to take up all those loose ends ...

Cheers,

Olaf

I've just created new JIRA issue:
http://opensource.atlassian.com/project ... se/HHH-488

I still have the described problems when using JBoss 4.02 and Hibernate 3.1.3.
I have created an application poily named "test" in the login-config.xml and in hibernate cfg.xml this is also the name of the context attribute of the security element. From the thrown EJBMethodPermission exception when trying to save a object, i can see that i have the required role. Does anybody have a hint?
Thanks
Fabian