[Design of Messaging on JBoss (Messaging/JBoss)] - security on management address & replication using JMX
by jmesnil
JBM 2.0 can be managed by sending management message to a special management address.
Security must be enforced on that address to prevent anybody to send potentially destructive management messages (e.g. delete all queues).
I've added a role in jbm-queues.xml so that only the role "admin" can read/write to this address.
However this breaks the replication mechanism used to replicate management operations through JMX.
When the user invokes a management operation through JMX, it is converted to a core message and sent to the management address using a ClientSession. This core message will be send to both the live node and the backup node ensuring both nodes will handle the management operation.
However the created session does not have any user credentials and it won't work anymore now that only a user with the admin role is allowed to interact with the management address.
For this replication to work, a session must be created with a valid admin user for both the live node and the backup node.
This means:
1. having the same admin user defined on both nodes
2. using this admin user when creating the session used to replicate management message
(1) is obvious since both backup and live nodes are expected to share the same set of users
(2) is less obvious: I could query the security manager until I find a right user (with the admin role) and I'll also have to know its password so that I can create a session with his credential.
The security manager does not expose this information (to avoid any security leak)
So I'm thinking to have the code to create a session inside the security manager (JBMSecurityManagerImpl class). e.g.:
| createAdminSession(SessionFactory sf)
| {
| // find a valid admin user
| // use its credentials to create a session from the session factory
| // return the admin session
| }
|
This smells like a Bad Idea(TM) but I've no other ideas at the moment to ensure that management operation using JMX are properly replicated.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207756#4207756
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207756
15 years, 4 months
[Design of JBoss jBPM] - blobs, clobs, text and bytes
by tom.baeyens@jboss.com
I'm adding binary process attachments to jbpm 4. I'm seeing things we need to improve relative to jbpm 3. I'm seeing new possibilities. But I don't see clearly the final solution yet. So please help fill my gaps:
1) chopping or blobs as the default strategy ?
* jBPM 3's capability to chop a blob into discrete sized chops and store a list of those chops turned out to be very portable
* i thought that oracle was one of the most difficult db's with respect to plain BLOBs. But currently in jBPM 4 this seems to work ok.
So the first question is: should we keep the chops as our default solution? Or can we rely on our own QA now and give the BLOB's another try ?
I already build a Lob (Large OBject) hibernate entity that can store a java.lang.String or a byte array in various ways (configurable). Then the handling of blobs and clobs becomes kind of configurable in one central location instead of spread out over the whole jbpm domain model.
2) Another aspect is the large text columns.
Here and there in the process definition datamodel and in the runtime datamodel, there are text columns. Typically string is fine. But for some DB's this is limited to 4K (was it ORA or DB2?). So we ended up truncating those strings.
Every string property that is potentially longer then 255 could a reference to such a Clob entity.
3) The third aspect is process definition vs runtime blobs. Process attachments need a blob, and storage of serialized objects also need a blob. Process attachments need to be cached in hibernate's second level cache. While process variables cannot be cached.
So this doesn't really match with the configurable Blob and Clob approach that i was buiding out. As hibernate cannot make a distinction between the process definition Blobs and the variable Blobs.
All input appreciated : extra requirements, desired improvements, silver bullet solutions,...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207739#4207739
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207739
15 years, 4 months
[Design of POJO Server] - Re: Bringing the trunk profile service changes to 5_x
by scott.stark@jboss.org
"emuckenhuber" wrote :
| Furthermore - what's actually DeploymentTemplate.updateTemplate supposed to do?
| It's not implemented and i'm wondering why you should not call ManagementView.updateComponent ?
| Which is then the last thing referencing a VFSDeployment.
|
The notion was that the template might need to create the attachments that define the deployment after it has a VFSDeployment because it may not have put out enough information in the VirtualFile returned by the first phase when applyTemplate was called. A template may not want to have a complete xml or file based view of the properties what it writes out.
"emuckenhuber" wrote :
| The implementation uses the AbstractDeployment only because there is no DeploymentFactory.getInstance(),
| but shouldn't the AbstractDeployment already be in 5_x?
|
Yes, I found it. I thought it was in jboss-deployers-client-spi.jar, but turns out its in
jboss-deployers-client.jar so its just that the system subproject dependencies did not include this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207722#4207722
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207722
15 years, 4 months
[Design of JBoss jBPM] - Re: Concurrency in jBPM4
by roschmel
Hi,
let my try to explain my thoughts in short:
1) A lot of external system cannot be rolled back (WebService Calls, Legacy Systems...).
2) To make it worse, there are also a lot of system where a retry causes major issues (think about a Bank Transfer - doing it twice may not be good choice)
So in an ideal world you would exactly know where the process execution has crashed. This would mean committing every little step - but this is not really cool stuff.....
So its first about knowing where the process have crashed - therefore you need logging information - just another topic I am currently discussing in the user forum.
And its about minimizing the chance, that a jBPM Transaction is getting rolled back. It is espacially about not considering a rollback as "a normal path of execution" - a rollback is for really bad things happended and not per design. So I think SOSE and retrying as a designed path of execution is simply wrong.
What I would expect:
If I have a process 1 waiting in state-A and waiting in state-B for the callback from an external system and both of them sending me the signal at the same time, I expect to have them executed just one after the other and I do not expect getting exception and letting the engine doing things twice.
We are currently working on a pessimistic locking feature for this situation. But there are two major issues with it:
1) You have to find out what the shared resource is based on the command you get (and its most of the time the parents- parents- ... processinstance)
2) We are doing it in the CommandService EJB and because its a synchronous method call we have to block the thread until we get the look
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4207712#4207712
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4207712
15 years, 4 months