| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WBI v6\ All OS\ Security topology |
« View previous topic :: View next topic » |
| Author |
Message
|
| hopsala |
 Posted: Mon Oct 16, 2006 6:05 pm Post subject: WBI v6\ All OS\ Security topology |
 |
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Yep, it's me. it has been quite a while, hasn't it? I figured that despite my long absence (university+work will do that to ya) I still earned my keep and am entitled to ask something, right? 
So, the simple form of my question is as follows: Is it possible to assign a different userid - and therefore different security permissions - to different flows and/or execution groups?
Now, my search so far yielded a silent "no" (hints, nothing definite), which somewhat worries me. Why? Well, here's the complex version of the question:
I am attempting to construct an air-tight security configuration combining WMQ and WBI; I have divided it into three possible security levels: the first is your regular SSL topology, with pre-set MCAUSER attributes. The second is with context-based channel security, and supposedly should prevent applications from using the wrong resource or sending messages to the wrong destination. The third level is message encryption, which is not relevant to this discussion.
Now, if I want to do this - i.e to prevent Flow1 from opening the same queue as Flow2 - I need seperate security levels for each, but I can't seem to find a way to do this - neither here nor in the infocenter. Maybe I simply haven't found it.
So, any thoughts?
(p.s hope everybody's doing ok!) |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Oct 16, 2006 6:19 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Broker always accesses all MQ resources as the Broker service user.
Broker always accesses any particular ODBC datasource as one particular user. You can point many many ODBC datasources at the same database.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Oct 17, 2006 12:45 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
So what you're saying is that there is no way to restrict access to files, databases, queues or any other resource by execution group/message flow?
Any ideas on how one can implement such restrictions? (seems to me like a very basic product requirement)
Also, if it is as you say (and unfortunately, it seems to be the case) then this segment loses all meaning:
| Quote: |
| Each execution group is started as a separate operating system process, providing an isolated runtime environment for a set of deployed message flows. ... By setting up additional execution groups, you can isolate message flows that handle sensitive data such as payroll records, or security information, or unannounced product information, from other non-sensitive message flows. |
...? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 17, 2006 1:03 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It doesn't lose all meaning. It just might not mean what you think it means.
What it basically says is that one Execution Group = one Process. And processes don't share memory.
But, yes, there is no way to change what user starts a particular execution group, and consequently no way to change what user is running the DataFlowEngine process - this is *always* the Broker service user.
There is nothing that prevents you from running multiple brokers on the same machine, each under different service users.
Other than the ability to maintain the necessary number of queue managers - since brokers can't share queue managers.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Wed Nov 08, 2006 1:11 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
A little update: Opened a PMR with IBM on this; local support couldn't help, so I ended up chatting with one of the developers at Hursley.
Basically, he admitted we were right, and that although this isn't a very common requirement on most sites (usually the broker is "trusted" from the get go) they have gotten similar feedback from other sites, mainly banks and the like, who have stricter information security protocols than most.
For now, no real results, other than a vague promise to find a solution. Possibly, a fix will ensue.
I will keep this thread updated if there is any interesting progress. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
