When security is on, the Primary AuthID and Password are used when each user (or process) logs in to the XDB Server. The system then checks the SYSXDB.SYSACFUSERS table for the existence of a SecondaryID. If present, the user (or process) assumes the identity of the SecondaryID and is accorded all privileges that have been defined for the SecondaryID. If no SecondaryID exists for the user, then privileges are based on what has been granted for the Primary AuthID and the group(s) to which it belongs.
Multiple users can be assigned the same SecondaryID. In effect, this provides an alternate method for granting a particular set of privileges to a group of users without having to define those privileges for each user individually. The privileges are granted to the SecondaryID (essentially just another AuthID). However, the preferred method for assigning the same privilege set to many users is to use the XDB Server Group, which is similar to the DB2 concept of assigning multiple secondary authorization IDs to a primary authorization in IBM's RACF (Resource Access Control Facility).
If several users have the same SecondaryID, all the objects they create will be owned by the SecondaryID and not by the individual users. All users having that same SecondaryID will have all privileges on those objects. The GRANT and REVOKE commands have no effect on privileges of an object's creator/owner, which in this case includes all users with the SecondaryID that is also the AuthID portion of the object's name. All of these users are seen by the system as being the owner of the object.