Author |
Message
|
amita09 |
Posted: Fri Oct 28, 2005 1:43 am Post subject: |
|
|
Novice
Joined: 13 Oct 2005 Posts: 24
|
-Have to use persistent messages.
-Problem is MQ-CICS bridge reads plain passwords from the header.
-API exit seems to be only viable solution.
-I know about TAM, BI...it darn expensive...my wallet is v. small.
I need to investigate on Api Exit only...thats only the solution i guess :(
Thought someone suggested enabling CICS to invoke api exit before reading mq messages. |
|
Back to top |
|
 |
wschutz |
Posted: Fri Oct 28, 2005 2:01 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Do a search for CSQCAPX in the MQ zOS manuals. That will tell you everytinhg you need to know about the exit.
Be aware however that there is a performance penalty for using the exit. it gets called twice for EVERY MQ call made in the region. _________________ -wayne |
|
Back to top |
|
 |
zpat |
Posted: Fri Oct 28, 2005 2:04 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Or authenticate the message in the application, not the infrastructure.
MQ just delivers messages, if you want to check the origin is trusted - use some sort of authentication check such as the shared secret method.
We have done all this sort of stuff for years without the (new) API exit, you can use channel exits to verify messages and insert an authentication token to say that the message is OK to process in your CICS bridge (or just discard messages that fail the verification). |
|
Back to top |
|
 |
amita09 |
Posted: Fri Oct 28, 2005 3:22 am Post subject: |
|
|
Novice
Joined: 13 Oct 2005 Posts: 24
|
zpat and wschutz
which option is easy to implement ? I am suppose to ask our folks to do it on the mainframe. ... i.e. writing an exit.
I hear from the forum and other resources on the net that certain features or exits are not available on the mainframe. API exit is available that seems to be confirmed. What about the other exits...channel exits ? |
|
Back to top |
|
 |
zpat |
Posted: Fri Oct 28, 2005 3:48 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
We use the message exit on the mainframe receiver channel to authenticate messages from other queue managers.
There are send, receive, security and message exits available on all platforms. There are various samples around (including on here) if you look for them. |
|
Back to top |
|
 |
wschutz |
Posted: Fri Oct 28, 2005 6:01 am Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Two comments:
There is no channel message exit if you are using MQ clients to connect to the zOS system. Regular receiver channels do have this exit.
If you do authenticate at the channel exit, then you'll need to change the authentication level in the CICS bridge to either LOCAL (which the runs all tasks as the CICS default user) or IDENTIFY (which runs the task as the userid in the MQMD). Make sure that your security people are okay with switching off VERIFY authentication before you bother with any changes. _________________ -wayne |
|
Back to top |
|
 |
amita09 |
Posted: Wed Nov 02, 2005 3:35 am Post subject: |
|
|
Novice
Joined: 13 Oct 2005 Posts: 24
|
Hi All,
Planning to put together some of the items we discussed for future use for folks who have not had experience writing security stuff for MQ.
I plan to use most of the items from the resources of IBM..basically a crisp document
Anyone interested is welcome to assist. :lol:
2. Approaches to enhancing WebSphere MQ security
2.2 REPLACE THE MQI LIBRARY OR MODIFY ITS BEHAVIOR
2.2.1. Using the API-crossing exit for (e.g. HOST)
2.2.2. Use a vendor-supplied solution
2.3 Use RACF/OBJECT AUTHORITY MANAGER
2.3.1. Restricting Access of MQ Resources
2.3.2. Authority to administer WebSphere MQ on z/OS
2.3.3. Command security and command resource security
2.3.4. Use an alternate user authority
2.3.5. Using Message context
2.3.6. Using Identity context
2.3.7. Using Origin context
2.4 Use CHANNEL EXITS
2.4.1. Writing an authentication exit e.g. MQZAC available on V6
2.5 CHANNEL OVERLAY (e.g. SSL)
2.5.1. Brief steps to configure WebSphere MQ for SSL
2.5.2. Queue Manager's Key Repository
2.5.3. WebSphere MQ Client's Certificate
2.6 Tivoli Access Manager for Business Integration
3. Other possible approaches to connect to CICS
3.1 SOAP based access to CICS
3.2 Java Connector Architecture (JCA)
3.3 Enterprise Java Beans with CICS
3.4 HTTP based access to CICS
3.5 TCP/IP sockets
3.6 Options Summary
4. Available IBM Technologies for connecting to CICS |
|
Back to top |
|
 |
|