[Security & JAAS/JBoss] - Re: How to let
by bjolletz
Thanks for your reply!
I am already using a security domain. I'll try to describe my problem better:
For example, I have a bean like this:
| @StateLess
| @SecurityDomain("MySecurityDomain")
| public class MyEntityManagerSLB {
|
| @RolesAllowed({"admin", "developer"})
| public void foo() {
| // Method that a user with admin or developer roles may use
| ...
| }
|
| @RolesAllowed("system")
| public void bar() {
| // Method that only "the system" may use. "The system" referring to scheduled tasks run by a timer.
| ...
| }
| }
|
The problem is to make "the system" able to run the bar method. I can't figure out how to make "the system" authenticated in the "MySecurityDomain".
My first idea was to use @RunAs("system") in the scheduled timer methods , but to be able to use @RunAs in a class, that class must also have a security domain. If I put @SecurityDomain("MySecurityDomain") on the timer class I will get an Authentication Exception. This is understandable, since the code in this class is really not being run by someone logged in to the sucurity domain, but rather from "the system", which is not authenticated in the security domain.
I don't know if I've made this any more understandable, but maybe you understand what I'm trying to do.
/Daniel
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080784#4080784
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080784
19 years
[JBoss Messaging] - Re: JMS Bridge Question
by mclu
I did...
I updated source and destination to 1.4 CR2.
Now this error is gone but there is a new one. Maybe only a different log?
Anyway... here is the log:
| 11:21:22,640 ERROR [ResourceManager] org.jboss.jms.exception.MessagingXAException: A security exception happend!
| org.jboss.jms.exception.MessagingXAException: A security exception happend!
| at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:641)
| at org.jboss.jms.tx.ResourceManager.commit(ResourceManager.java:370)
| at org.jboss.jms.tx.MessagingXAResource.commit(MessagingXAResource.java:238)
| at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:636)
| at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2619)
| at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1779)
| at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:88)
| at com.arjuna.ats.arjuna.AtomicAction.end(AtomicAction.java:216)
| at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:238)
| at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1238)
| at org.jboss.jms.server.bridge.Bridge.access$1700(Bridge.java:62)
| at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1489)
| at java.lang.Thread.run(Thread.java:619)
| Caused by: javax.jms.JMSSecurityException: User: null is not authorized to write to destination incomingSyncRequests
| at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.java:312)
| at org.jboss.jms.server.container.SecurityAspect.handleSendTransaction(SecurityAspect.java:190)
| at sun.reflect.GeneratedMethodAccessor150.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:597)
| at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:121)
| at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
| at org.jboss.jms.server.container.ServerLogInterceptor.invoke(ServerLogInterceptor.java:105)
| at org.jboss.jms.server.endpoint.advised.ConnectionAdvised$sendTransaction_N3268650789275322226.invokeNext(ConnectionAdvised$sendTransaction_N3268650789275322226.java)
| at org.jboss.jms.server.endpoint.advised.ConnectionAdvised.sendTransaction(ConnectionAdvised.java)
| at org.jboss.jms.wireformat.ConnectionSendTransactionRequest.serverInvoke(ConnectionSendTransactionRequest.java:82)
| at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSServerInvocationHandler.java:144)
| at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:734)
| at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:560)
| at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:383)
| at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:165)
| at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:163)
| at org.jboss.remoting.Client.invoke(Client.java:1550)
| at org.jboss.remoting.Client.invoke(Client.java:530)
| at org.jboss.remoting.Client.invoke(Client.java:518)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:186)
| at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:157)
| at org.jboss.jms.client.delegate.ClientConnectionDelegate.org$jboss$jms$client$delegate$ClientConnectionDelegate$sendTransaction$aop(ClientConnectionDelegate.java:221)
| at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
| at org.jboss.jms.client.container.FailoverValveInterceptor.invoke(FailoverValveInterceptor.java:91)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
| at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
| at org.jboss.jms.client.container.ClosedInterceptor.invoke(ClosedInterceptor.java:170)
| at org.jboss.aop.advice.PerInstanceInterceptor.invoke(PerInstanceInterceptor.java:105)
| at org.jboss.jms.client.delegate.ClientConnectionDelegate$sendTransaction_N3268650789275322226.invokeNext(ClientConnectionDelegate$sendTransaction_N3268650789275322226.java)
| at org.jboss.jms.client.delegate.ClientConnectionDelegate.sendTransaction(ClientConnectionDelegate.java)
| at org.jboss.jms.tx.ResourceManager.sendTransactionXA(ResourceManager.java:637)
| ... 12 more
| 11:21:22,656 WARN [Bridge] Failed to send + acknowledge batch, closing JMS objects
| javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
| at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commit(TransactionImple.java:253)
| at org.jboss.jms.server.bridge.Bridge.sendBatch(Bridge.java:1238)
| at org.jboss.jms.server.bridge.Bridge.access$1700(Bridge.java:62)
| at org.jboss.jms.server.bridge.Bridge$BatchTimeChecker.run(Bridge.java:1489)
| at java.lang.Thread.run(Thread.java:619)
|
If I configure the source name and password in my bridge config the name "null" is replaced by "guest"... but still it does not work.
In my source log I can see:
2007-09-04 11:22:13,734 DEBUG [org.jboss.jms.server.security.SecurityMetadataStore] No SecurityMetadadata was available for incomingSyncRequests, using default security config
I wonder why the destination queue was asked here so I debugged at the Source side into the SecurityMetadataStore.getSecurityMetadata() method. I can see that while a message needs to be bridged this method is called with the source queue but also with the incomingSyncRequests which is not deployed on the source because this is the destination.
The SecurityMetadataStore.getSecurityMetadata() is never called on the destination side!?!
Suggestions:
- Is there a problem if I have both servers (source and destination) currently on one machine (localhost)?!?
- While starting up I also receive this JTA Bridge warning.
my tm is an instance of com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@163b85
Any Ideas?
this is my bridge config:
the remote loader was posted already below
| <mbean code="org.jboss.jms.server.bridge.BridgeService"
| name="jboss.messaging:service=Bridge,name=IncommingBridge_A"
| xmbean-dd="xmdesc/Bridge-xmbean.xml">
|
| <!-- The JMS provider loader that is used to lookup the source destination -->
| <depends optional-attribute-name="SourceProviderLoader">jboss.messaging:service=JMSProviderLoaderRemote,name=RemoteJMSProvider_A</depends>
|
| <!-- The JMS provider loader that is used to lookup the target destination -->
| <depends optional-attribute-name="TargetProviderLoader">jboss.messaging:service=JMSProviderLoader,name=JMSProvider</depends>
|
| <!-- Added to be sure that the destination-queue is loaded first-->
| <depends>jboss.messaging.destination:service=Queue,name=incomingSyncRequests</depends>
|
| <!-- The JNDI lookup for the source destination -->
| <attribute name="SourceDestinationLookup">/queue/local_incomingSyncRequests</attribute>
|
| <!-- The JNDI lookup for the target destination -->
| <attribute name="TargetDestinationLookup">/queue/incomingSyncRequests</attribute>
|
| <!-- The username to use for the source connection
| <attribute name="SourceUsername">bob</attribute>
| -->
|
| <!-- The password to use for the source connection
| <attribute name="SourcePassword">cheesecake</attribute>
| -->
|
| <!-- The username to use for the target connection
| <attribute name="TargetUsername">mary</attribute>
| -->
|
| <!-- The password to use for the target connection
| <attribute name="TargetPassword">hotdog</attribute>
| -->
|
| <!-- Optional: The Quality Of Service mode to use, one of:
| QOS_AT_MOST_ONCE = 0;
| QOS_DUPLICATES_OK = 1;
| QOS_ONCE_AND_ONLY_ONCE = 2; -->
| <attribute name="QualityOfServiceMode">2</attribute>
|
| <!-- JMS selector to use for consuming messages from the source
| <attribute name="Selector">specify jms selector here</attribute>
| -->
|
| <!-- The maximum number of messages to consume from the source before sending to the target -->
| <attribute name="MaxBatchSize">5</attribute>
|
| <!-- The maximum time to wait (in ms) before sending a batch to the target even if MaxBatchSize is not exceeded.
| -1 means wait forever -->
| <attribute name="MaxBatchTime">1000</attribute>
|
| <!-- If consuming from a durable subscription this is the subscription name
| <attribute name="SubName">mysub</attribute>
| -->
|
| <!-- If consuming from a durable subscription this is the client ID to use
| <attribute name="ClientID">myClientID</attribute>
| -->
|
| <!-- The number of ms to wait between connection retrues in the event connections to source or target fail -->
| <attribute name="FailureRetryInterval">50000</attribute>
|
| <!-- The maximum number of connection retries to make in case of failure, before giving up
| -1 means try forever-->
| <attribute name="MaxRetries">2</attribute>
|
| <!-- If true then the message id of the message before bridging will be added as a header to the message so it is available
| to the receiver. Can then be sent as correlation id to correlate in a distributed request-response -->
| <attribute name="AddMessageIDInHeader">false</attribute>
|
| </mbean>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080781#4080781
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080781
19 years
[JBoss Seam] - Generel question of understanding (ManyToMany, Hibernate...)
by Eethyo
Hi,
i have a general question in understanding something.
I set up a manytomany relation in my project. (unidirectional).
A user has several roles.
Datatables:
User(Username)(PK))
UserRole(Rolename(PK))
UserToRole((Username(FK),Rolename(FK))(PK))
My join:
@ManyToMany
| @JoinTable(name="USERTOROLE", joinColumns=@JoinColumn(name="username"),
| inverseJoinColumns=@JoinColumn(name="rolename"))
| public List<UserRole> getUserRoles()
| {
| return userRoles;
| }
So i get the list of the user roles in the entity object and i can access it. by Removing something from this list hibernate also deletes it from the database, as it should be.
My problem is the following:
Hibernate first of all deletes everything in in my "UserToRole" Table where the current "username" occurs. After this it deletes it also from the list and inserts everything again to this table so that the list and the table are consistent again.
Is there a way to switch this behaviour that it just deletes this one entry without deleting all entries and then inserting the rest again?
| 10:53:19,095 INFO [STDOUT] Hibernate: delete from dci6fe.USERTOROLLE where username=?
| 10:53:19,111 INFO [STDOUT] Hibernate: insert into USERTOROLE (username, ROLENAME) values (?, ?)
| 10:53:19,111 INFO [STDOUT] Hibernate: insert into USERTOROLE (username, ROLENAME) values (?, ?)
|
as you can see i had three entries... all deleted and 2 inserted again.
Thank you.
Christian
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4080762#4080762
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4080762
19 years