Setting metadata store access permissions

Permission hierarchy of DBB objects

Users set access permissions on the metadata store high-level objects that are stored in the DBB database. These permissions also control the access permissions of the enclosed objects. The hierarchy is as follows:

Setting access permissions to DBB objects

Three fields on a DBB high-level object can be used to control access permissions to DBB objects: Owner, Team, and Permission. Use these fields when you create or modify high-level objects in the database.

Granting roles to users

You must assign one of the following roles to each DBB user by connecting individual users or groups to the listed RACF groups. These three roles are defined by DBB to control user authority to read and write DBB objects.

Defining DBB RACF groups

For DBB to recognize a user's connection to a RACF group, the group must have an OMVS group ID. When you define the default DBB RACF groups from the table above or when you define your own groups for the DBB user roles (see Mapping RACF groups to roles), you must include an OMVS group ID on the group definition. For example:

ADDGROUP DBBADMNS OMVS(GID(<group id>))

Once the group is defined, the user must be connected to the group.

CONNECT <admin user> GROUP(DBBADMNS)

See the sample jcl, /usr/lpp/IBM/dbb/conf/BGZRACF.jcl, for how to create groups and connect members.

Mapping RACF groups to roles

DBB has three roles: DBBADMNS, DBBUSERS, and DBBGUEST. In DBB 2.0, DBB required that RACF groups that matched the role names were defined. In DBB 2.0.1 and later, a database mapping table can be used to map one or more existing RACF groups to a DBB role. By default, the mapping is one to one and the role equals the RACF group to maintain consistency with DBB 2.0. These mappings can be replaced and others can be added as necessary.

NOTE: All the users that run DBB scripts that access the Db2 metadata store should only be granted SELECT authority to the DBB_ROLE_MAPPING table to maintain integrity of the mapping. Administrators that add and remove roles to RACF mappings should be granted DELETE, INSERT, SELECT, UPDATE authority to the DBB_ROLE_MAPPING table.

Use the following command to add a DBB role to RACF mappings. Each row in the table represents a mapping and there can be more than one mapping per role. The DBB_ROLE column must be one of the DBB roles: DBBADMNS, DBBUSERS, and DBBGUEST. Any other value will be ignored.

SET SCHEMA DBBZ; 
INSERT INTO DBB_ROLE_MAPPING (DBB_ROLE, RACF_GROUP)
  VALUES ('DBBADMNS', '<racfgroup>');

Database user versus DBB user

Access to the data in the DBB database can be controlled in two ways:

• Database user: Access for connecting to the DBB database, which is typically associated with a technical user ID (that is, a generic account for technical purposes that is not tied to a specific user). This is configured by using Db2 user IDs and by granting users access to the database tables.
• DBB user: Access for running DBB APIs and accessing DBB metadata information, which can be associated with a technical user ID, as well as with developers’ user IDs. This is configured by using DBB roles and permissions.

The database connection user ID and the DBB user ID can be the same user ID or can be different. In some cases, the same user ID can be used, for instance, if the technical user ID that connects to the Db2 metadata store is the same as the user ID that runs the CI/CD pipeline.

If a shared user ID is used for the database connection, each DBB user uses the same database user ID to connect to the database, and the database operations will be performed by using that shared user ID and its database permissions. If each user uses their own user ID for the database connection, then each user must be granted authority to read/write to the database depending on their role. In either case, the DBB roles and permissions will apply to the DBB user that is running the DBB script or DBB CLI.