• DBADM can now be a system authority for managing all databases in a DB2 10 for z/OS subsystem without the ability to access data or control access to data.
• SECADM is a new authority for performing security tasks without the ability to change or access data. An individual in this role is responsible for managing data access privileges, which entails creating, modifying, and dropping trusted context, roles and audit policies.
• DATAACCESS is a new authority for accessing data without the ability to manage data or control access to data.

To ensure consistent implementation of the RBAC access model, each authority can be associated with a role definition—standalone database object, not dependent on any specific accounts (authorization IDs). DB2 roles were introduced in DB2 9 for z/OS as an object defining a collection of privileges aligned with a job function. But DB2 10 for z/OS introduces new system authorities and has made it possible to define a comprehensive, role-based access control model for application and administrative access.

Role-Based Data Control Mechanism for Application Access

As discussed previously, most applications use the same approach to access data in DB2. In this approach, coarse-grained data access privileges are granted to a group or individual users. This is because middleware servers normally maintain a pool of connections to the DBMS and each connection is associated with the same authentication ID. It isn’t practical to maintain a connection for each individual user since it negatively impacts performance. So most systems use overprivileged authentication IDs, which grant access to data spanning many actual job responsibilities. To complicate the matter further, applications hosted on distributed platforms are associated with distributed user identities and DB2 on z/OS resources are protected using RACF user identities. This mismatch prevents the use of fine-grained access control models such as RCAC.

Let’s consider the details of this traditional approach for applications running on WebSphere Application Server (WAS) as shown in Figure 4. The overprivileged RACF user identity (username/password) associated with pooled database connections is hard-coded as a Java Authentication and Authorization Service (JAAS) alias in WAS and stored directly in the file system of application servers in a security.xml file as an encoded value.

Custom password encryption can be enabled but it doesn’t address the key issues with the current approach to access control:

• Violation of the least privilege and separation of responsibilities principles by associating a database connection pool with a single overprivileged DB2 authorization ID. Permissions are granted to either an overprivileged individual ID or a group, which is a collection of users established exclusively based on user identity, and not associated with a specific activity.
• Loss of user identity and the ability to trace the activity to a specific entity.

To facilitate establishing effective role-based access control mechanisms, DB2 9 and 10 for z/OS introduced new security concepts: roles and trusted context. Role is a collection of privileges aligned with job functions. In DB2 9 and 10 for z/OS, access to DB2 objects can be restricted based on the role membership when DB2 trusted contexts are defined; in other words, in DB2 for z/OS, roles are only available as part of trusted connections. 

Trusted context is a DB2 object that controls an application’s access to data based on trust attributes: connection AuthID, domain name, encryption type and list of host names (or IP addresses, though host names are preferable from an operational standpoint) from where connections can be made. With trusted context:

• Users eligible to use trusted context get access privileges through roles associated with trusted context
• The current connection user identity can be switched with or without requiring further authentication.
To establish a role-based application access to data for an n-tier application, the following approach can be used:

5 Pages