| Author |
Message
|
| muthu_tek |
 Posted: Mon Jun 28, 2010 10:17 pm Post subject: Security in Message Broker Product Level |
 |
|
Apprentice
Joined: 21 Jan 2010
Posts: 36
Location: Coimbatore,India
|
If we develop our application as a product using Message Broker,How can we create security for our product?
Like,
1. Avoiding make enhancement in our application
2. Restrict duplication of Bar files
3. Restrict to view internal Broker Level security configuration..etc
Do you have any information to suggest this scenario?
Thanks in advance guys !!!...
-- Marimuthu Udayakumar |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Jun 28, 2010 10:40 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You can set up an access control list for MQSI commands.
Note that when you create more granular controls you must include the permissions from above. E.g. if you permit a Unix group to deploy to an execution group, you must also permit full access to the mqbrkrs group - it won't cascade down the authority. Each list of permissions must be self contained.
The easiest way to manage the ACLs is first to create the execution groups. Then generate an XML file like this:
mqsilistaclentry CFMGR -f acl.txt
Edit the acl.txt to add the permissions then reload it
mqsicreateaclenty CFMGR -f acl.txt
See the IBM manual for the various permissions possible (e.g. view, deploy etc). |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 29, 2010 2:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
ACLs work in version 6.1 and earlier. Broker v7 uses a different administrative model that is more granular and is based on MQ permissions.
There's no way to ensure that someone doesn't deploy the same bar file to multiple execution groups. There's no way to deploy the same message flow resources more than once to the same execution group without either renaming all of the resources or overwriting the existing ones.
muthu_tek, your question indicates that you're at a very basic start of learning message broker. This forum is not an education resource, except indirectly. Please spend time reading the documentation and trying things, it will save you time and effort in both the short term and the long term. |
|
| Back to top |
|
|
| muthu_tek |
| Posted: Tue Jun 29, 2010 2:53 am Post subject: |
|
|
Apprentice
Joined: 21 Jan 2010
Posts: 36
Location: Coimbatore,India
|
Thanks for reply Mr.mqjeff and Mr.zpat.
| Quote: |
| There's no way to ensure that someone doesn't deploy the same bar file to multiple execution groups. There's no way to deploy the same message flow resources more than once to the same execution group without either renaming all of the resources or overwriting the existing ones. |
Absolutely you are right.But My question is that If once delivered our bar file to client after that how can we restrict them to make enhancement on that.can we have any mechanism for this in broker level ? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 29, 2010 3:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| muthu_tek wrote: |
| Absolutely you are right.But My question is that If once delivered our bar file to client after that how can we restrict them to make enhancement on that.can we have any mechanism for this in broker level ? |
No. A bar file is just a zip file, and Broker does not support any mechanisms for signing or encrypting or "locking" a bar file from editing.
If you intend to provide a packaged "solution" for Broker, that you sell as licensed software, the only thing you could do is produce an "installer" that will execute mqsideploy or call the CMP/Administrative API. You can then do things to encrypt or sign or lock the installer package such that the bar file is not visible to the end user.
Otherwise you can constrain your customers via license and support policy - "if you mess with the bar file, you're out of support and you've broken the license".
And there's nothing you can do to lock down the deployed resources. |
|
| Back to top |
|
|
| muthu_tek |
| Posted: Tue Jun 29, 2010 3:30 am Post subject: |
|
|
Apprentice
Joined: 21 Jan 2010
Posts: 36
Location: Coimbatore,India
|
Very informative. Thanks mqjeff. I will try what you suggest.  |
|
| Back to top |
|
|
| muthu_tek |
| Posted: Wed Jun 30, 2010 11:06 pm Post subject: |
|
|
Apprentice
Joined: 21 Jan 2010
Posts: 36
Location: Coimbatore,India
|
| Quote: |
| If you intend to provide a packaged "solution" for Broker, that you sell as licensed software, the only thing you could do is produce an "installer" that will execute mqsideploy or call the CMP/Administrative API. You can then do things to encrypt or sign or lock the installer package such that the bar file is not visible to the end user. |
Even if we come up with the installer, the bar file will get deployed automatically. From where the user can extract the contents and use it at
multiple places .So we need to somehow protect the component from getting reused.
Anyone has an Idea about this ? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Jul 01, 2010 12:55 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Why not put the .BAR file in a password protected zip wrapper.
Then the installer would need a password to deploy the .bar file (or read it from an LDAP or other source).
A 'normal user' could not get at the contents of the bar file without knowing the unlock password.
Just my 2p worth that will no doubt get shot down in flames.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 01, 2010 1:05 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| A question I would ask is why the deployer needs access to more than one execution group? If you devolve WMB deployment and grant access to one execution group only, the problem cannot happen. |
|
| Back to top |
|
|
| muthu_tek |
| Posted: Thu Jul 01, 2010 1:55 am Post subject: |
|
|
Apprentice
Joined: 21 Jan 2010
Posts: 36
Location: Coimbatore,India
|
| Quote: |
| grant access to one execution group only |
May i know how to grant access to one execution group ?
 |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jul 01, 2010 2:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Just configure the MQSI ACLs appropriately. Put the deployment user into a Unix group (I am assuming your config mgr runs on Unix), lets call the group group1. Make sure this user is not in mqbrkrs group.
Create the execution group (lets call it testeg) in broker (lets call it testbk) and generate the ACL xml file as described in my earlier post. You will see a reference to the execution group.
Edit it something like this (only part of the file is shown)
| Code: |
<object>
<objectname>testbk/testeg</objectname>
<objecttype>ExecutionGroup</objecttype>
<aclentry>
<principalname>mqbrkrs</principalname>
<principaltype>GROUP</principaltype>
<accesstype>F</accesstype>
</aclentry>
<aclentry>
<principalname>group1</principalname>
<principaltype>GROUP</principaltype>
<accesstype>D</accesstype>
</aclentry>
</object>
|
Reload the ACL txt as described above. You can also use the mqsicreateaclentry with operands if you don't want to use the XML approach. The result is the same.
When you list the ACL entries you will see this:
| Quote: |
BIP1778I: mqbrkrs - GROUP - F - ConfigManagerProxy - ConfigManagerProxy
BIP1778I: mqbrkrs - GROUP - F - ExecutionGroup - testbk/testeg
BIP1778I: group1 - GROUP - D - ExecutionGroup - testbk/testeg
|
It's all documented in the IBM WMB config/admin manual. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jul 07, 2010 11:36 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jul 08, 2010 12:56 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
zpat, muthu_tek is talking about supplying a package to an external customer that the customer then deploys as they feel like.
muthu_tek is asking about options for securing intellectual properties stored in the contents of the bar file, and how to prevent the customer from extracting the contents of the deployed bar file or deploying it in more than one place.
There's very limited room for that, alas. |
|
| Back to top |
|
|
| muthu_tek |
| Posted: Mon Jul 12, 2010 2:45 am Post subject: |
|
|
Apprentice
Joined: 21 Jan 2010
Posts: 36
Location: Coimbatore,India
|
Thanks Mr.zpat and Mr.mqjeff for giving useful information.
Exactly Mr.mqjeff.There is limited options for that.
We can come up some application level validation for this issue.If we come up this option, then our bar file needs to be rebuilt and again hand over to client. But This is not a good option right guys? |
|
| Back to top |
|
|
|
|
