Chapter 8. Configuring Authorization

Chapter 8. Configuring Authorization
Prev		Next

Table of Contents

System Privileges
Object Privileges
Table Ownership
Privilege Hierarchy

System Built-in Roles
User-Defined Roles

Managing Roles, Privileges and Users

Role Creation
Role Removal
Role Status
Grant Roles or Privileges
Revoke Roles or Privileges

Oracle NoSQL Database provides role-based authorization which enables the user to assign kvstore roles to user accounts to define accessible data and allow database administrative operations for each user account.

Users can acquire desired privileges by role-granting. The user-defined role feature allows the user to create new roles using kvstore built-in privileges, and add new privilege groups to users by assigning newly-defined roles to users. You can grant users multiple roles.

For more information, see:

Privileges

System Privileges
Object Privileges
Table Ownership
Privilege Hierarchy

A privilege is an approval to perform an operation on one or more Oracle NoSQL Database objects. In Oracle NoSQL Database, all privileges fall into the two general categories:

System privileges

This gives a user the ability to perform a particular action, or to perform an action on any data objects of a particular type.
Object privileges

This gives a user the ability to perform a particular action on a specific object, such as a table.

System Privileges

Oracle NoSQL Database provides the following system privileges, covering both data access and administrative operations:

SYSDBA

Can perform Oracle NoSQL Database management, including table create/drop/evolve, index create/drop and Avro schema create/evolve.
SYSVIEW

Can view/show system information, configuration and metadata.
DBVIEW

Can query data object information.
USRVIEW

Can query its own information.
SYSOPER

Can perform Oracle NoSQL Database system configuration, topology management, user privilege/role management, diagnostic and maintenance operations. Allows a role to perform cancel, execute, interrupt, and wait on any plan.
READ_ANY

Can get/iterate keys and values in the entire store, including any tables.
WRITE_ANY

Can put/delete values in the entire store, including any tables.
CREATE_ANY_TABLE

Can create any table in the store.
DROP_ANY_TABLE

Can drop any table from the store.
EVOLVE_ANY_TABLE

Can evolve any table in the store.
CREATE_ANY_INDEX

Can create any index on any table in the store.
DROP_ANY_INDEX

Can drop any index from any table in the store.
READ_ANY_TABLE

Can read from any table in the store.
DELETE_ANY_TABLE

Can delete data from any table in the store.
INSERT_ANY_TABLE

Can insert and update data in any table in the store.

Object Privileges

The object privileges defined in Oracle NoSQL Database are:

READ_TABLE

Can read from a specific table in the.
DELETE_TABLE

Can delete data from a specific table in the store
INSERT_TABLE

Can insert and update data to a specific table in the store.
EVOLVE_TABLE

Can evolve a specific table.
CREATE_INDEX

Can create indexes on a specific table.
DROP_INDEX

Can drop indexes from a specific table.

For more information on the privileges required by the user to access specific KVStore APIs as well as CLI commands, see KVStore Required Privileges.

Table Ownership

When you are using a secure store, tables are owned by the user that created them. A table's owner has by default full privileges to the table. That is, the owner has all the table object privileges.

Note

For tables created in a non-secured store, or tables created prior to the 3.3 release, the table's owner is null.

Once a table is created, its owner cannot be changed. If a table is dropped and then recreated, all previously granted table privileges must be granted again.

Parent and child tables are required to have the same owner. However, table privileges are not automatically granted to the table's children. For example, if READ_TABLE is granted to table myTable, then that privilege is not automatically granted to any of that table's children. To grant READ_TABLE to the child tables, you must individually grant the privilege to each child table in turn.

A table's owner can grant or revoke all table privileges to or from other roles. To do this, use the GRANT DDL statement. (See Grant Roles or Privileges for details.) To make a user other than the owner be able to read/insert/delete a specific table, two conditions must be met:

The user has the read/insert/delete privilege for the table in question; and
The user has the same privilege, or read privilege, for all parent tables of that table.

For example, for table myTable and its child myTable.child1, a non-owner user can only insert data to myTable.child1 when she has insert privilege (or better) on myTable.child1, and read and/or insert privilege on myTable.

Privilege Hierarchy

In Oracle NoSQL Database, there is a relationship between parts of existing privileges, called 'implications'. Implication means that a privilege may be a superset of some other privileges.

For example, Privilege A implies (=>) B means that privilege A has all the permissions defined in privilege B.

The following illustration depicts all implication relationship among Oracle NoSQL Database privileges:

Note

All implications are transitive, that is, if A=>B and B=>C, then A=>C.