In DB2 security, you do not sign on to DB2; the primary authorization ID identifies you to DB2. When you connect to DB2, you can become associated with one or more secondary authorization Ids. A secondary auth ID can give you additional authority to access objects in DB2. A process can have up to 245 secondary auth Ids. The required privileges for some actions can be held by any one of the secondary auth Ids; they can also release some of the administrative burdens in native DB2 caused by the cascade effect when privileges are revoked. The CA Top Secret Option for DB2 resource IBMGROUP can still function as a secondary authorization ID. A current SQL ID is the current authorization ID of the user for those commands or statements where composite privileges are not used.

The current SQL ID is the only identifier that can be changed during a connection. The current SQL ID can be set to the primary authorization ID or any secondary ID or, if any authorization ID has SYSADM, to any string of up to eight alphanumeric characters.

DB2 identifies itself to CA Top Secret based on the connection type and process. With CA Top Secret Option for DB2 you do not need secondary authorization Ids. You can continue to use these Ids if you wish; however, they can obscure the lines of individual accountability. With the elimination of the cascading REVOKE effect, secondary authorization Ids have become somewhat unnecessary. Also, it is difficult to maintain multiple Ids and they create significant performance overhead when they are used. While your site might opt to use secondary authorization Ids for some services, CA Top Secret Option for DB2 profiles provide all the flexibility necessary to group users and access in whatever way best suits your enWith CA Top Secret Option for DB2, you can continue to use the authorities that DB2 has defined. All authorities are controlled through the TSS ADD and TSS PERMIT command function. All access control features used with authorizations are applicable.

CA Top Secret Option for DB2 lets you delegate access easily with the TSS PERMIT command function.vironment.

DB2 groups privileges into functional authorities that are granted in the same manner as privileges. These authorities are grouped into a hierarchy. The SYSADM authority applies to all the user databaseds and cannot be restricted from any database, except the catalog and directory.

The WITH GRANT OPTION clause enables you to grant a privilege to another user. Because this privilege is granted to another ID, this option can make it difficult for you to keep track of who has what authority or which resource. Also, when a privilege is revoked form a particular user, the cascade effect causes that privilege to be revoked from all users who were granted that privilege by that particular user.

Again, with the elimination of the cascading effect of the REVOKE command, the control and management of authorities for an CA Top Secret security administrator is made easier. Each type of CA Top Secret administrator is restricted to functioning within a definite scope of authority. The higher its place in hierarchy, the greater its scope of authority.

As an administrator, the SQL GRANT statement lets you assign privileges to users. The REVOKE statement lets you take them away. The WITH GRANT OPTION clause lets you pass on the granted privileges to others. The PUBLIC option grants privileges to all users.

The SQL CREATE statement allows you to create an object. Ownership of an object carries certain privileges implicitly. An ID has all of these privileges for any object it owns, and can grant them to others.

As long as an object exists, there is no way to change the owner or revoke the privileges implicit in ownership. The only thing to be done is to drop the object, which deletes all privileges on it and all data, and then recreate it with a new user.

As an CA Top Secret Option for DB2 administrator, the TSS ADMIN command function gives you the authority you need to add and permit DB2‑specific resources to users.

In CA Top Secret Option for DB2, the concept of ownership through the creation of an object is eliminated. The CA Top Secret Option for DB2 owner has the same implicitly privileges that a native DB2 owner has over certain resources. However, in CA Top Secret Option for DB2, precisely who owns a resource is straightforward and easily changed.

To grant the database administrative authority on database PAYROLL to the PAYDEPT ID, the database administrator enters:

GRANT DBADM ON DATABASE PAYROLL TO PAYDEPT

To grant the ability to create tables on database PAYROLL to USER01, the database administrator enters:

GRANT CREATETAB ON DATABASE PAYROLL TO USER01

To revoke USER01’s privlege to create tables on the PAYROLL database, the administrator enters:

REVOKE CREATETAB ON DATABASE PAYROLL FROM USER01

When you use the PUBLIC option, it grants the privileges to all users.

To assign database ownership to the PAYDEPT ACID in the database called PAYROLL, the TSS administrator enters:

TSS ADD(PAYDEPT) DB2DBASE(PAYROLL)

To permit USER01 to create tables in database PAYROLL, the TSS administrator enters:

TSS PERMIT(USER01) DB2DBASE(PAYROLL) ACCESS(CRETAB)

To revoke USER01’s privilege to access database PAYROLL, the TSS administrator enters:

TSS REVOKE(USER01) DB2DBASE(PAYROLL)

When you permit a resource to the ALL Record using the TSS PERMIT(ALL) command function, you are authorizing all users to access this particular resource. This command is analogous to the PUBLIC option when using it with the SQL GRANT statement.