| Author |
Message
|
| javagals |
 Posted: Thu Aug 14, 2008 6:52 am Post subject: How to add UserIdentifier (MQMD) of Message using rcvExit |
 |
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
Hello,
Could someone please give me a valid answer on how to add/update UserIdentifer field of MQMD of a message using receiveExit.
I have written a receive exit program which is required to set UserIdentifier field of MQ Message descriptor. I can extract the user id field from channel definition but not able to update it.
Regards,
Sridhar Javagal |
|
| Back to top |
|
 |
| David.Partridge |
| Posted: Fri Aug 15, 2008 12:21 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
Sridhar,
Even if you do change the MQMQ.UserIdentifier field in an incoming MQPUT request buffer, and set the exit code so that the channel uses the modified exit buffer on output, the user under which the channel runs will still need to be authorised to use set context in order for this to have any effect, and you'll need to modify the PMO in the buffer as well to request that the context be used.
As I said in my other posts - I think you are approaching this from the wrong direction - just because you potentially *can* do something using MQ exits doesn't mean that you should.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| javagals |
| Posted: Fri Aug 15, 2008 3:23 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
Well said sir.
I am looking for an easy, maintainable solution and I want my clients to do minimum work. As a service provider I would like to give secure, scalable and highly available solution.
Having said that,
I still have not found a clear answer to my question.
1. Is it a good idea to use receiver Exit to update the message header. Please keep in mind that I want my clients to enter username/pwd and send the business msg. Nothing more.
2. If this is a good idea then how do I do it? If there is a pseudo code please let me know.
Thank you,
Sridhar Javagal |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Fri Aug 15, 2008 3:43 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
> Is it a good idea to use receiver Exit to update the message header.
If I've not made it clear enough already, no I don't think this is a good idea.
I also think that the proposed userid/password method of authentication is totally insecure.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| javagals |
| Posted: Fri Aug 15, 2008 5:04 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
|
| Back to top |
|
|
| javagals |
| Posted: Wed Sep 03, 2008 6:27 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
Hello Guys,
Thanks for your help. I have managed to create receiver exit which successfully updates format, userid and remote client ip in message header.
Thank you,
Sridhar Javagal
Solution design and delivery
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Wed Sep 03, 2008 6:40 am Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
Just hope and pray that you never get me doing an MQ security audit on your system 
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| javagals |
| Posted: Fri Sep 05, 2008 5:39 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
Why? Isnt it secure?
I am asking users to connect to channel using an id and password. I am checking this id in my local ldap server and authenticating them. I am also applying setmqaut on each channel, qmgr and alias queues so that each carrier has authorization to connect to a specific queue.
I am extracting username, format and remote client ip address and passing to next component for further business use.
Note: No SSL because clients dont want to do it.
Regards,
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Sep 05, 2008 7:52 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
| javagals wrote: |
| Why? Isnt it secure? |
David has extensive MQ security knowledge along with the fact he was a CTO for a Vendor who sells a security product. Hence, here's what he's probably thinking:
- Are you sending a plain text password?
- A security exit and a receive exit are 2 separate beasts and are called at different points - you are thinking linear
- You are checking the UserId against a LDAP but setmqaut sets ACL against a local OS account. So you have duplicated the UserId?
- In your scenario, an application can connect with a UserId "fred" with very low privileges and then switch the UserId to "barney" (higher privileges) or "mqm" and then do whatever they want.
Food for thought.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| David.Partridge |
| Posted: Sun Sep 07, 2008 11:28 pm Post subject: |
|
|
Master
Joined: 28 Jun 2001
Posts: 249
|
Even if the password is not being sent in clear text, I think I'd lay fairly good money that any mechanism that is being used for "masking" the password is unlikely to be cryptographically sound and therefore readily subject to compromise.
Or, put another way, it's highly likely that it will be possible without too much work to connect as mqm. Once you've done that it's a few short steps to (for example) get a remote command prompt up on the client workstation as mqm.
That's why I would strongly advise the use of SSL authentication against a low privilege SVRCONN channel, and locking down the other SVRCONN channels as well.
_________________
Cheers,
David C. Partridge |
|
| Back to top |
|
|
| javagals |
| Posted: Mon Sep 08, 2008 2:19 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
Guys, I appreciate your help on this issue.
- Are you sending a plain text password.
It is business requirement to allow clients to connect using both SSL and non SSL mode. Clients who connect in non-SSL mode use uid/pwd in a secure ipsec vpn network.
- A security exit and a receive exit are 2 separate beasts and are called at different points - you are thinking linear
Yes. I am aware of this fact. security exit is used for identity and authentication. receiver exit is used to add uid/remote client ip to msg header for further business use.
- You are checking the UserId against a LDAP but setmqaut sets ACL against a local OS account. So you have duplicated the UserId?
Nope. I am not duplicating the account as same LDAP server is used for unix authentication.
- In your scenario, an application can connect with a UserId "fred" with very low privileges and then switch the UserId to "barney" (higher privileges) or "mqm" and then do whatever they want.
Yes. I am aware of this. MCA user is changed so that incoming client has limited functionality to access.
Design makes sure clients can only put messages on autherised queues and thier identity and authentication is checked before accepting connection.
Business requirement drives us in this direction.
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| vchenna |
| Posted: Thu Jul 02, 2009 7:42 am Post subject: Hi there |
|
|
Novice
Joined: 29 Jun 2009
Posts: 18
|
Javagals,
I m encountering the same issue , I wan to change my user from mqm to FMMI in the message header once its puts the message on the queue, Since i m new to User Exits can you please provide me the solution or the program and let me know what are the configuration that I need to do to achieve it successfully |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 02, 2009 7:58 am Post subject: Re: Hi there |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| vchenna wrote: |
| I m encountering the same issue , I wan to change my user from mqm to FMMI in the message header once its puts the message on the queue, Since i m new to User Exits can you please provide me the solution or the program and let me know what are the configuration that I need to do to achieve it successfully |
If you didn't like the advice I gave you here then you should have said.
It's also worth pointing out that exits are an advanced topic, with the possibility to cause enormous damage if badly written, configured or implemented. Certainly not something you just do without a raft of testing.
In your case I think it's a sledgehammer to crack a nut.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
