"However, if you don't, Java cannot determine the signed on userid... "
Why? Is this just the way JAVA is? Or is there a way to configure your JAVA environment so that it can get the ID? Peter Potkay IBM MQSeries Certified Specialist, Developer [EMAIL PROTECTED] X 77906 -----Original Message----- From: Tony Reddiough [mailto:[EMAIL PROTECTED]] Sent: Thursday, July 11, 2002 1:21 PM To: [EMAIL PROTECTED] Subject: Re: MQSeries Client Security If you provide a userid (specified within the Java program itself) it will be checked. However, if you don't, Java cannot determine the signed on userid and so passes nothing to the server. In this case, the listener has to either reject the channel start request or simply let it through. IBM chose to do the latter. If you then look at the messages on the queue, in the MQMD, you'll see the userid of the listener which is usually mqm or MQUSR_ADMIN or something very powerful. Of course you cannot rely on Mr Hacker to specify his userid from within his Java program - he might not be that helpful ! I successfully managed to put a message to the SYSTEM.DEFAULT.LOCAL.QUEUE on my clients production queue manager which he thought was well protected. He was not impressed ! Since then he has either deleted all SVRCONN channels or disabled them by coding MCAUSER(wibble) where wibble has no authority. This overrides all other userids but does mean everyone gets the same treatment. I was pretty shocked when I discovered this but IBM thought it was perfectly acceptable. They always recommend security exits anyway. Hope this helps, Tony. Tony Reddiough Certified MQSeries Specialist Tel: +44 (0) 1793 616100 Mobile: +44 (0) 7711 264281 www.alphacourt.com <http://www.alphacourt.com> Alphacourt - "The Integration Practice" -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of Robert Broderick Sent: 11 July 2002 17:18 To: [EMAIL PROTECTED] Subject: Re: MQSeries Client Security I have a question. How does the JAVA client application bypass the security checking on the server. If the svrconn channel has blanks in the MCAUSER attribute doesn't the server have to authenticate the userid in the message against the server. We have JAVA apps here and that seems the way they perform. Am I missing something?? bobbee >From: Tony Reddiough <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: MQSeries Client Security >Date: Thu, 11 Jul 2002 15:20:15 +0100 > >Bill, > I recently discovered a "limitation" with client security on the >distributed platforms, not sure if it applies to OS/390 but I wouldn't be >at >all suprised. > >When a client attaches through the SVRCONN channel, the userid under which >the client application is running will be assumed by the server end (i.e. >OS/390 in your case). So, if you client is an win2000 application running >under userid "fred" then that user will be authenticated at the OS/390 to >make sure it can connect to the queue manager, put messages on the specific >queue etc. So, the upshot is, you have to define "fred" to OS/390 and >grant >it permission to your queues. > >This is fine. However, if the client application is written in Java, it >manages to skip all this checking and can therefore access whatever it >likes >on your OS/390 queue manager. > >Ok, you say, my program isn't written in Java. BUT you also have to worry >about the mallicious guy who is hacking in - his program might be written >in >java. > >Bottom line, all SVRCONN channels provide access to the queue manager where >they are defined without going through a securty check. Since all queue >managers define SYSTEM.DEFAULT.SVRCONN when they are created (and most >people don't delete them), I reckon I could put a message onto most queue >managers in the world unchallenged given access to the network. > >Bottom, bottom line, you need security exits ! > >Tony Reddiough >Certified MQSeries Specialist >Alphacourt Limited >Tel: +44 (0) 1793 616100 >Mobile: +44 (0) 7711 264281 >www.alphacourt.com <http://www.alphacourt.com> > >Alphacourt - The Integration Practice > > >-----Original Message----- >From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of >Conklin, William >Sent: 11 July 2002 13:33 >To: [EMAIL PROTECTED] >Subject: MQSeries Client Security > > >Hi All, >I'm in the process of setting up a Windows 2000 MQSeries Client to access a >single q on OS/390 using one qmgr. (we use Top Secret as our mainframe >security package). I want to be able to secure the q so that only one >application can access it. In the manual they discuss Transport level >security, Channel security exits, and Identification passed to a channel >exit. Or, should I look at the OAM (Object Authority Manager) as a way of >securing this? Several users will be accessing the application with >specific >and generic user ids. > >Thanks a MILLION in advance for any ideas you may have on the topic. > >Bill C. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
