Configuring your system to use the Secure Sockets Layer (SSL) - Middleware News
Security installation tasks
================
When WebSphere MQ is first installed and customized, you must perform these security-related tasks:
1. Set up WebSphere MQ data set and system security by:
* Authorizing the queue manager started-task procedure xxxxMSTR and the distributed queuing started-task procedure xxxxCHIN to run under RACF.
* Authorizing access to queue manager data sets.
* Authorizing access to resources for those user IDs that will use the queue manager and utility programs.
* Authorizing access for those queue managers that will use the coupling facility list structures.
* Authorizing access for those queue managers that will use DB2.
2. Set up RACF definitions for WebSphere MQ security.
3. If you want to use the Secure Sockets Layer (SSL), prepare your system to use certificates and keys (see Configuring your system to use the Secure Sockets Layer (SSL)).
Setting up WebSphere MQ data set security
==========================
The possible users of WebSphere MQ data sets include:
* The queue manager itself.
* The channel initiator
* WebSphere MQ administrators who need to create WebSphere MQ data sets, run utility programs, and so on.
* Application programmers, who need to use the WebSphere MQ-supplied copybooks, include data sets, macros, and so on.
* Applications involving one or more of the following:
o Batch jobs
o TSO users
o CICS regions
o IMS regions
* Data sets CSQOUTX and CSQSNAP
* Dynamic queues SYSTEM.CSQXCMD.*
For all these potential users, protect the WebSphere MQ data sets with RACF.
You must also control access to all your 'CSQINP' data sets.
RACF authorization of started-task procedures
=============================
Some WebSphere MQ data sets should be for the exclusive use of the queue manager. If you protect your WebSphere MQ data sets using RACF, you must also authorize the queue manager started-task procedure xxxxMSTR, and the distributed queuing started-task procedure xxxxCHIN, using RACF. To do this, use the STARTED class. Alternatively, you can use the started procedures table (ICHRIN03), but then you need to IPL your z/OS system before the changes take effect.
For more information, see the z/OS SecureWay Security Server RACF System Programmer's Guide.
The RACF user ID identified must have the required access to the data sets in the started-task procedure. For example, if you associate a queue manager started task procedure called CSQ1MSTR with the RACF user ID QMGRCSQ1, the user ID QMGRCSQ1 must have access to the z/OS resources accessed by the CSQ1 queue manager.
The RACF user IDs associated with the queue manager and channel initiator started task procedures should not have the TRUSTED attribute set.
Setting up WebSphere MQ resource security
========================
The possible users of WebSphere MQ resources, such as queues and channels, are the same as the possible users of WebSphere MQ data sets, as listed above. For all these potential users, protect the WebSphere MQ resources with RACF. In particular, note that the channel initiator needs access to various resources, as described in Chapter 17, Security considerations for distributed queuing, and so the user ID under which it runs must be authorized to access these resources.
If you are using a queue-sharing group, the queue manager might issue various commands internally, so the user ID it uses must be authorized to issue such commands. The commands are:
* DEFINE, ALTER, and DELETE for every object that has QSGDISP(GROUP)
* START and STOP CHANNEL for every channel used with CHLDISP(SHARED)
Configuring your system to use the Secure Sockets Layer (SSL)
====================================
If you want to use the Secure Sockets Layer (SSL) for channel security, there are a number of tasks you need to perform to set this up on your system. (See the WebSphere MQ Security book for more information about SSL.)
1. Create a key ring in RACF to hold all the keys and certificates for your system, using the RACF RACDCERT command. For example:
RACDCERT ID(QM1) ADDRING(QM1RING)
The ID should be the channel initiator address space.
2. Create a digital certificate for each queue manager, using the RACF RACDCERT command.
The label of the certificate must be of the form ibmWebSphereMQqmgr-name, so in this example it is ibmWebSphereMQQM1.
For example:
RACDCERT ID(QM1) GENCERT
SUBJECTSDN(CN('username') O('IBM') OU('departmentname') C('England'))
WITHLABEL('ibmWebSphereMQQM1')
3. Connect the certificate in RACF to the key ring, using the RACF RACDCERT command. For example:
RACDCERT CONNECT(ID(QM1) LABEL('ibmWebSphereMQQM1') RING(QM1RING))
You also need to connect any relevant signer certificates (from a Certification Authority) to the key ring. For example:
RACDCERT ID(userid)
CONNECT(CERTAUTH LABEL('My CA') RING(ring-name) USAGE(CERTAUTH))
4. On each of your queue managers, use the WebSphere MQ ALTER QMGR command to specify the key repository that the queue manager needs to point to. For example:
ALTER QMGR SSLKEYR(QM1RING)
5. Certificate Revocation Lists (CRLs) allow the Certification Authorities to revoke certificates that can no longer be trusted. CRLs are stored in LDAP servers. To access this list on the LDAP server, you first need to create an AUTHINFO object of AUTHTYPE CRLLDAP, using the WebSphere MQ DEFINE AUTHINFO command. For example:
DEFINE AUTHINFO(LDAP1)
AUTHTYPE(CRLLDAP)
CONNAME(ldap.server(389))
LDAPUSER('')
LDAPPWD('')
In this example, the certificate revocation list is stored in a public area of the LDAP server, so the LDAPUSER and LDAPPWD fields are not neccessary.
Next, put your AUTHINFO object into a namelist, using the WebSphere MQ DEFINE NAMELIST command. For example:
DEFINE NAMELIST(LDAPNL) NAMES(LDAP1)
Finally, associate the namelist with each queue manager, using the WebSphere MQ ALTER QMGR command. For example:
ALTER QMGR SSLCRLNL(LDAPNL)
6. Set up your queue manager to run SSL calls, using the WebSphere MQ ALTER QMGR command. This defines server subtasks that handle SSL calls only, which leaves the normal dispatchers to continue processing as normal without being impacted by any SSL calls. You must have at least two of these subtasks. For example:
ALTER QMGR SSLTASKS(8)
This change only takes effect when the channel initiator is restarted.
7. Specify the cipher specification to be used for each channel, using the WebSphere MQ DEFINE CHANNEL or ALTER CHANNEL command. For example:
ALTER CHANNEL(LDAPCHL)
CHLTYPE(SDR)
SSLCIPH(RC4_MD5_US)
Security installation tasks
================
When WebSphere MQ is first installed and customized, you must perform these security-related tasks:
1. Set up WebSphere MQ data set and system security by:
* Authorizing the queue manager started-task procedure xxxxMSTR and the distributed queuing started-task procedure xxxxCHIN to run under RACF.
* Authorizing access to queue manager data sets.
* Authorizing access to resources for those user IDs that will use the queue manager and utility programs.
* Authorizing access for those queue managers that will use the coupling facility list structures.
* Authorizing access for those queue managers that will use DB2.
2. Set up RACF definitions for WebSphere MQ security.
3. If you want to use the Secure Sockets Layer (SSL), prepare your system to use certificates and keys (see Configuring your system to use the Secure Sockets Layer (SSL)).
Setting up WebSphere MQ data set security
==========================
The possible users of WebSphere MQ data sets include:
* The queue manager itself.
* The channel initiator
* WebSphere MQ administrators who need to create WebSphere MQ data sets, run utility programs, and so on.
* Application programmers, who need to use the WebSphere MQ-supplied copybooks, include data sets, macros, and so on.
* Applications involving one or more of the following:
o Batch jobs
o TSO users
o CICS regions
o IMS regions
* Data sets CSQOUTX and CSQSNAP
* Dynamic queues SYSTEM.CSQXCMD.*
For all these potential users, protect the WebSphere MQ data sets with RACF.
You must also control access to all your 'CSQINP' data sets.
RACF authorization of started-task procedures
=============================
Some WebSphere MQ data sets should be for the exclusive use of the queue manager. If you protect your WebSphere MQ data sets using RACF, you must also authorize the queue manager started-task procedure xxxxMSTR, and the distributed queuing started-task procedure xxxxCHIN, using RACF. To do this, use the STARTED class. Alternatively, you can use the started procedures table (ICHRIN03), but then you need to IPL your z/OS system before the changes take effect.
For more information, see the z/OS SecureWay Security Server RACF System Programmer's Guide.
The RACF user ID identified must have the required access to the data sets in the started-task procedure. For example, if you associate a queue manager started task procedure called CSQ1MSTR with the RACF user ID QMGRCSQ1, the user ID QMGRCSQ1 must have access to the z/OS resources accessed by the CSQ1 queue manager.
The RACF user IDs associated with the queue manager and channel initiator started task procedures should not have the TRUSTED attribute set.
Setting up WebSphere MQ resource security
========================
The possible users of WebSphere MQ resources, such as queues and channels, are the same as the possible users of WebSphere MQ data sets, as listed above. For all these potential users, protect the WebSphere MQ resources with RACF. In particular, note that the channel initiator needs access to various resources, as described in Chapter 17, Security considerations for distributed queuing, and so the user ID under which it runs must be authorized to access these resources.
If you are using a queue-sharing group, the queue manager might issue various commands internally, so the user ID it uses must be authorized to issue such commands. The commands are:
* DEFINE, ALTER, and DELETE for every object that has QSGDISP(GROUP)
* START and STOP CHANNEL for every channel used with CHLDISP(SHARED)
Configuring your system to use the Secure Sockets Layer (SSL)
====================================
If you want to use the Secure Sockets Layer (SSL) for channel security, there are a number of tasks you need to perform to set this up on your system. (See the WebSphere MQ Security book for more information about SSL.)
1. Create a key ring in RACF to hold all the keys and certificates for your system, using the RACF RACDCERT command. For example:
RACDCERT ID(QM1) ADDRING(QM1RING)
The ID should be the channel initiator address space.
2. Create a digital certificate for each queue manager, using the RACF RACDCERT command.
The label of the certificate must be of the form ibmWebSphereMQqmgr-name, so in this example it is ibmWebSphereMQQM1.
For example:
RACDCERT ID(QM1) GENCERT
SUBJECTSDN(CN('username') O('IBM') OU('departmentname') C('England'))
WITHLABEL('ibmWebSphereMQQM1')
3. Connect the certificate in RACF to the key ring, using the RACF RACDCERT command. For example:
RACDCERT CONNECT(ID(QM1) LABEL('ibmWebSphereMQQM1') RING(QM1RING))
You also need to connect any relevant signer certificates (from a Certification Authority) to the key ring. For example:
RACDCERT ID(userid)
CONNECT(CERTAUTH LABEL('My CA') RING(ring-name) USAGE(CERTAUTH))
4. On each of your queue managers, use the WebSphere MQ ALTER QMGR command to specify the key repository that the queue manager needs to point to. For example:
ALTER QMGR SSLKEYR(QM1RING)
5. Certificate Revocation Lists (CRLs) allow the Certification Authorities to revoke certificates that can no longer be trusted. CRLs are stored in LDAP servers. To access this list on the LDAP server, you first need to create an AUTHINFO object of AUTHTYPE CRLLDAP, using the WebSphere MQ DEFINE AUTHINFO command. For example:
DEFINE AUTHINFO(LDAP1)
AUTHTYPE(CRLLDAP)
CONNAME(ldap.server(389))
LDAPUSER('')
LDAPPWD('')
In this example, the certificate revocation list is stored in a public area of the LDAP server, so the LDAPUSER and LDAPPWD fields are not neccessary.
Next, put your AUTHINFO object into a namelist, using the WebSphere MQ DEFINE NAMELIST command. For example:
DEFINE NAMELIST(LDAPNL) NAMES(LDAP1)
Finally, associate the namelist with each queue manager, using the WebSphere MQ ALTER QMGR command. For example:
ALTER QMGR SSLCRLNL(LDAPNL)
6. Set up your queue manager to run SSL calls, using the WebSphere MQ ALTER QMGR command. This defines server subtasks that handle SSL calls only, which leaves the normal dispatchers to continue processing as normal without being impacted by any SSL calls. You must have at least two of these subtasks. For example:
ALTER QMGR SSLTASKS(8)
This change only takes effect when the channel initiator is restarted.
7. Specify the cipher specification to be used for each channel, using the WebSphere MQ DEFINE CHANNEL or ALTER CHANNEL command. For example:
ALTER CHANNEL(LDAPCHL)
CHLTYPE(SDR)
SSLCIPH(RC4_MD5_US)
Comments
Post a Comment