データベース・アプリケーション表統合リファレンス
Oracle Access Governanceとの統合が認定されたDatabase Application Tablesコンポーネント
次に、統合可能なデータベース・アプリケーション表コンポーネントを示します。
動作保証されたコンポーネント
| コンポーネント・タイプ | コンポーネント |
|---|---|
| Oracle固有の要件 | |
| システム | ターゲット・システムは、次のいずれかのRDBMSのデータベース表。
|
| JDK | JDK 1.6以上 |
| Microsoft SQL Server固有の要件 | |
| システム | Microsoft SQL Server 2016, 2017 |
| JDBCドライバ | Microsoft SQL Server 2014の場合: sqljdbc4バージョン4.0 |
| Microsoft MySQL固有の要件 | |
| システム | MySQL 5.x、MySQL 8.x |
| JDBCドライバ | mysql-connector-java-5.1.12-bin |
| 一般的な要件 | |
| ユーザー・データがシステムに格納される形式 |
Database Application Tablesコネクタを使用できるのは、ユーザー・データが次のいずれかの形式でターゲット・システムに格納されている場合のみです。
|
| システムのその他の要件 |
システムは、次の要件を満たす必要があります。
|
データベース・アプリケーション表の統合でサポートされる構成モード
Oracle Access Governance統合は、アイデンティティ・データのオンボーディングおよびアカウントのプロビジョニングの要件に応じて、様々な構成モードで設定できます。
サポートされているモード
Database Application Tables Orchestrated Systemでは、次のモードがサポートされています。
-
認可ソース
次の場合、Oracle Access Governanceのアイデンティティ情報の信頼できるソースとしてデータベース・アプリケーション表を使用できます。
- すべてのユーザー・データが1つの表またはビューに格納されている場合
- すべてのユーザー・データが、単一の更新可能なビュー(1つ以上のテーブルに基づく)に格納されている場合。
-
管理対象システム
次の場合、Database Application Tables権限を管理できます。
- すべてのユーザー・データが1つの表またはビューに格納されている場合
- すべてのユーザー・データが、単一の更新可能なビュー(つまり、1つ以上のテーブルに基づく)または
- ユーザー・データが、1つの親表全体および1つ以上の子表に分散している場合。あるいは
- ユーザー・データが、(1つ以上の表に基づく)単一の更新可能なビュー、および(1つ以上の表に基づく)1つ以上の子ビューに分散している場合。
最小特権サービスユーザーの構成
データベース・アプリケーション表の最小特権サービス・ユーザーの構成(Oracle)
Oracle Access GovernanceとDatabase Application Tables (Oracle)データベース間のセキュアな接続を有効にするには、統合の構成に必要な最小限の権限を持つサービス・ユーザーを作成します。
認可ソース・モードに必要な権限
Database Application Tables (Oracle)オーケストレート済システムを認可モードで構成する場合は、アイデンティティを含む表に対する読取り権限をサービス・ユーザーに付与して、Oracle Access Governanceにロードできるようにする必要があります。この場合に必要な最小限の権限セットは、アイデンティティ情報または個人情報を含む表に対するSELECT権限です。
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER; ここで:-
MYDBAT_PERSON: アイデンティティ情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
管理対象システム・モードに必要な権限
データベース・アプリケーション表(Oracle)のオーケストレートされたシステムをマネージド・システム・モードで構成する場合、アカウント表および権限表に対する読取りおよび書込み権限を付与し、アカウントおよびアカウント権限のリコンシリエーション、作成、更新および削除を許可する必要があります。この場合に必要な最小限の権限セットは、アカウントおよびアカウントの権限表に対するSELECT、INSERT、UPDATEおよびDELETE権限です。
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;
ここで-
MYDBAT_PERSON: アカウント情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。 -
MYDBAT_ROLES: ロール情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。 -
MYDBAT_GROUPS: グループ情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。 -
MYDBAT_PERSON_ROLE: ユーザー・ロール情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。 -
MYDBAT_PERSON_GROUP: グループ・ロール情報を含むデータベース・アプリケーション表(Oracle)データベースの表です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
カスタム・スクリプトに必要な権限
「Groovyを使用したデータベース・アプリケーション表(Oracle)のカスタム・スクリプトの開発」の説明に従って、データベース・アプリケーション表(Oracle)統合の操作用のカスタム・スクリプトを開発するには、カスタム・スクリプトで参照されるストアド・プロシージャまたはその他のデータベース・オブジェクトに権限を追加する必要があります。サービス・ユーザーを使用してストアド・プロシージャを作成する場合は、権限を必要としません。ストアド・プロシージャまたは他のデータベース・オブジェクトが別のユーザーに作成されている場合は、必要に応じて権限を付与する必要があります。
GRANT EXECUTE ON MYDBAT_CUSTOMDEV.GET_USERROLE TO SERVICEUSER;ここで:-
MYDBAT_CUSTOMDEV: ストアド・プロシージャの作成に使用したユーザーです。 -
GET_USERROLEは、ストアド・プロシージャの名前です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
データベース・アプリケーション表(MSSQL)の最小特権サービス・ユーザーの構成
Oracle Access GovernanceとDatabase Application Tables (MSSQL)データベース間のセキュアな接続を有効にするには、統合の構成に必要な最小限の権限を持つサービス・ユーザーを作成します。
認可ソース・モードに必要な権限
データベース・アプリケーション表(MSSQL)オーケストレート済システムを認可モードで構成する場合は、アイデンティティを含む表に対する読取り権限をサービス・ユーザーに付与して、それらをOracle Access Governanceにロードできるようにする必要があります。この場合に必要な最小限の権限セットは、アイデンティティ情報または個人情報を含む表に対するSELECT権限です。
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER; ここで:-
MYDBAT_PERSON: アイデンティティ情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
管理対象システム・モードに必要な権限
管理対象システム・モードでデータベース・アプリケーション表(MSSQL)オーケストレート済システムを構成する場合、アカウントおよびアカウント権限のリコンシリエーション、作成、更新および削除を許可するために、アカウント表および権限表に対する読取りおよび書込み権限を付与する必要があります。この場合に必要な最小限の権限セットは、アカウントおよびアカウントの権限表に対するSELECT、INSERT、UPDATEおよびDELETE権限です。
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;
ここで-
MYDBAT_PERSON: アカウント情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。 -
MYDBAT_ROLES: ロール情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。 -
MYDBAT_GROUPS: グループ情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。 -
MYDBAT_PERSON_ROLE: ユーザー・ロール情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。 -
MYDBAT_PERSON_GROUP: グループ・ロール情報を含むデータベース・アプリケーション表(MSSQL)データベースの表です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
カスタム・スクリプトに必要な権限
「Groovyを使用したデータベース・アプリケーション表(Oracle)のカスタム・スクリプトの開発」の説明に従って、データベース・アプリケーション表(MSSQL)統合での操作のカスタム・スクリプトを開発する場合は、カスタム・スクリプトで参照されるストアド・プロシージャまたはその他のデータベース・オブジェクトに権限を追加する必要があります。サービス・ユーザーを使用してストアド・プロシージャを作成する場合は、権限を必要としません。ストアド・プロシージャまたは他のデータベース・オブジェクトが別のユーザーに作成されている場合は、必要に応じて権限を付与する必要があります。
GRANT EXECUTE ON OBJECT::dbo.GET_USERROLE TO SERVICEUSER;ここで:-
OBJECT::dbo: Microsoft MSSQLデータベース・オブジェクトです。 -
GET_USERROLEは、ストアド・プロシージャの名前です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
データベース・アプリケーション表の最小特権サービス・ユーザーの構成(MySQL)
Oracle Access GovernanceとDatabase Application Tables (MySQL)データベース間のセキュアな接続を有効にするには、統合の構成に必要な最小限の権限を持つサービス・ユーザーを作成します。
認可ソース・モードに必要な権限
データベース・アプリケーション表(MySQL)のオーケストレートされたシステムを認可モードで構成する場合は、アイデンティティを含む表に対する読取り権限をサービス・ユーザーに付与して、Oracle Access Governanceにロードできるようにする必要があります。この場合に必要な最小限の権限セットは、アイデンティティ情報または個人情報を含む表に対するSELECT権限です。
GRANT SELECT ON MYDBAT_PERSON TO SERVICEUSER; ここで:-
MYDBAT_PERSON: アイデンティティ情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
管理対象システム・モードに必要な権限
データベース・アプリケーション表(MySQL)のオーケストレートされたシステムをマネージド・システム・モードで構成する場合、アカウント表および権限表に対する読取りおよび書込み権限を付与し、アカウントおよびアカウント権限のリコンシリエーション、作成、更新および削除を許可する必要があります。この場合に必要な最小限の権限セットは、アカウントおよびアカウントの権限表に対するSELECT、INSERT、UPDATEおよびDELETE権限です。
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_ROLES TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_GROUPS TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_ROLE TO SERVICEUSER;
GRANT SELECT, INSERT, UPDATE, DELETE ON MYDBAT_PERSON_GROUP TO SERVICEUSER;
ここで-
MYDBAT_PERSON: アカウント情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。 -
MYDBAT_ROLES: ロール情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。 -
MYDBAT_GROUPS: グループ情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。 -
MYDBAT_PERSON_ROLE: ユーザー・ロール情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。 -
MYDBAT_PERSON_GROUP: グループ・ロール情報を含むデータベース・アプリケーション表(MySQL)データベースの表です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
カスタム・スクリプトに必要な権限
「Groovyを使用したデータベース・アプリケーション表(Oracle)のカスタム・スクリプトの開発」の説明に従って、データベース・アプリケーション表(MySQL)統合の操作用のカスタム・スクリプトを開発する場合は、カスタム・スクリプトで参照されているストアド・プロシージャまたはその他のデータベース・オブジェクトに権限を追加する必要があります。サービス・ユーザーを使用してストアド・プロシージャを作成する場合は、権限を必要としません。ストアド・プロシージャまたは他のデータベース・オブジェクトが別のユーザーに作成されている場合は、必要に応じて権限を付与する必要があります。
GRANT EXECUTE ON MYSQLDB.GET_USERROLE TO 'SERVICEUSER';ここで:-
MYSQLDB: ストアド・プロシージャを作成したMySQLデータベースです。 -
GET_USERROLEは、ストアド・プロシージャ名です。 -
SERVICEUSER: サービス・アカウント・ユーザー。
データベース・アプリケーション表へのプロビジョニング時にサポートされる操作
Oracle Access GovernanceからDatabase Application Tablesにアカウントをプロビジョニングすると、特定の操作がサポートされます。
- アカウントの作成
- アカウントの有効化
- アカウントの無効化
- アカウントの取消
- 権限の割当
- 権限の削除
サポートされているデータ型
リコンシリエーションおよびプロビジョニング操作でサポートされるデータ型を以下の項で示します。
Oracle Databaseの場合
Oracle Databaseオーケストレート済システムのリコンシリエーションおよびプロビジョニング操作でサポートされているデータ型は、次のとおりです。
- VARCHAR2
- CHAR
- NUMBER
- NUMERIC
- INTEGER
- INT
- SMALLINT
- DOUBLE
- FLOAT
- DECIMAL
- 12月
- REAL
- DATE
- TIMESTAMP
Microsoft SQL Serverの場合
Microsoft SQL Serverデータベース・オーケストレート済システムのリコンシリエーションおよびプロビジョニング操作でサポートされているデータ型は、次のとおりです。
- CHAR
- VARCHAR
- SMALLINT
- INT
- BIGINT
- DECIMAL
- NUMERIC
- NVARCHAR
- FLOAT
- REAL
- SMALLDATETIME
- DATETIME
MySQLの場合
MySQLデータベースのオーケストレート済システムのリコンシリエーションおよびプロビジョニング操作でサポートされているデータ型は、次のとおりです。
- ブール
- SMALLINT
- MEDIUMINT
- INT
- BIGINT
- FLOAT
- DOUBLE
- DECIMAL
- CHAR
- VARCHAR
- TINYTEXT
- DATE
- DATETIME
- TIMESTAMP
デフォルトのサポートされる属性
データベース・アプリケーション表の統合にはスキーマの検出が必要であり、検出されたスキーマは固定されていないため、サポートされている特定の属性などはありません。必要に応じて、schema.jsonを変更してコア属性およびカスタム属性を追加できます。少なくとも、「コア・アイデンティティ属性」で定義されているように、Oracle Access Governanceアイデンティティに必要なuidおよびname属性を含める必要があります。
デフォルト照合ルール
Oracle Access Governanceのアイデンティティにアカウントをマップするには、オーケストレート済システムごとに照合ルールが必要です。
Database Application Tablesオーケストレート済システムのデフォルト照合ルールは、次のとおりです。
| モード | デフォルト照合ルール |
|---|---|
|
認可ソース
アイデンティティ照合では、受信アイデンティティが既存のアイデンティティと一致するか、新しいアイデンティティであるかがチェックされます |
画面値:
属性名:
|
|
管理されたシステム
アカウント照合では、受信アカウントが既存のアイデンティティと一致するかどうかがチェックされます。 |
画面値:
属性名:
|
データベース・アプリケーション表のガイドライン
Oracle Access Governanceでデータベース・アクセス表を使用する場合は、表の設計および構造における次のガイドラインを考慮する必要があります。
一般ガイドライン
- エンティティの「名前」列および「キー」列は、NOT NULLとして構成する必要があります。
- 特定のエンティティの場合、同じデータベース列を「名前」および「キー」として構成できます。必要に応じて、これらの列に異なる列を使用することもできます。
- ACCOUNTエンティティに含まれるコア属性は、次のルールに従う必要があります。
- 列のデータ型には、Oracle Access Governance側のデータ型との互換性があることが必要です。
- スキーマJSONファイルで
"nature":["REQUIRED"]として構成される属性は、NOT NULLデータベース・フィールドに対応している必要があります。
- ENTITLEMENTおよびLOOKUP表には、キー列に対する主キー制約が必要です。
- ENTITLEMENTテーブルとLOOKUPテーブルの関連カラムが一致する場合、ACCOUNT/TARGETACCOUNTテーブルとENTITLEMENTテーブルとLOOKUPテーブルの間に外部キー関係を定義する必要はありません。詳細については、次のセクションを参照してください。
テーブル関係
CREATE TABLE MYDBAT_PERSON
(USERID VARCHAR2 NOT NULL ENABLE,
USERNAME VARCHAR2 NOT NULL ENABLE,
FIRSTNAME VARCHAR2,
LASTNAME VARCHAR2,
EMAIL VARCHAR2 NOT NULL ENABLE,
HOMECOUNTRY VARCHAR2,
FOREIGN KEY (HOMECOUNTRY) REFERENCES MYDBAT_COUNTRY(COUNTRYCODE));
CREATE TABLE MYDBAT_COUNTRY
(COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)
CREATE TABLE MYDBAT_PERSON
(USERID VARCHAR2 NOT NULL ENABLE,
USERNAME VARCHAR2 NOT NULL ENABLE,
FIRSTNAME VARCHAR2,
LASTNAME VARCHAR2,
EMAIL VARCHAR2 NOT NULL ENABLE,
COUNTRYCODE VARCHAR2);
CREATE TABLE MYDBAT_COUNTRY
(COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)
CREATE TABLE MYDBAT_PERSON
(USERID VARCHAR2 NOT NULL ENABLE,
USERNAME VARCHAR2 NOT NULL ENABLE,
FIRSTNAME VARCHAR2,
LASTNAME VARCHAR2,
EMAIL VARCHAR2 NOT NULL ENABLE,
HOMECOUNTRY VARCHAR2);
CREATE TABLE MYDBAT_COUNTRY
(COUNTRYCODE VARCHAR2 NOT NULL ENABLE,
COUNTRYNAME VARCHAR2 NOT NULL ENABLE,
CONSTRAINT MYDBAT_COUNTRY_PK PRIMARY KEY (COUNTRYCODE)
ユーザーと参照間の関係について前述したのと同じ原則が、ユーザーと権限の間の関係に対して表を定義するときに適用されます。
アイデンティティ属性とアカウント属性の関連付け
アカウント属性設定を編集することで、アイデンティティ属性をアカウント属性に関連付けることができます。
- Oracle Access Governanceコンソールにサインインし、「Service Administration」→「Orchestrated Systems」に移動します。
- アイデンティティ属性をアカウント属性に関連付けるDBATオーケストレート済システムの「統合の管理」を選択します。
- 「アカウント属性」タイルから「管理」を選択します。
- マップするアカウント属性について、アクション・メニューから「関連付けられたアイデンティティ属性の編集」を選択します。
- アカウント属性に関連付けるアイデンティティ属性を選択し、「保存」をクリックします。この値は、アカウント属性の「関連付けられたアイデンティティ属性」列に表示されます。
カスタム複数値アイデンティティ属性のDBAT提携サポート
DBATオーケストレート済システムは、Custom (Complex) Multivalued Attributesの実装を通じてアフィリエイト・データをサポートします。
提携は、必要な提携のカスタム表を追加し、それをアカウント表にリンクすることで有効になります。たとえば、次のようなユーザーというアカウント表があるとします。
| USER_ID | USER_NAME | FIRST_NAME | LAST_NAME | 電子メール | ステータス |
|---|---|---|---|---|---|
| 1 | USR001 | ユーザー | 1つ | userone@email.com | ACTIVE |
| 2 | USR002 | ユーザー | 2 | usertwo@email.com | ACTIVE |
次に、表すアフィリエイトのカスタム表を作成する必要があります。たとえば、1つのIDに複数の肩書を割り当てられる所属関係を設定できます。これを行うには、次のような表ジョブを作成します:
| 職務コード | USER_ID | JOBNAME | 説明 |
|---|---|---|---|
| JB001 | 1 | ジョブ | これはジョブです |
| 1 | 別のジョブ | これは別のジョブです | |
| 2 | 新規ジョブ | これは新規ジョブです |
勘定科目テーブルは、複合主キー(USER_ID、JOBCODE)によって Affiliationテーブルに直接リンクされます。
最後に、次のスニペットに示すように、schema.jsonの塗りつぶしにアフィレーションを追加する必要があります。
[
{
"type": "ACCOUNT",
"name": "ACCOUNT",
"displayName": "Account",
"attributes": [
{
"name": "JOBS",
"targetName": "JOBS",
"displayName": "",
"dataType": "",
"nature": ["MULTIVALUED"],
"usage": [
"READ"
],
"relationship": {
"relatedTo": "__CUSTOM_COMPLEX__", // Indicates the custom relationship
"relatedBy": "",
"relationshipProperties": [
{
"name": "JOBCODE",
"dataType": "TEXT",
"nature": ["REQUIRED"]
},
{
"name": "JOBNAME",
"dataType": "TEXT",
"nature": ["REQUIRED"]
},
{
"name": "DESCRIPTION",
"dataType": "TEXT",
"nature": []
}
]
}
}
]
}
]
統合設定には、この表名とその他の関連表を含めます。詳細は、関係会社を参照してください。