リリース9.1.0.2
B56035-01
 目次 |
 索引 |
| Oracle Identity Manager Toolsリファレンス リリース9.1.0.2 B56035-01 |
|
職務の分離（SoD）の概念は、ビジネス・プロセスにチェック・アンド・バランスを適用することを目的としています。ビジネス・プロセスの各段階では、複数の人員の参加が必要になる場合があります。組織では、ユーザー・プロビジョニング・ソリューションの一部としてSoDを実装することにより、こうした状況をすべてのIT対応のビジネス・プロセスの要件にすることができます。SoDには、組織のリソースが意図的または偶発的に悪用されることにより生じる危険を軽減するという利点があります。
Oracle Identity ManagerのSoDの実装では、ユーザーが送信したIT権限（権限）リクエストが、SoDエンジンと他のユーザーによってチェックされ、承認されます。システムと人による複数レベルのチェックの導入により、たとえ元のリクエストに変更が加えられても、リクエストがクリアされる前に必ず入念に検査されるようにすることができます。この予防シミュレーションの方法は、リクエストされた権限がユーザーに付与される前に、そのユーザーに対する権限割当てで競合する可能性のあるものを特定し、修正する上で役立ちます。
この章では、Oracle Identity Managerで生成された権限リクエストの処理にSoDがどのように使用されるか、およびSoDを実装する手順について説明します。
この章は、次の項に分かれています。
SoD起動ライブラリ（SIL）は、Oracle Identity ManagerでのSoD実装の基礎となります。SILはJavaベースのアダプタの集合で、事前に定義されたOracle Identity Managerコネクタとの統合を可能にします。その結果、コネクタは、Oracle Identity Managerをターゲット・システムと結び付けます。次のOracle Identity Managerコネクタが、SoD検証用に事前に構成されています。
SILは、SILとSoDエンジンを統合する専用アダプタの基礎の役割も果します。これらのアダプタは、SILプロバイダと呼ばれます。SILプロバイダは、SILと特定のSoDエンジンとのインタフェースの機能を果します。次のSoDエンジン用に事前に定義されたSILプロバイダがあります。
このプロバイダは、SAP GRC SILプロバイダとしても知られています。動作保証されたSAP GRCのバージョンは、バージョン5.2 SP4以上および5.3 SP5以上です。
このプロバイダは、OAACG SILプロバイダとしても知られています。
図13-1では、Oracle Identity ManagerでのSoD実装のアーキテクチャを示しています。
Oracle Identity Managerコネクタは、必要に応じて、SAP GRC SILプロバイダまたはOAACG SILプロバイダのいずれとも構成できます。たとえば、PeopleSoft User ManagementコネクタとOAACG SILプロバイダを使用すれば、PeopleSoft Enterpriseアプリケーションで権限に対するリクエストのSoD検証を自動化できます。
カスタムSoDエンジン用SILプロバイダを作成し、事前に構成されたOracle Identity Managerコネクタ、またはSoD検証用に構成したOracle Identity Managerコネクタのいずれかとともに使用することもできます。
Oracle Identity Managerは、ユーザー・プロビジョニング・ソリューションです。権限リクエストは、Oracle Identity Managerで管理できます。
Oracle Identity ManagerでのSoD検証プロセスは、ユーザーが特定のターゲット・システムでの権限に対するリクエストを作成すると開始されます。Oracle Identity Managerのリソース承認ワークフローは、SoDエンジンによりリアルタイムでこのリクエストを検証するように構成できます。SoDエンジンでは、事前定義のルールを使用して、権限割当てがSoD違反につながるかどうかをチェックします。このチェックの結果は、Oracle Identity Managerに返されます。リクエストがSoD検証をパスしなかった場合、修正処理が行われるように承認ワークフローを構成できます。リクエストがSoD検証にパスし、承認者がリクエストを承認した場合、リソース・プロビジョニング・ワークフローが開始されます。このリソース・プロビジョニング・ワークフローは、SoD検証を再実行するように構成することもできます。これは、権限割当てがターゲット・システムにプロビジョニングされる直前に、権限割当てのSoDコンプライアンスを保証するためです。リソース・プロビジョニング・ワークフローでのSoD検証チェックは、リソース承認ワークフローでこの検証にパスした場合には、省略されるように構成することもできます。
Oracle Identity Managerは、SoDエンジンとターゲット・システムの両方と統合されます。また、ターゲット・システムとSoDエンジンは、権限データのターゲット・システムからSoDエンジンへの同期化が有効になるように統合されます。
図13-2は、SoD検証プロセスでのデータの流れを示しています。
Oracle Identity ManagerでSoDを実装し、有効にするために必要な手順の概要は次のとおりです。
手順は、13.3.2項「Oracle Identity Managerコネクタのインストールおよび構成」を参照してください。
Oracle Identity Managerリリース9.1.0.2へのアップグレードの手順を実行すると、Oracle Identity Managerデータベース・スキーマにSILデータベース表が作成されます。
SILデータベース表に異なるスキーマを使用する場合は、次のようにします。
SILデータベース表を作成するには、次のディレクトリのいずれかにあるSoDInvocationDBScript.sqlスクリプトを実行します。
Microsoft SQL Serverの場合:
SIL_HOME/database/script/mssql
Oracle Databaseの場合:
SIL_HOME/database/script/oracle
SoD検証に使用するターゲット・システム用のOracle Identity Managerコネクタをインストールし、構成します。
Oracle Identity Managerコネクタの完全なドキュメント・セットにアクセスするには、次のURLにあるOracle Technology Networkにアクセスしてください。
http://www.oracle.com/technology/documentation/oim1014.html
使用する予定のSILプロバイダに応じて、次のいずれかの項の手順を参照してください。
OAACG SILプロバイダで必要な外部ファイルをコピーするには、次のようにします。
http://abdera.apache.org/
abdera.parser.0.3.0-incubating.retro.jar
abdera.core.0.3.0-incubating.retro.jar
abdera-i18n-0.3.0-incubating.retro.jar
commons-codec-1.3.jar
log4j-1.2.14.jar
axiom-api-1.2.5.jar
commons-logging-1.0.4.jar
retroweaver-rt-2.0.jar
axiom-impl-1.2.5.jar
jaxen-1.1.1.jar
stax-api-1.0.1.jar
http://dist.codehaus.org/stax/jars
SAP GRC SILプロバイダで必要な外部ファイルをコピーするには、次のようにします。
http://www.apache.org
ターゲット・システムからSoDエンジンに権限データをインポートする必要があります。必要に応じて、SoDエンジンでSoD検証ルールも構成します。
次の項では、事前に定義されたSoDエンジンに対するこれら手順を説明します。
Oracle Application Access Controls Governorの構成には、次の手順が必要です。
SoD検証処理用に基本タイプのアカウントを作成します。13.3.5.1項「SoDエンジンの情報を保持するためのITリソースの作成」で説明されている手順の実行中に、このアカウントのユーザー名およびパスワードを指定します。
アカウント作成の詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。
Oracle E-Business Suiteからロールおよび職責データをOracle Application Access Controls Governorにインポート（同期化）する必要があります。最初の同期化の後、データの定期的同期化のスケジュールを設定する必要があります。
詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。
ロールおよび職責データのインポート後、Oracle Application Access Controls Governorでアクセス・ポリシーを設定します。これらのアクセス・ポリシーは、ロールおよび職責の様々な組合せに基づいています。
詳細は、Oracle Application Access Controls Governorのドキュメントを参照してください。
SAP GRCでは、SAP R/3のユーザー、ロールおよびプロファイル・データを使用して、アカウント、ロールおよび職責に対するリクエストを検証します。SAP GRCの構成には、次の手順が必要です。
SoD処理用のSAP GRCアカウントを作成する必要があります。SoD処理中、SAP GRC Webサービスのコールにこのアカウントが使用されます。
このユーザー・アカウントの作成時に、アカウントを次のグループに割り当てる必要があります。
このアカウントにはロールを割り当てないでください。
キーストアを生成するには、次のようにします。
https://SAP_GRC_HOST:PORT_NUMBER/VirsaCCRiskAnalysisService/Config1?wsdl
keytool -import -v -trustcacerts -alias sapgrc -file CERTIFICATE_FILENAME -keystore sgil.keystore -keypass changeit -storepass changeit
changeitを指定します。これは、デフォルトのキーストア・パスワードです。
yesを入力します。
Risk Terminatorは、GRC Access Controlの機能です。これは、SAP GRCのSoD検証機能のメイン・コンポーネントです。ロールがプロファイル・ジェネレータで作成されたり、ユーザーに割り当てられたりすると、Risk Terminatorにより、このロールの作成または割当てがSoD違反になるかどうかが検証されます。
詳細は、Risk Terminator構成のドキュメントを参照してください。
ユーザー、ロールおよびプロファイル・データは、SAP ERPからSAP GRCにインポート（同期化）する必要があります。最初の同期化の後、データの定期的同期化のスケジュールを設定する必要があります。
ロールおよび職責データのインポート後、SAP GRCのRisk Analysis and Remediation機能を使用して、職務の分離タイプのリスク・ポリシーを定義します。
詳細は、SAP GRCのドキュメントを参照してください。
Oracle Identity ManagerがOracle Application Serverで稼働している場合、次の手順を実行します。
<code-source path="OIM_HOME/xellerate/ext/wsdl4j-.5.1.jar"/> <code-source path="OIM_HOME/xellerate/ext/log4j-1.2.8.jar"/> <code-source path="OIM_HOME/xellerate/ext/saaj.jar"/> <code-source path="OIM_HOME/xellerate/ext/axis.jar"/> <code-source path="OIM_HOME/xellerate/ext/commons-discovery-0.2.jar"/> <code-source path="OIM_HOME/xellerate/ext/commons-logging-1.0.4.jar"/> <code-source path="OIM_HOME/xellerate/ext/jaxrpc.jar"/>
ここでは、OIM_HOMEをOIM_HOMEディレクトリのフルパスに置き換えます。たとえば、OIM_HOMEディレクトリがc:/programfiles/oimの場合、コードの行は次のようになります。
<code-source path="c:/programfiles/oim/xellerate/ext/wsdl4j-.5.1.jar"/>
Oracle Identity ManagerがOracle WebLogic Application Serverで稼働している場合、次の手順を実行します。
log4j.logger.org.apache.axis.ConfigurationException = INFO
pushd "D:¥bea¥user_projects¥domains¥oim9102¥bin" xlStartWLS.cmd popd
ここでは、D:¥bea¥user_projects¥domains¥oim9102が、ファイル内のドメインの場所のエントリです。
SILの登録時に、使用するOracle Identity Managerインストール、SoDエンジンおよびターゲット・システムの詳細を指定します。1回の登録セッション中に、複数のOracle Identity Managerインストール、SoDエンジンおよびターゲット・システムを登録できます。Oracle Identity Managerインストール、SoDエンジンおよびターゲット・システムの各組合せには、登録プロセス中に一意のIDが割り当てられます。
登録スクリプト（registration.shおよびregistration.bat）により、登録プロセスが実行されます。このスクリプトを実行すると、必要な情報の入力を要求されます。スクリプトにより表示される最初の一連のプロンプトは、registration.xmlファイルから読み取られます。登録スクリプトは、SIL_HOME/scriptsディレクトリにあります。registration.xmlは、SIL_HOME/registrationXMLディレクトリにあります。
SILおよびSILプロバイダのデプロイには、次の手順が必要です。
前述のように、registration.xmlファイルには、登録スクリプトによって表示される最初の一連のプロンプトがあります。このXMLファイルでは、SoDエンジンの情報を要求するプロンプトを表示するためにSystemType要素が使用されます。
SoDエンジンの情報を保持するには、ITリソースを作成する必要があります。
ITリソース・タイプ（まだ存在しない場合）およびITリソースの作成の詳細は、
『Oracle Identity Managerデザイン・コンソール・ガイド』を参照してください。ITリソース・タイプおよびITリソースには任意の名前を指定できます。次の表では、ITリソースに含める必要のあるパラメータの名前を示しています。
| パラメータ | 説明 | サンプル値 |
|---|---|---|
|
Source Datastore Name |
SoDエンジンで定義したソース・データ・ストア（ターゲット・システム）の名前を入力します。 ソース・データ・ストア名は、「Oracle Application Access Controls Governorの構成」で説明されている手順の実行中に指定します。 |
|
|
dbuser |
SoDエンジンで使用されるデータベース上のスキーマ所有者のユーザー名を入力します。 このアカウントは、SoD処理中にApplication Access Controls Governorデータベースへのアクセスに使用されます。 注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
|
|
dbpassword |
SoDエンジンで使用されるデータベース上のスキーマ所有者のパスワードを入力します。 注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
|
|
jdbcURL |
SoDエンジンで使用されるデータベースに接続するためのJDBC URLを入力します。 注意: このパラメータは、Oracle Application Access Controls Governor固有のものです。 |
|
|
password |
APIコール用にSoDエンジンで作成されたアカウントのパスワードを入力します。 |
|
|
port |
SoDエンジンがリスニングを行うポートの番号を入力します。 |
|
|
server |
SoDエンジンが稼働しているホスト・コンピュータのIPアドレスを入力します。 |
|
|
sslEnable |
SoDエンジンでHTTPS通信リクエストのみを受け入れる場合、 |
|
|
username |
SoDエンジンで作成されたアカウントのユーザー名を入力します。このアカウントは、SoD検証中に使用されるSoDエンジンAPIのコールのために使用されます。 |
|
|
注意: Oracle Identity Managerインストールのライフサイクル中には随時、登録スクリプトを複数回実行できます。たとえば、新規のSoDエンジンを登録するとします。スクリプトの実行時に、入力を行う必要のあるセクション（一連のプロンプト）に導くプロンプトを使用します。残りのセクションはスキップできます。 登録スクリプトの実行例は、例13-1を参照してください。この例では、SoDエンジンの情報を指定するためにITリソースが作成されているものと仮定します。 |
スクリプトを実行し、Oracle Identity Managerインストール、SoDエンジンおよびターゲット・システムの登録情報を指定する手順は次のとおりです。
<!-- SIL DB Parameters for jdbc connectivity --> <directDB> <driver>@jdbcDriver</driver> <url>@jdbcUrl</url> <username>@dbUserName</username> <password encrypted="false">@dbPassword</password> </directDB>これらの行で、次の文字列を使用するデータベースの値に置き換えます。
com.microsoft.sqlserver.jdbc.SQLServerDriver
Oracle Databaseのサンプル・ドライバ:
oracle.jdbc.driver.OracleDriver
@jdbcUrl
この文字列を、使用するデータベースのJDBC URLに置き換えます。
Microsoft SQL ServerのサンプルURL:
jdbc:sqlserver://HOST_NAME/IP_ADDRESS:DATABASE_PORT;
DatabaseName=DATABASE_NAME
Oracle DatabaseのサンプルURL:
jdbc:oracle:thin:@HOST_NAME/IP_ADDRESS:DATABASE_PORT:SID
@dbUserName
この文字列を、SoD処理に使用するデータベース・アカウントのユーザー名に置き換えます。
@dbPassword
この文字列を、SoD処理に使用するデータベース・アカウントのプレーン・テキストのパスワードに置き換えます。
SILConfig.xmlファイルを保存して閉じます。
Microsoft Windowsの場合: SIL_HOME/scripts/registration.bat
UNIXの場合: SIL_HOME/scripts/registration.sh
OIM_HOMEを検索します。
OIM_HOME = /Installations/OIM9102/server/xellerate
Which Security Model you want to use? (1 or 2) 1) Idm System 2) SoD Invocation Library
1を入力します。1を入力すると、登録スクリプトで入力したOIM_HOMEディレクトリのフルパスが表示されます。次に例を示します。
/Installations/OIM9102/server/xellerate
2を入力します。キーストアを生成するかどうかの指定を要求されます。
Generate new Keystore?(y/n)
yを入力します。キーストアのパスワードの設定を要求されます。
Generating Keystore Password for DB Access:
次の行は、暗号化されたパスワードの値の例です。
Encrypted value of password: cuMcTHK60ZMa+HnX2FK9vw== Keystore Generated, Copy Encrypted Password in SIL_Config."
暗号化されたパスワードをコピーする必要のあるSILConfig.xmlファイル内のコード・ブロックは、次のとおりです。
<Security> <!-- Symmetric Encryption Provider implementation java class. A sample value is "oracle.iam.grc.sod.encryption.DefaultDBEncryptionImpl"--> <!--<SymmetricProvider>@providerClass</SymmetricProvider>--> <SymmetricProvider>oracle.iam.grc.sod.encryption.DefaultDBEncryptionImpl
</SymmetricProvider> <XLSymmetricProvider> <KeyStore> <!-- Location of the generated keystore, used during database level encryption. The value of the directory location including the filename of the keystore should be relative to SIL home directory. A sample value is "security/.silkeystore"--> <!--<Location>@keystoreLocation</Location>--> <Location>security/.silkeystore</Location> <!-- Keystore password. It should be first encrypted using "Encryptpassword.bat" and the encrypted value should be defined below. A sample value is "RN2+ji9vQ1OX6l/BQ6hPUA=="--> <Password encrypted="true">@keystorePassword</Password> <!-- Keystore Type. A sample value is "JCEKS"--> <!--<Type>@keystoreType</Type>--> <Type>JCEKS</Type> <!-- Keystore provider. A sample value is "com.sun.crypto.provider.SunJCE"--> <!--<Provider>@providerClass</Provider>--> <Provider>com.sun.crypto.provider.SunJCE</Provider> </KeyStore> <Keys> <DBSecretKey> <!-- Alias for the symmetric key. Should be same the value of parameter "alias" in "SetDBKey.bat". A sample value is "sil"--> <!--<Alias>@alias</Alias>--> <Alias>sil</Alias> <!-- Key password. It should be first encrypted using "Encryptpassword.bat" and the encrypted value should be defined below. A sample value is "RN2+ji9vQ1OX6l/BQ6hPUA=="--> <Password encrypted="true">@keyPassword</Password> <!-- Block Mode for the symmetric key. A sample value is "CBC"--> <!--<BlockMode>@keyBlockMode</BlockMode>--> <BlockMode>CBC</BlockMode> </DBSecretKey> </Keys> </XLSymmetricProvider> </Security>
Do you want to proceed with registration? (y/n)
yを入力します。Oracle Identity Managerインストールを登録するかどうかの指定を要求されます。
Register System Instance for type OIM?(y/n)
yを入力します。
Provide instance name
oim0
Register System Instance for type EBS? (y/n)
yを入力します。使用しない場合は、nを入力します。
yを入力すると、Oracle E-Business Suiteインストールのインスタンス名の入力を要求されます。
Provide instance name
Oracle E-Business Suiteインストールの名前を入力します。次に例を示します。
ebs2
Register System Instance for type OAACG? (y/n)
yを入力すると、Oracle Application Access Controls Governorインストールのインスタンス名の入力を要求されます。
Provide instance name
Oracle Application Access Controls Governorインストールの名前を入力します。次に例を示します。
oaacg01
OIM ITResource Instance Name:
作成したITリソース名OAACG ITR2を入力します。
nを入力します。
例13-1は、登録スクリプトの実行例の出力を示しています。ここでは、SoDエンジンの情報を指定するためにITリソースが作成されているものと仮定します。
Which Security Model you want to use?(1 or 2) 1) IdM System 2) SoD Invocation Library 1 OIM_HOME provided by you via Registration.bat is: C:¥OIM_installations¥wls_ibm_2 ¥installation¥xellerate Do you want to proceed with registration? (y/n) y log4j:WARN No appenders could be found for logger (XELLERATE.JAVACLIENT). log4j:WARN Please initialize the log4j system properly. Register System Instance for type OIM ?(y/n) y Provide instance name oim1 Register System Instance for type EBS ?(y/n) y Provide instance name ebs1 Register System Instance for type OAACG ?(y/n) y Provide instance name oaacg1 OIM ITResource Instance Name: OAACG ITR2 Register System Instance for type SAP ?(y/n) n Register System Instance for type GRC ?(y/n) n
登録プロセスの最後に、システム・タイプ名がOracle Identity Managerデータベースで設定されます。これらの名前は、登録スクリプトを使用してデータベースから取得できます。これらの名前は、取得後にSILConfig.xmlファイルに入力する必要があります。
サービス・コンポーネント名を取得し、記録する手順は次のとおりです。
SIL_HOME/script
Microsoft Windowsの場合:
registration.bat printRegistrationIDs
UNIXの場合:
registration.sh printRegistrationIDs
このコマンドの出力例は、次のとおりです。
----------------------------------------------- System Type Instance Name Registration ID ----------------------------------------------- OIM oim 1 EBS Ebs 2 OAACG oaacg 3
次のXMLのブロックは、Topologies要素とその子要素を示しています。
<Topologies> <Topology> <name>@topologyName</name> <IdmId>@Idm RegistrationId</IdmId> <SodId>@Sod RegistrationId</SodId> <SDSId>@Sds RegistrationId</SDSId> </Topology> </Topologies>
Topologies要素の次の子要素の値を入力します。
クラスタ化環境では、SIL_HOMEディレクトリをクラスタの各ノードにコピーします。さらに、このディレクトリの構造が、クラスタのすべてのノードで同じであることを確認します。
次の手順のいずれかを実行します。
Oracle Application Access Controls GovernorとOracle Identity Manager間のSSL通信を有効にする手順は次のとおりです。
keytool -genkey -alias tomcat -keyalg RSA -keystore JAVA_HOME/lib/security/.keystore keytool -certreq -alias tomcat -file JAVA_HOME/lib/security/xell.cvs -keystore JAVA_HOME/lib/security/.keystore keytool -export -alias tomcat -file JAVA_HOME/lib/security/server.cert -keystore JAVA_HOME/lib/security/.keystore
これらのコマンドの実行後、JAVA_HOME/lib/securityディレクトリにサーバー証明書（server.cert）が作成されます。
<Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" disableUploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="JAVA_HOME/lib/security/.keystore">
keytool -import -alias oaacg_trusted_cert -file JAVA_HOME/lib/security/server.cert -trustcacerts -keystore JAVA_HOME/lib/security/cacerts -storepass changeit
SAP GRCとOracle Identity Manager間のSSL通信を有効にするには、SAP GRCホスト・コンピュータで証明書を次のようにエクスポートします。
https://mysapserver01:50001/VirsaCCRiskAnalysisService/Config1?wsdl
keytool -import -alias sapgrc_trusted_cert -file JAVA_HOME/lib/security/ CERTIFICATE_FILENAME -trustcacerts -keystore JAVA_HOME/lib/security/
cacerts -storepass changeit
このコマンドの要素:
yesを入力します。「Certificate was added to keystore」というメッセージが表示されます。
SoD機能を有効にする手順は次のとおりです。
trueに設定します。
SAP GRCでは、リクエスト検証処理の結果を返すのに時間がかかる場合があります。必要に応じて、SAP GRCでSoD検証リクエストが即時に処理されるのを待つかわりに、指定時刻にSoD検証のリクエストが送信されるようにスケジュールを設定できます。つまり、SAP GRCでの同期SoD検証プロセスを非同期プロセスに変更できます。これを実行する手順は次のとおりです。
trueに設定します。
直接プロビジョニング中、SoD検証プロセスがSODCheckNotInitinitated状態またはSODCheckCompletedWithError状態のままの場合、「Resubmit Uninitiated Provisioning SOD Checks」スケジュール済タスクを実行して、SoD検証プロセスを開始することができます。このスケジュール済タスクを実行すると、プロセス・タスクの状態がSODCheckNotInitinitatedまたはSODCheckCompletedWithErrorからSODCheckPendingに変わります。SODCheckPending状態のタスクは、次回の「Get SOD Check Results Provisioning」スケジュール済タスクの実行で完了します。
リクエストベースのプロビジョニング中、SoD検証プロセスがSODCheckNotInitinitated状態またはSODCheckCompletedWithError状態のままの場合、「Resubmit Uninitiated Approval SOD Checks」スケジュール済タスクを実行して、SoD検証プロセスを開始することができます。このスケジュール済タスクを実行すると、プロセス・タスクの状態がSODCheckNotInitinitatedまたはSODCheckCompletedWithErrorからSODCheckPendingに変わります。SODCheckPending状態のタスクは、次回の「Get SOD Check Results Provisioning」スケジュール済タスクの実行で完了します。
かわりに、直接またはリクエストベースのプロビジョニングによる権限リクエスト・データの送信後、これらのスケジュール済タスクを手動で実行できます。
SoDは、有効にした後、次の手順を実行することによりいつでも無効にできます。
falseに設定します。
これらのプロセス・タスクの無効化の詳細は、コネクタのガイドを参照してください。
すべてのSoD関連イベントのロギングを有効にする手順は次のとおりです。
log4j.logger.XELLERATE.SOD=DEBUG
|
注意: この項で説明する手順は、Oracle E-Business Suite、SAP CUAおよびSAP R3以外のターゲット・システムを使用する場合のみ実行します。Oracle Application Access Controls GovernorおよびSAP GRC以外のSoDエンジンを使用する場合は、13.5項「SILプロバイダの作成」で示す手順も実行する必要があります。 この手順は、Oracle Identity ManagerでのSoDの最初の実装前、または実装後のいつでも実行できます。 |
新規ターゲット・システム用のSILを構成する手順の概要は次のとおりです。
次の前提条件には必ず対処してください。
Oracle Application Access Controls Governorを使用する場合、ターゲット・システムからロードしたデータを使用して、ポリシー定義を作成します。
SAP GRCを使用する場合、ターゲット・システムからロードしたデータを使用して、リスク定義を作成します。
詳細は、SoDエンジンのベンダーのドキュメントを参照してください。
変換レイヤーは、ターゲット・システムの属性値を、SoDエンジンで使用可能な値に変換するために使用されます。
IdMvsSoDDataTransformationOperインタフェースの実装として、変換レイヤーを作成する必要があります。
Oracle Application Access Controls Governorを使用する場合は、IdMvsSoDDataTransformationOperインタフェースの実装クラスで、transformInputメソッドの実装を作成します。
Oracle Application Access Controls Governor以外のSoDエンジンを使用する場合は、IdMvsSoDDataTransformationOperインタフェースの実装クラスで、transformInputメソッドおよびtransformSoDAnalysisInputメソッドの実装を作成します。
registration.xmlファイルで変換レイヤーの詳細を、次のように入力します。
<SystemType name="SYSTEM_TYPE_NAME" type="Sod Source DataStore"></SystemType> <ServiceComponent type="IdMvsSoDDataTransformationOper" name="NAME_FOR_IMPLEMENTATION" <Impl-Class>NAME_OF_IPMLEMENTATION_CLASS</Impl-Class> <IdMSystemType>OIM</IdMSystemType> <SoDEngineType>SoD_ENGINE</SoDEngineType> <srcSystemType>SYSTEM_TYPE_NAME</srcSystemType> <DataTransformation> <AttrSoD type="user" name="NAME_OF_ATTRIBUTE_ON_TARGET_SYSTEM" sourceIdMAttrName="NAME_OF_ATTRIBUTE_ON_SOD_ENGINE" isSourceKey="true"/> <AttrSoD type="user" name="firstname" sourceIdMAttrName="firstname" isSourceKey="false"/> <AttrSoD type="user" name="lastname" sourceIdMAttrName="lastname" isSourceKey="false"/> <AttrSoD type="duty" dutyType="ENTITLEMENT_TYPE" name="accessorigid" sourceIdMAttrName="ENTITLEMENT_NAME" isSourceKey="true"/> </DataTransformation> <DataTransformation> . . . </DataTransformation> <DataTransformation> . . . </DataTransformation> </ServiceComponent>
registration.xmlファイルでSystemType要素とServiceComponent要素を追加する際、次のガイドラインを適用します。
DBToOAACGのように指定します。
oracle.iam.grc.sod.scomp.impl.oaacg.transformation.IdMvsSoDDataTransformationOperDBvsOAACGのように指定します。
OAACGを入力します。SoDとしてSAP GRCを使用する場合は、GRCを入力します。カスタムSILプロバイダを使用する場合は、SoDエンジンに設定した名前を入力します。
ROLEのように指定します。
Resource Managerのように指定します。
この項では、次の手順について説明します。
SoD検証用承認ワークフローを変更する手順は次のとおりです。
SoDCheckStatus: このフィールドの有効値は、SoDCheckNotInitiated、SoDCheckResultPendingおよびSoDCheckCompletedです。SoDCheckNotInitiatedをこのフィールドのデフォルト値に設定します。
SoDCheckTrackingID: SoD検証プロセスが開始されると、SoDフレームワーク・ライブラリからこのフィールドの文字列値が返されます。値は後から、SoD検証プロセスの結果のポーリングに使用できます。
SoDCheckResult: このフィールドの有効値は、PassedおよびFailedです。
SoDCheckTimestamp: このフィールドには、SoD検証プロセスの結果が生成された日時が表示されます。
SoDCheckViolation: このフィールドには、リクエストおよび対応する権限が違反したSoDエンジンでのポリシーが表示されます。このフィールドの長さを4000文字に設定します。
次のスクリーンショットは、親オブジェクト・フォームの例を示しています。
次のスクリーンショットは、このパラメータが追加されたITリソースの例を示しています。
次のプロセス・タスクを承認ワークフローに追加します。
「Required for Completion」に設定する必要があります。次のスクリーンショットには、SODCheckerタスクの例が表示されています。
次のスクリーンショットに、これが示されています。
「Required for Completion」としてマークする必要があります。このタスクの生成は、SODCheckerタスクの完了に依存します。 次のスクリーンショットは、ワークフローにアタッチされたヒューマン承認タスクを示しています。
さらに、ヒューマン承認タスクは、SODCheckCompletedレスポンス・コードの受信時に生成される必要があります。次のスクリーンショットは、SODCheckerタスクの完了と同時に生成されるタスクとしてアタッチされた「Manager Approval」タスクを示しています。
次のスクリーンショットは、SODResolverユーザーに割り当てられた2番目の承認タスクを示しています。
次のスクリーンショットは、違反が発生した場合に生成されるタスクとしてアタッチされた、2番目の承認タスクを示しています。
このワークフローによれば、SoD検証プロセスが正常に完了した場合、システム管理者に承認タスクが割り当てられます。しかし、違反が発生した場合は、承認タスクはSODResolverによって識別されたユーザーに割り当てられます。このユーザーは、競合する権限の1つを削除して、競合を解決することを求められます。
または、自分の操作環境で、違反が発生した場合に、プロビジョニング・リクエストを却下することができます。これは、SODCheckViolationレスポンス・コードを「Cancelled (X)」タスク・ステータスにマップすることで実現します。違反が発生した場合、SODCheckerタスクが取り消され、プロビジョニングはそれ以上進みません。
アダプタでは、次のSoD分析フォームのいずれかを開始します。
アダプタは即時に結果を返し、親オブジェクト・フォームではSoDCheckStatusがSoDCheckCompletedに設定されます。違反がない場合、アダプタはSODCheckerタスクをCompletedに設定します。その結果、SoDCheckerタスクによりリクエストを承認できます。違反がある場合は、SODCheckViolationレスポンス・コードが返されます。
アダプタにより親オブジェクト・フォームでSoDCheckStatusがSoDResultPendingに設定され、タスク・ステータスがPendingに設定されます。1回のAPIコールでは、アダプタは結果を返しません。結果を収集するためのSIL APIをコールするスケジュール済タスクを実行する必要があります。このスケジュール済タスクでは、承認待ちで、SoDタイプ（SODCheckerの接頭辞付き）であり、親オブジェクト・フォームで対応するSoDCheckStatusがSoDResultPendingであるプロセス・タスクを探します。このようなタスクごとに、スケジュール済タスクがトラッキングID値を取得し、SoDフレームワーク・ライブラリを起動して、SoDの結果を取得します。SoDの結果が取得できれば、SoDCheckStatusがSoDCheckCompletedに更新されます。また、SoDCheckResultフィールドとSoDCheckViolationフィールドが、返された値により適切に更新され、タスクは結果に基づいて完了または却下されます。
承認を与える前に、最初の承認者が権限データを変更できるようにする場合、マルチレベル承認システムが必要になります。この場合、SODResolverユーザーが、競合しない権限を提供すると信頼されているか、SODResolverユーザーがリクエストを承認した後、SoD検証が再実行される必要があります。
マルチレベル承認を実装する手順は次のとおりです。
次のスクリーンショットは、SODCheckerタスクの例を示しています。
この場合、タスクが2つ、承認レベルが2つになります。
Manager Approval: 条件付き、完了に必要、レスポンス・コードがSODCheckCompletedのときにSODCheckerの完了と同時に生成
Manager Approval1: 条件付き、完了に必要、レスポンス・コードがSODCheckViolationのときにSODCheckerの完了と同時に生成
Manager Approval2: 条件付き、完了に必要、SODChecker1の完了と同時に生成
各プロセス定義には、権限をユーザーにプロビジョニングするために、1つのプロセス・タスクがアタッチされています。SoD検証プロセスは、このタスクをトリガーする前、ターゲット・システムで権限を保持する子表にすべてのデータを挿入した直後に実行する必要があります。したがって、子表にデータを挿入した後、SoD検証プロセスが完了するまで、このプロセス・タスクを保持する必要があります。これを実行するには、ユーザーへの権限のプロビジョニングに先行する「Holder」タスクを作成します。
「Holder」タスクは、SoD検証プロセスが完了する前に、ユーザーにリソースをプロビジョニングすることを防ぐために追加されます。ユーザー権限は、このタスクが完了した場合にのみプロビジョニングされます。SoDエンジンで、権限の割当てがSoDポリシーまたはルールに違反していないことが検証されると、このタスクは完了します。
SoD検証プロセスがヒューマン承認の前に実行された場合、SoD検証プロセスは、プロビジョニング・レベルでSoD検証プロセスが有効になっていても、再実行する必要がありません。SoD検証プロセスを実行する必要があるかないかは、プロビジョニング・レベルでのSoD検証プロセスの前に、次のチェックを行うことにより評価できます。
SoDCheckCompletedに設定されていますか。
SoD検証用プロビジョニング・ワークフローを変更する手順は次のとおりです。
次のスクリーンショットは、この「Holder」タスクを示しています。
次のスクリーンショットは、「Holder」タスクに依存するOracle E-Business User Managementコネクタのすべての権限タスクを示しています。
次のスクリーンショットは、「Add Responsibility to User」タスクに先行するタスクとして「Holder」タスクを示しています。
次のスクリーンショットは、このSODCheckerタスクを示しています。
次のレスポンス・コードをSODCheckerタスクにアタッチします。
次のスクリーンショットには、これらのレスポンス・コードが表示されています。
子プロセス・フォーム表では、異なるタイプの複数値データ（ロール・データ、プロファイル・データおよびアドレス情報など）を保持できます。SoD処理に使用する権限データを保持している子プロセス・フォーム表をマークする必要があります。詳細は、14.4項「子プロセス・フォームでの権限属性のマーク」を参照してください。
新規ターゲット・システムを登録するには、次の項で説明されている手順を実行します。
|
注意: この項で説明する手順は、Oracle Application Access Controls GovernorおよびSAP GRC以外のSoDエンジンを使用する場合にのみ実行してください。Oracle E-Business Suite、SAP CUAおよびSAP R3以外のターゲット・システムを使用する場合は、13.4項「SoD用コネクタの構成」で説明されている手順も実行する必要があります。 SILプロバイダの作成を開始する前に、SoDエンジンをインストールする必要があります。 この手順は、Oracle Identity ManagerでのSoDの最初の実装前、または実装後のいつでも実行できます。 |
SILプロバイダを作成する手順の概要は次のとおりです。
次の前提条件には必ず対処してください。
次のサービス・コンポーネントのJava実装を作成します。
registration.xmlファイルで変換レイヤーの詳細を、次のように入力します。
新規SILプロバイダを登録するには、次の項で説明されている手順を実行します。
|
 Copyright © 2009 Oracle Corporation. All Rights Reserved. |
|