Security for Db2 data sharing

You can use the same authorization mechanisms that are in place for non-data sharing Db2 subsystems to control access to shared Db2 data and to specific data sharing members. Because all members in the group share the same Db2 catalog, an authorization ID has the same granted privileges and authorities for every member of the group. You can also use a security system outside of Db2 (such as RACF® or its equivalent) to control which user IDs can access which members. Some specific considerations apply in Db2 data sharing environments.

SSL support in data sharing

In a data sharing environment, each Db2 member with SSL support must specify a secure port. The secure port for each Db2 member of the group should be the same, just as the DRDA port for each member should also be the same. If each Db2 member specifies a unique secure port, unpredictable behaviors might occur. For example, Sysplex member workload balancing might not work correctly.

Similarly, for Db2 members that are defined as a subset of the data sharing group, each Db2 member that belongs to the subset needs to configure the secure port. You do not need to define a separate unique secure port for the location alias.

For more information, see Configuring the Db2 server for SSL.

Connection and sign-on exit routines

Each member of a data sharing group uses the same names for the connection and sign-on exit routines. As a good practice, all members of a group should share the same exit routines. Sharing avoids authorization anomalies such as:

Primary authorization IDs that are treated differently by different members of the group
Primary authorization IDs that are associated with different sets of secondary IDs by different members of the group

RACF access control module considerations

Start of change All members of a data sharing group use the same name for the access control authorization exit routine. It is a good practice for all members of a data sharing group to share the same exit routine. End of change

Start of change In a data sharing environment, Db2 passes the Db2 group attachment name to the RACF access control module, instead of a Db2 subsystem name. As a result, class names and profile names must be defined with the Db2 group attachment name. When you use the RACF access control module in a data sharing environment, all subsystems in the Db2 data sharing group must share the same RACF database. End of change

For more information, see Defining class names for Db2 objects in the RACF access control module.

DSNR resource class format for WLM in Db2 data sharing

In Db2 data sharing, a different format is used for the DSNR resource class.

Db2 checks the resource authorization by using the DSNR RACF class as follows:

In a Db2 data sharing environment, Db2 checks the following RACF resource name, where db2-groupname is the name of the Db2 data sharing group:
```
db2-groupname.WLMENV.wlm-environment
```
In a non-data sharing environment, Db2 checks the following RACF resource name, where db2-ssid is the Db2 subsystem name:
```
db2-ssid.WLMENV.wlm-environment
```

For more information, see the following topics:

Member-specific and group access with RACF PassTickets

You can use PassTickets for both member-specific and group access to a Db2 data sharing group by adopting an appropriate naming scheme and using a distributed dynamic IP address (DDVIPA) for the group. For more information, see Configuring Db2 data sharing groups for member-specific and group access with RACF PassTickets

Kerberos considerations

Data sharing sysplex environments that use Kerberos security must have a Kerberos Security Server instance running on each system in the sysplex. The instances must either be in the same realm and share the same RACF database, or have different RACF databases and be in different realms.

For more information, see Establishing Kerberos authentication through RACF.