Security requirements for collecting RMF III reports

To collect RMF III reports, the Data Collector or the Log Forwarder must have the permissions to send HTTP requests to the RMF Distributed Data server and access the RMF III data.

Note: In the following examples, HBOLGF is the user ID that is associated with the Data Collector or the Log Forwarder started task. If you use a different user ID, change it to a different value.

Set up AT-TLS for secure communication with Distributed Data Server.If RMF Distributed Data Server is configured with the HTTPS(ATTLS) option, an AT-TLS rule is required to convert the outbound connection from the Z Common Data Provider to RMF DDS to secure communications. For more information about how to set up AT-TLS rules for DDS clients, see Setting up secure communication for the Distributed Data Server.
You must grant the Z Common Data Provider access to the RACF® key ring and the certificate for a successful communication to the Distributed Data Server through AT-TLS.
Client certificate authentication is not required
Client certificate authentication is not required if the HandshakeRole is specified as Server in the AT-TLS server rule for the Distributed Data Server.
The RACF key ring that is specified in the client rule must contain the CA certificate only to validate the server certificate of the Distributed Data Server.
Follow the instructions below to grant the Data Collector or the Log Forwarder access to the key ring depending on if the RDATALIB or FACILITY class is used in your site to protect the shared key ring and the private key of certificates.

If you use the RDATALIB class, run the following commands:
RDEFINE RDATALIB owner.ring.LST UACC(NONE) PERMIT owner.ring.LST CLASS(RDATALIB) ID(HBOLGF) ACCESS(READ) SETROPTS RACLIST(RDATALIB) REFRESH

owner and ring

The value of owner and ring must match the key ring that is specified in the Keyring parameter of TTLSKeyringParms in the AT-TLS client rule.

If you use the FACILITY class, run the following commands:
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(HBOLGF) ACCESS(UPDATE) SETROPTS RACLIST(FACILITY) REFRESH

ACCESS(UPDATE)

If HBOLGF is the owner of the key ring, only READ authority is required.
Client certificate authentication is required
Client certificate authentication is required if the HandshakeRole is specified as ServerWithClientAuth in the AT-TLS server rule for the Distributed Data Server.
Apart from the CA certificate to validate the server certificate of the Distributed Data Server, the RACF key ring that is specified in the AT-TLS client rule must also contain a client certificate.
Follow the instructions below to grant the Data Collector or the Log Forwarder access to the key ring and certificates depending on if the RDATALIB or FACILITY class is used in your site to protect the shared key ring and the private key of certificates.

If you use the RDATALIB class, run the following commands:
RDEFINE RDATALIB <owner>.<ring>.LST UACC(NONE) PERMIT <owner>.<ring>.LST CLASS(RDATALIB) ID(HBOLGF) ACCESS(UPDATE) SETROPTS RACLIST(RDATALIB) REFRESH

owner and ring

The value of owner and ring must match the key ring that is specified in the Keyring parameter of TTLSKeyringParms in the AT-TLS client rule.

ACCESS (UPDATE)

If HBOLGF is the owner of the client certificate in the key ring, only READ authority is required.

If you use the FACILITY class, run the following commands:
RDEFINE FACILITY IRR.DIGTCERT.LISTRING UACC(NONE) PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(HBOLGF) ACCESS(UPDATE) SETROPTS RACLIST(FACILITY) REFRESH

ID(HBOLGF)

If you use the FACLITY class, HBOLGF must be the owner of the client certificate in the key ring.

ACCESS(UPDATE)

If HBOLGF is the owner of the key ring, only READ authority is required.
Authenticate the Z Common Data Provider in Distributed Data Server.You can authenticate the Z Common Data Provider with Distributed Data Server in the following ways;
No authentication

In the DDS HTTP_NOAUTH option, you can specify the host names or TCP/IP addresses that can use the RMF DDS HTTP interface without authentication.

Authentication using the AT-TLS provided client certificate

If you specify the DDS CLIENT_CERT(ACCEPT) option, the DDS will take the user ID from an AT-TLS provided client certificate.
To use this approach, the RMF Distributed Data Server AT-TLS rule must be set with client certificate authentication. For more information about how to set up AT-TLS rules for RMF Distributed Data Server with client certificate authentication, see Setting up secure communication for the Distributed Data Server.

For more information about the security requirements for the Z Common Data Provider to access the RACF key ring and the client certificate, see 1.

Authentication using a user ID and a PassTicket
To use this approach, you must configure PassTicket support for the Distributed Data Server. For more information, see Configuring PassTicket support for the Distributed Data Server.
You must grant the user ID that is associated with the Data Collector or the Log Forwarder the authority to generate a PassTicket for a user. For example, run the following commands:
```
PERMIT IRRPTAUTH.GPMSERVE.* CLASS(PTKTDATA) ID(HBOLGF) ACCESS(UPDATE)  
SETROPTS RACLIST(PTKTDATA) REFRESH
```
By default, the Data Collector or the Log Forwarder generates a PassTicket for the user ID that is associated with the started task. However, the default user, HBOLGF, is normally created as a protected user. A protected user cannot be used for authentication with the Distributed Data Server with a PassTicket. You can use the CDP_PTKT_USER parameter to specify an alternate user with a password to authenticate with the Distributed Data Server with a PassTicket. In the Log Forwarder started task JCL of the following example, USER1 is used to be authenticated with Distributed Data Server together with a PassTicket.
```
//HBOPROC  PROC OPT=''                                                          
//*                                                                            
// EXPORT SYMLIST=(OPT)                                                         
// SET QT=''''                                                                  
// SET OPT=&QT.&OPT.&QT.                                                        
//*                                                                             
//ZLOGOUT EXEC PGM=BPXBATSL,REGION=0M,TIME=NOLIMIT                              
//STDOUT  DD   SYSOUT=*                                                         
//STDERR  DD   SYSOUT=*                                                         
//STDPARM DD   *,SYMBOLS=JCLONLY                                                 
PGM /bin/sh                                                                     
/usr/lpp/IBM/zcdp/v5r1m0/LF/samples/startup.sh                                  
-e /etc/cdpConfig/myPolicy.config.properties                                   
-p 20301 &OPT                                                                   
//*                                           
//STDENV  DD   *                              
JAVA_HOME=/usr/lpp/java/J17.0_64             
CDP_HOME=/var/zcdp/lf
TZ=EST5EDT                                    
CDP_PTKT_USER=USER1                           
//      PEND
```
Granting the Z Common Data Provider access to RMF III data.Unless HTTP_NOAUTH is used to bypass authentication, you must grant the user ID that is used to authenticate with Distributed Data Server access to the RMF III data. For example, run the following commands:
```
RDEFINE FACILITY ERBSDS.MON3DATA UACC(NONE)

PERMIT ERBSDS.MON3DATA CLASS(FACILITY) ID(userid) ACC(READ)         

SETROPTS RACLIST(FACILITY) REFRESH
```
ID(userid)
The userid must be the user that is used by the Data Collector or the Log Forwarder to authenticate with the Distributed Data Server. It might not necessarily be the user ID that is associated with the Data Collector or the Log Forwarder started task. Depending on your configuration, it can be:
- The user that is associated with the AT-TLS provided client certificate when the DDS CLIENT_CERT(ACCEPT) option is used.
- The user that is authenticated with the Distributed Data Server with a PassTicket. It can be the user that is specified in the CDP_PTKT_USER parameter in the Data Collector or the Log Forwarder started task JCL, or the user that is associated with the Data Collector or the Log Forwarder started task when it is not a protected user.