What Happened to Authorities, Permissions, and Groups?

SAP Sybase IQ 16.0 introduces a role-based security model. Earlier versions used authorities, permissions, object-level permissions, and groups. The role-based security model uses roles, system privileges, object-level privileges, and user-extended roles.

Note: You can use an SAP Sybase IQ 16.0 or later server with an IQ database from an earlier version (pre-16.0). When you do, full backward compatibility is provided for that database, and its security model is not changed.

In pre-16.0, authorities are database-level permissions. For example, a user with BACKUP authority can back up the database. Some authorities bundle object-level permissions. For example, a user with PROFILE authority can perform application profiling and database tracing tasks, which involve using system procedures that are not otherwise available for use. You cannot create new authorities, alter the permissions they comprised, or drop them. You can grant administrative rights (WITH GRANT), but cannot limit the grant to administrator rights only.

In 16.0 or later, roles replace authorities, with the added benefit that you can create new roles, alter the system privileges granted, and drop them. Roles and privileges provide a more granular control when granting system privileges to users. You can also grant roles to users with administrative rights only. A user can then grant and revoke the role, but cannot exercise the underlying privileges.

In pre-16.0, permissions allowed you to create, modify, query, use, or delete database objects such as tables, views, and users.

In 16.0, system privileges replace permissions in functionality. Every privileged operation that you can perform on a database object now has a grantable system privilege. You can grant system privileges individually to users or to a role.

In 16.0, the meaning of permissions has changed. In pre-16.0 versions, it meant the a permission meant a grantable capability. Now, permission means the result of an evaluation of whether an operation can be performed. For example, you have permission to alter the table if you are the owner or you have the ALTER ANY TABLE system privilege.

In pre-16.0, groups were a collection of one or more users whose authorities and permissions were determined at the group level. A user was granted group status, and then other users were granted membership in that group.

In 16.0, the group paradigm is achieved using user-extended roles. If you have a user with a set of privileges that you want to grant to other users, you extend the user to become a user-extended role, and then grant that role to other users.

Upgrading a pre-16.0 database automatically converts your existing authority, permission, and group hierarchy into an equivalent role, privilege, and user-extended role hierarchy. Every pre-16.0 authority has a compatibility role. These roles are easily identifiable because their names start with SYS_AUTH. Compatibility roles contain the system privileges required to perform the same operations as the corresponding previous authority.

To take full advantage of the control and granularity of privileges available with role-based security, SAP recommends that, after migration, you review the compatibility role grants of each user and adjust membership and system privilege grants as necessary.