Access Control
CData Virtuality’s data governance allows granular permissions by using Role-Based Access Control (RBAC). Instead of each user being granted access to resources individually, each credentialed user belongs to one or more roles. Roles determine permissions to objects, actions, and administrative tasks within CData Virtuality.
Users
The CData Virtuality instance administrator invites new users via email. Every user logs onto CData Virtuality with a username and password. The administrator can then assign the appropriate role or roles to the new user.
Roles
A role is a collection of permissions to access resources. Roles adhere to the following guidelines:
Any role can be assigned to any user.
Every role has specific permissions.
When a role is assigned to a user, this user gets all the permissions associated with this role, and a user with multiple roles will have all the permissions associated with every one of these roles. If the two user roles conflict, the role that is more lenient takes precedence. For example, if a user has
role_1androle_2, withrole_1having read permission for a view androle_2having no access to the view,role_1takes precedence, and the user has access to the view.
The following are some of the common default roles in CData Virtuality. You can also define custom roles for more granular security.
Admin (admin-role)
The Admin role gives you full rights to all objects, resources, and configurations in the CData Virtuality Server. The first user in an organization is assigned the Admin role by default. This role cannot be modified or deleted.
Developer (dv-developer-role)
The Developer role gives you the ability to create and edit virtual views, stored procedures, and virtual schemas.
Business User (business-user-role)
The Business User role allows read and query access. They cannot create or alter views or stored procedures. They also cannot perform administrative tasks.
Custom Roles
You can create custom roles that fine-tune access to data. See Role Management for details.
Permissions
Permissions are more granular levels of access that make up roles. These include access to objects, actions, and administrative tasks. In CData Virtuality, resource permissions have the acronym CRUDEAL: Create, Read, Update, Delete, Execute, Alter, and Language. For each resource, you can select one or more resource permissions. For more details about resource permission types, see Role Permissions.
Resource Access
Resources in CData Virtuality include virtual schemas, virtual tables, views, and stored procedures. A resource can be as specific as the fully qualified name of a column of a particular table, or as general as an entire schema. Access to resources is inherited; that is, if the user is granted access at the schema level, the user is granted the same access to child resources. This includes any child tables added in the future. Permissions granted to a particular path apply to it and any resource paths that share the same partial name. For example, granting a READ permission to model will also grant READ permissions to model.table and model.table.column.
Allowing or denying a particular action is determined by searching for permissions from the most to the least specific resource paths. The first such permission found is used. It is possible to set very general permissions at high-level resource path names and override them as necessary at more specific resource paths.
Permission grants are only needed for resources that a role needs access to. Permissions are only applied to the columns, tables, or procedures in the user query, not to every resource accessed transitively through view and procedure definitions. Therefore, it is important to ensure that permission grants are applied consistently across models that access the same resources.
The rights for more specific resource names override those for the less specific ones. For example, if you prohibit reading contents of a schema, you can still enable reading contents of a particular table inside this schema.
The permissions on a particular data source's resource imply the appropriate permissions on its materialized representation in the Analytical Storage. This means that if you grant a role a read permission to a specific table, a user with this role will also be able to read the appropriate materialized table in the Analytical Storage if the SQL query is redirected there by an enabled optimization.
Administrative Tasks
Access to administrative tasks include the ability to create and edit users, manage roles, and configure data sources.