ユーザーおよびユーザーグループは、異なるアクションへのアクセスを微調整するために使用できます。CData Virtuality Server には、変更または削除できない1つのユーザーといくつかの設定済みグループが含まれています。独自のユーザーやグループを追加することもできますが、詳しくはData Rolesを参照してください。

このセクションの情報は、CData Virtuality Server で使用されるdvconfig ベースの認証とLDAP 認証の両方の認証メカニズムで有効です。唯一の違いは、設定が保存されている場所です:

  • dvconfig-based authentication: dv_rolesテーブル
  • LDAP 認証:dv_ldap_role_props テーブル

Default User and User Groups

デフォルトのユーザーはadminで、デフォルトのパスワードはadminです。このユーザーの名前を変更することはできませんが、SYSADMIN.changeUserPwdの手順を使用して、別のパスワードを設定することができます。

デフォルトのグループとそのPermission、スコープは以下のとおりです:

Group name

Default permissions

Scope

admin-role

CRUDEA on *
L on javascript

Virtual Database/VDB

connect-dv-role

C_____A_

Virtual Database/VDB

dv-developer-role

Allows to manage replications

Virtual Database/VDB

export-dv-role

C_____A_

Virtual Database/VDB

odata-role

Allows interacting via OData protocol

Virtual Database/VDB

superadmin-role

CRUDEAL on *
(full rights)

CData Virtuality Server

dv-developer-role available since v4.1

admin-role permission changed from CRUDEAL on * to CRUDEA on * and L on javascript to disable Python scripting since v4.9

User Rights

CData Virtuality Serverでは、以下のアクセス権が定義されています:

Right

Description

C

Create a table/view

R

Read contents of a table/view

U

Update the content of a table

D

Delete some table content

E

Execute a stored procedure

A

Alter a view

L

Use objecttable


Create temporary tables (special case, see below)

メタデータレポートSYSおよびpg_catalogスキーマには、permission は適用されません。ただし、SYSADMINSYSLOGUTILSのスキーマは、必要に応じてPermissionが必要な場合があります。

Default Rights

 adminユーザーは CData Virtuality Server のすべてのリソース(テーブルを含む)に対するすべての権限を持っています。それ以外のユーザーには、デフォルトで何の権利もありません。

Configuring Permissions

 SYSADMIN.setPermissions ストアドプロシージャを呼び出すことで、ロールに権限を付与することができます:

"SYSADMIN.setPermissions"(
"role_name" => 'string_role_name' /* mandatory */,
"resourceName" => 'string_resourceName' /* mandatory */,
"permissions" => 'string_permissions' /* optional */
);;

パーミッションはユーザーにではなく、ロールに付与されることに注意してください。特定のロールを持つユーザーは、このロールに割り当てられたパーミッションを持つことになります。

この例では、managers ロールがあり、このロールを持つユーザにcustomers スキーマのaddressテーブルの読み取り権限を与えたいとします:

CALL "SYSADMIN.setPermissions"(
"role_name" => 'managers',
"resourceName" => 'customers.address',
"permissions" => 'R'
);;

リソース名には、完全修飾名のいずれかを指定できます:

  • スキーマ名  - customers など
  • テーブル名 - customers.address など
  • ビュー名 - views.googleAnalyticsAndMongoDbView など
  • ストアドプロシージャ名 - SYSADMIN.setPermissions など

例えば、あるスキーマの内容の読み取りを禁止していても、そのスキーマ内の特定のテーブルの内容の読み取りを許可することができます。

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.
If a role is given execution rights on the SYSADMIN.setPermissions stored procedure, members of that role can effectively grant/revoke rights to everybody, including themselves. This means the role indirectly gets full rights.

Restricting Login

 SYSADMIN.allowUserLogin プロシージャでログインを制限できます。

call "SYSADMIN.allowUserLogin"(
"name" => 'string_name',
"loginAllowed" => true
);;

Prohibiting Access to a Specific Resource

  SYSADMIN.setPermissionsストアドプロシージャを (空の文字列) Permission 値で呼び出すと、 リソースの 'deny all' になります: ''   

CALL "SYSADMIN.setPermissions"(
"role_name" => 'managers',
"resourceName" => 'customers.address',
"permissions" => ''
);;

Complete Removal of Rights to Resources

 SYSADMIN.setPermissionsストアドプロシージャをNULL Permission 値で呼び出すと、  SYSADMIN.Permissionsエントリが削除されます。その結果、このRoleには特にPermissionsは設定されず、リソースおよび親のPermissionsが有効になります:

CALL "SYSADMIN.setPermissions"(
"role_name" => 'managers',
"resourceName" => 'customers.address',
"permissions" => null
);;

Special Permission to Create Temporary Tables

一時テーブルを使用した操作には特別な Permission が必要です。4つのデフォルトロールのうち2つ、admin-rolesuperadmin-role、すでに彼のPermissionを持っています。他の2つ(connect-dv-roleexport-dv-role)にはありません。SYSADMIN.addRole()を使用して独自のユーザ・ロールを作成する場合、このコマンドを使用して、必要に応じてこのロールに一時テーブルを作成する権利を付与することができます:

setAllowCreateTempTables(IN role_name string NOT NULL, IN allow boolean NOT NULL)

ロールがすでに存在し、そのロールにこの権限があるかどうかを確認したい場合、以下の2つのコマンドのどちらかを使用して確認することができます:

SELECT * FROM (CALL "SYSADMIN.getCreateTempTablesPermissions"()) a;;
-- or
SELECT * FROM "SYSADMIN.getCreateTempTablesPermissions"();;

ANDは既存のRoleの設定を変更する方法です:

CALL sysadmin.setAllowCreateTempTables(<role name>, TRUE|FALSE);;