| Oracle® Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド 11g リリース1(11.1.1) B56242-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Identity Managementアプリケーション開発者ガイド 11g リリース1(11.1.1) B56242-05 |
|
前 |
次 |
10g(10.1.4.0.1)には、様々な使用方法に対して最適化された、2つの補完的な製品が用意されています。
Oracle Identity Manager(旧Oracle Xellerate IP)は、ディレクトリ、データベース、メインフレーム、独自のテクノロジ、フラット・ファイルなどを含む、大きく異なる技術で構成された複雑な環境を管理するために設計されたエンタープライズ・プロビジョニング・プラットフォームです。Oracle Identity Managerには、豊富な一連の監査およびコンプライアンス機能に加え、様々な機能を持つワークフローおよびポリシー機能が備わっています。
アイデンティティ管理インフラストラクチャのコンポーネントであるOracle Directory Integration and Provisioningは、ディレクトリを中心とする環境において、ディレクトリの同期やプロビジョニング・タスクを実行するために設計されたメタディレクトリ・テクノロジです。Oracle Directory Integration and Provisioningは、ディレクトリおよび互換性のあるOracle製品で構成される、より同質性の高い環境を管理するよう設計されています。Oracle Directory Integration and Provisioningは、データの同期を使用してプロビジョニング・タスクを行います。ワークフローおよびフル機能のポリシー・エンジンが不要な場合、Oracle Directory Integration and Provisioningにより少量のデプロイメント・フットプリントが用意されます。
Oracle Internet Directory SDKにはOracle Directory Integration and Provisioningユーザー・プロビジョニングAPIが含まれ、ユーザーとそのアプリケーション・プロパティをOracle Identity Managementインフラストラクチャで管理できます。この章では、このAPIの主要機能と使用方法について説明します。
この章では、次の項目について説明します。
アプリケーションをプロビジョニング可能な状態にするには、プロビジョニング・システムに登録する必要があります。コマンドライン・インタフェースを使用してOracle Internet Directoryに独自の構成を作成する必要もあります。アプリケーション構成を表示するためのJavaクラスが存在します。
この項の項目は次のとおりです。
プロビジョニング・システムに登録するためには、アプリケーションでプロビジョニング構成を作成する必要があります。プロビジョニング構成が存在すると、ディレクトリ対応であり、プロビジョニングが可能なアプリケーションとしてプロビジョニング・システムに認識されます。
アプリケーションでは、次の手順によりプロビジョニング構成を作成します。
通常、Oracleアプリケーションは、$ORACLE_HOME/jlibにあるrepository.jarファイルのリポジトリAPIを使用して自己登録を行います。このファイルは、アプリケーション登録専用としてインストール時に配置されます。リポジトリAPIは、Oracle Internet Directoryにアプリケーション・エントリを作成する場合だけでなく、アプリケーションを権限グループに追加する場合にも使用できます。
ただし、顧客が作成したアプリケーションでは、アプリケーション登録にrepository.jar APIを使用することはできません。そのため、アプリケーション開発者は、LDIFテンプレートを使用し、LDAPコマンドでOracle Internet Directoryにアプリケーション・エントリを作成する必要があります。
次のいずれかのコンテナの下に、アプリケーション独自のコンテナを作成する必要があります。
cn=Products,cn=OracleContext: 複数レルムのユーザーにサービスを提供するアプリケーション用
"cn=Products,cn=OracleContext,RealmDN": 特定レルムのユーザーにサービスを提供するアプリケーション用
特定レルム用としてアプリケーションを構成すると、そのアプリケーションでは、他のレルムのユーザーを管理できません。ほとんどの場合、Oracle Internet Directoryの特定レルムに関連付けないように、アプリケーションを任意のアイデンティティ管理レルムの外部に作成する必要があります。
アプリケーションの新しいインスタンスがインストールされると、アプリケーション・インスタンスに対する個別エントリがアプリケーションのコンテナに作成されます。プロビジョニング構成には、特定タイプのすべてのインスタンスで共通のものとインスタンス固有のものがあります。企業内にアプリケーションのインスタンスが複数デプロイされている場合、各インスタンスはそれぞれ独立しています。各インスタンスは個別のプロビジョニング可能なアプリケーションとして定義されます。このアプリケーションの1つ以上のインスタンスにアクセスできるように、ユーザーは、このアプリケーションの1つ以上のインスタンスに対してプロビジョニングできます。
この項の例では、Oracle Filesに似たサンプル・アプリケーションを扱います。このアプリケーションの最初のインスタンスをインストールするときに、Oracle Internet Directoryに特定のエントリを作成する必要があります。次の例において、実行時に選択されるこのアプリケーションの名前はFiles-App1であり、アプリケーションのタイプはFILESです。このアプリケーションは、必要に応じてインスタンス化してOracle Internet DirectoryにアップロードできるLDIFテンプレートを持つことができます。この例では、アプリケーションのアイデンティティは任意のレルムの外部にあります。つまり、"cn=Products,cn=OracleContext"コンテナ下です。
dn: cn=FILES,cn=Products,cn=OracleContext changetype: add objectclass: orclContainer dn: orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext changetype: add orclappfullname: Files Application Instance 1 userpassword: welcome123 description: This is a test Appliction instance. protocolInformation: xxxxx orclVersion: 1.0 orclaci: access to entry by group="cn=odisgroup,cn=DIPAdmins, cn=Directory Integration Platform,cn=Products, cn=OracleContext" (browse,proxy) by group="cn=User Provisioning Admins, cn=Groups,cn=OracleContext" (browse,proxy) orclaci: access to attr=(*) by group="cn=odisgroup,cn=DIPAdmins, cn=Directory Integration Platform,cn=Products, cn=OracleContext" (search,read,write,compare) by group="cn=User Provisioning Admins, cn=Groups,cn=OracleContext" (search,read,write,compare)
この例でのACLの詳細は、「アプリケーション・ユーザー・データの場所」を参照してください。
アプリケーションでは、一部のプロビジョニング・サービスとプロビジョニング管理者に一定の権限を付与します。
このアプリケーションの2番目のインスタンスをインストールする場合、Oracle Directory Integration and Provisioningに次のエントリを作成する必要があります。この例では、実行時に決定されるこのアプリケーションの名前をFiles-App2とします。
dn: orclApplicationCommonName=Files-App2,cn=FILES,cn=Products,cn=OracleContext changetype: add orclappfullname: Files Application Instance 2 userpassword: welcome123 description: This is a test Appliction instance. orclVersion: 1.0 orclaci: access to entry by group="cn=odisgroup, cn=DIPAdmins,cn=Directory Integration Platform,cn=Products, cn=OracleContext" (browse,proxy) by group="cn=User Provisioning Admins, cn=Groups,cn=OracleContext" (browse,proxy) orclaci: access to attr=(*) by group="cn=odisgroup,cn=DIPAdmins, cn=Directory Integration Platform,cn=Products, cn=OracleContext" (search,read,write,compare) by group="cn=User Provisioning Admins,cn=Groups,cn=OracleContext" (search,read,write,compare)
アプリケーションのエントリが正常に作成されると、アプリケーションのアイデンティティがOracle Internet Directoryに登録されます。アプリケーションに特定の権限が必要な場合、この時点でアプリケーションをOracle Internet Directoryの特定の権限グループに追加できます。表12-1「一部の有用な権限グループ」に、アプリケーションで自身を追加できる権限グループを示します。これらの各グループは、すべてのレルムに存在し、また、RootOracleContextにも存在します。RootOracleContextグループは、すべてのレルムのグループ・メンバーです。
表12-1 一部の有用な権限グループ
| グループ名 | 権限 |
|---|---|
|
OracleDASCreateUser |
パブリック・ユーザーの作成 |
|
OracleDASEditUser |
パブリック・ユーザーの編集 |
|
OracleDASDeleteUser |
パブリック・ユーザーの削除 |
|
OracleDASCreateGroup |
新規パブリック・グループの作成 |
|
OracleDASEditGroup |
パブリック・グループの編集 |
|
OracleDASDeleteGroup |
パブリック・グループの削除 |
たとえば、次のLDIFファイルを使用すると、すべてのレルムでユーザーを作成する権限を付与するcn=OracleCreateUserに、Files-App1アプリケーションを追加できます。
dn:cn=OracleCreateUser,cn=Groups,cn=OracleContext changetype: modify add: uniquemember uniquemember: orclApplicationCommonName=Files-App1,cn=FILES,cn=Products,cn=OracleContext
アプリケーションのプロビジョニング構成はそのアプリケーションのプロビジョニング・プロファイルで管理されています。プロビジョニング・システムは、バージョン1.1、2.0および3.0の3つの異なるバージョンのプロビジョニング・プロファイルをサポートします。プロビジョニング・サービスはプロファイルのバージョンごとに異なるサービスを提供します。一部の汎用構成の詳細はバージョンに関係なく、すべてのアプリケーションで共通です。
プロビジョニング構成バージョン間の差異
バージョン3.0のプロファイルとバージョン2.0および1.1のプロファイルとの違いは、次のとおりです。
新しいプロビジョニング・フレームワークでは、バージョン3.0のアプリケーションのみが認識されます。したがって、プロビジョニング対象のアプリケーションとしてOracleプロビジョニング・コンソールに表示されるのは、バージョン3.0のプロビジョニング・プロファイルを保持するアプリケーションのみです。バージョン2.0および1.1のプロファイルを保持するアプリケーションは、プロビジョニング対象のアプリケーションとしてプロビジョニング・コンソールに表示されません。ただし、これらのアプリケーションに構成されているイベントの情報は、アプリケーションに通知されます。
バージョン3.0のプロファイルでは、アプリケーションのプロビジョニング構成の作成は複数ステップのプロセスです。旧バージョンのプロファイルでは、プロビジョニング登録には単一のステップのみが必要とされます(oidprovtoolコマンドの実行)。
アプリケーションは、様々なインタフェースを使用してプロビジョニング・イベントをサブスクライブできます。JavaおよびOID-LDAPの2つのインタフェースは、プロビジョニング構成のバージョン3.0と併用されるインタフェース・バージョン3.0でのみ使用可能です。表12-2「インタフェースとその構成」を参照してください。
アプリケーションでは、LDIFファイルで、そのアプリケーション固有のユーザー属性の構成を指定できます。これは、プロビジョニング構成のバージョン3.0と併用されるインタフェース・バージョン3.0でのみサポートされます。第12.1.1.2.6項「アプリケーション・ユーザー属性とデフォルト値の構成」を参照してください。
『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』に記載されているユーザーのプロビジョニング・ステータスは、バージョン3.0のアプリケーションについてのみ保持されます。バージョン3.0より前のプロファイルを使用するアプリケーションのプロビジョニング・ステータスは、保存されません。
イベント伝播の構成パラメータは、バージョンごとに変化します。表12-5「イベント伝播のパラメータ」を参照してください。
バージョン3.0固有のプロビジョニング構成
特に記載のないかぎり、この項ではこれより、バージョン3.0に固有のプロビジョニング構成について説明します。図12-1に、プロビジョニング構成の格納に使用されるOracle Internet DirectoryのDITを示します。すべてのプロビジョニング構成情報は、次のコンテナの下に配置されます。
cn=Provisioning,cn=Directory Integration Platform,cn=Products,cn=OracleContext
共通のプロビジョニング構成情報は、次のコンテナの下のエントリに格納されます。
cn=Profiles,cn=Provisioning,cn=Directory Integration Platform, cn=Products,cn=OracleContext
残りのアプリケーション用のプロビジョニング構成は、次のコンテナの下に配置されます。
cn=ApplicationType,cn=Applications,cn=Provisioning,
cn=Directory Integration Platform,cn=Products,cn=OracleContext
特定のアプリケーション・タイプのすべてのインスタンスは、このコンテナの下にある構成を共有します。つまり、既存のアプリケーション・タイプの2つ目のインスタンスがプロビジョニング・プロファイルを作成すると常に、"cn=ApplicationType"コンテナ内のすべての構成情報が共有されます。
Profilesコンテナには、次のタイプの構成情報が含まれます。
アプリケーション・インスタンスによってプロファイルが作成されると、その新規プロファイルは、常に次の名前書式でProfilesコンテナの下の個別エントリに格納されます。
orclODIPProfileName=GUID_of_the_Realm_Entry_GUID_of_the_Application_Identity,….
プロビジョニング構成の作成時に、アプリケーションの次の情報を指定する必要があります。
アプリケーションの各インスタンスは、次のパラメータで一意に識別されます。
アプリケーション識別名: アプリケーションを示すOracle Internet Directory内の一意の識別名。これは必須パラメータです。
アプリケーション・タイプ: 同一アプリケーションのすべてのインスタンスに共通のパラメータ。一部の構成は、特定タイプの複数のインスタンスで共有できます。これは必須パラメータです。
アプリケーション名: このパラメータは、個別に指定できます。指定しない場合、識別名から抽出されます。これはオプション・パラメータです。
アプリケーション表示名: ユーザーにわかりやすいアプリケーション名。この名前は、プロビジョニング可能なターゲット・アプリケーションとしてプロビジョニング・コンソールに表示されます。これはオプション・パラメータです。
プロビジョニング・プロファイルの作成時にこれらのアプリケーションのアイデンティティのパラメータを指定するには、$ORACLE_HOME/bin/oidprovtoolコマンドライン・ユーティリティにそれぞれ次の引数を使用します。
application_type
application_dn
application_name
application_display_name
|
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の |
特定レルムのユーザーのみにサービスを提供するには、そのレルムを対象にアプリケーションを登録します。アプリケーションでサービスを提供するレルムごとに、個別のプロビジョニング・プロファイルを作成する必要があります。複数レルムのシナリオ(ホスティングされたOracle Portalシナリオなど)では、個々のレルムを対象にアプリケーションを登録する必要があります。
レルムのプロビジョニング管理者がプロビジョニング・コンソールにアクセスすると、プロビジョニング可能なターゲット・アプリケーションとして、そのレルムに登録されているアプリケーションのみが表示されます。
プロビジョニング・プロファイルの作成時にレルム情報を指定するには、organization_dn引数付きで$ORACLE_HOME/bin/oidprovtoolコマンドライン・ユーティリティを使用します。
|
関連項目: 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の |
プロビジョニング・プロファイルの作成時に、プロビジョニング・コンソールでそのアプリケーションに対するプロビジョニングを管理するかどうかを指定できます。管理しない場合、そのアプリケーションは、プロビジョニング・コンソールにプロビジョニング対象として表示されません。ただし、Oracle Directory Integration and Provisioningでは、通常どおりこのプロファイルが処理され、イベントが伝播されます。
プロビジョニング・プロファイルの作成時にこの情報を指定するには、$ORACLE_HOME/bin/oidprovtoolコマンドライン・ユーティリティにapplication_isdasvisible引数を使用します。デフォルト値はTRUEです。
デフォルトで該当レルム内のすべてのユーザーをアプリケーションにプロビジョニングするか、どのユーザーもプロビジョニングしないかを決定するためのデフォルト・ポリシーを構成できます。有効な値は次のとおりです。
PROVISIONING_REQUIRED: デフォルトですべてのユーザーをプロビジョニングします。
PROVISIONING_NOT_REQUIRED: デフォルトでユーザーをプロビジョニングしません。
デフォルト値はPROVISIONING_REQUIREDです。
アプリケーション付属のポリシー・プラグインを使用して、デフォルト・ポリシーを実行時に上書きできます。また、管理者は、デフォルト・ポリシーとポリシー・プラグインの決定を両方とも上書きできます。
デフォルト・ポリシー情報を指定するには、$ORACLE_HOME/bin/oidprovtoolコマンドライン・ユーティリティにdefault_provisioning_policy引数を使用します。
アプリケーション固有のユーザー情報は、アプリケーション固有のコンテナに格納されます。このデータをプロビジョニング・システムで管理する場合、プロビジョニングの登録時にこれらのコンテナの場所を指定する必要があります。ユーザー・データの場所を指定するには、$ORACLE_HOME/bin/oidprovtoolコマンドライン・ユーティリティにuser_data_location引数を使用します。このコンテナに対するACLでOracle Delegated Administration ServicesおよびOracle Directory Integration and Provisioningによるこのコンテナでの情報の管理が許可されることをアプリケーションで確認します。
アプリケーションは、PLSQL、Java、OID-LDAPなどの様々なインタフェースを使用してプロビジョニング・イベントをサブスクライブできます。表12-2「インタフェースとその構成」に、サポートされるインタフェースと対応する構成をリストします。INTERFACE_VERSIONは、プロビジョニング・プロファイルのバージョンに合せてください。
表12-2 インタフェースとその構成
| 構成パラメータ | PL/SQL | Java | OID-LDAP |
|---|---|---|---|
|
INTERFACE_VERSION |
1.1、2.0、3.0 |
3.0 |
3.0 |
|
INTERFACE_NAME |
インタフェースを実装するPL/SQLパッケージの名前 |
未使用 |
未使用 |
|
INTERFACE_CONNECT_INFO |
データベース接続文字列。すべてのバージョンでサポートされる複数の書式です。 |
未使用 |
未使用 |
|
INTERFACE_ADDITIONAL_INFO |
未使用 |
未使用 |
未使用 |
|
プラグイン・タイプ |
PRE_DATA_ENTRY、POST_DATA_ENTRY、DATA_ACCESS |
PRE_DATA_ENTRY、POST_DATA_ENTRY、DATA_ACCESS、EVENT_DELIVERY (MUST) |
PRE_DATA_ENTRY、POST_DATA_ENTRY、DATA_ACCESS |
|
説明 |
主にOracleデータベースのバックエンドを基盤とするアプリケーションが対象です。DIPサーバーは、PL/SQLプロシージャを起動してリモート・データベースにイベントを送信します。 |
インタフェース・タイプがJAVAの場合、イベント配信プラグインを構成する必要があります。構成されていない場合、サーバーでエラーが発生します。プラグイン構成により残りの構成が決定されます。第12.1.1.2.7項「アプリケーション・プロビジョニング・プラグインの構成」を参照してください。 |
主に、アプリケーションがOracle Internet Directoryと緊密に統合されており、PL/SQLインタフェースまたはJavaイベント配信プラグインによるイベント配信が不要な場合に使用されます。このインタフェースは、将来的に非推奨になります。かわりにJavaインタフェースを使用してください。 |
イベント・インタフェース構成を指定する場合、$ORACLE_HOME/bin/oidprovtoolに次の引数を使用できます。
interface_type(デフォルトはPLSQL)
interface_version(デフォルトは2.0)
interface_name
interface_connect_info
interface_additional_info
表12-3「PL/SQLインタフェースでサポートされる情報の書式」に、リモート・データベースに接続する場合にPL/SQLインタフェースでサポートされるインタフェース接続情報の書式をリストします。すべてのインタフェース・バージョンですべての書式がサポートされます。
表12-3 PL/SQLインタフェースでサポートされる情報の書式
| 書式 | 説明 |
|---|---|
|
dbHost:dbPort:dbSID:username:password |
古い書式であり、推奨されません。Oracle Directory Integration and Provisioningでこの情報をシンJDBCドライバに渡します。 |
|
dbHost:dbPort:dbServiceName:username:password |
新しい書式です。高可用性実装では、データベース・ホストおよびポートが変わる可能性があるため、推奨されません。DIPでは、この情報がシンJDBCドライバに渡されます。 |
|
DBSVC=DB_TNS_Connect_Sring_Alias:username:password |
JDBCシックOCIドライバで使用されます。ローカルの |
|
DBURL=ldap://LDAP_host:LDAP_port/ServiceName,cn=OracleContext |
高可用性の要件に対応した推奨書式です。DIPはこれをシンJDBCドライバに渡し、ドライバはOracle Internet Directoryでデータベース登録エントリを検索して実際のデータベース接続情報を取得します。 |
サポートされる書式の例は、次のとおりです。
localhost:1521:iasdb:scott:tiger
localhost:1521:iasdbsvc:scott:tiger
DBSVC=TNSALIAS:scott:tiger
DBURL=ldap://example.com:3060/samplegdbname:scott:tiger
アプリケーションでは、LDIFファイルで、そのアプリケーション固有のユーザー属性の構成を指定できます。これは、バージョン3.0のインタフェースでのみサポートされます。
図12-1「プロビジョニング構成データのディレクトリ情報ツリー」に示すとおり、特定の属性に対する構成は、コンテナ下に別のエントリとして格納されます。
"cn=Attributes,cn=User Configuration,cn=Attribute configuration,
cn=Application_Type,cn=Applications,cn=Provisioning,
cn=Directory Integration Platform,cn=Products,cn=OracleContext"
この情報をアップロードするためのoidprovtoolの引数はありません。LDAPファイルとコマンドライン・ツールを使用して、属性の構成情報をOracle Internet Directoryにアップロードする必要があります。
各アプリケーションに固有の属性は、個別のエントリとして示されます。次の例は、属性orclFilesDomainを対象としています。
dn: cn=orclFilesDomain,cn=Attributes,cn=User configuration,cn=Attribute configuration,…… changetype: add orcldasadminmodifiable: 1 orcldasviewable: 1 displayname: Files Domain orcldasismandatory: 1 orcldasuitype: LOV orcldaslov: us.example.com orcldaslov: uk.example.com orclDASAttrIsUIField: 1 orclDASAttrIsFieldForCreate: 1 orclDASAttrIsFieldForEdit: 1 orclDASAttrToDisplayByDefault: 1 orclDASSelfModifiable: 1 orclDASAttrDisplayOrder: 1 orclDASAttrDefaultValue: us.example.com orclDASAttrObjectClass: orclFILESUser objectclass: orclDASConfigAttr objectclass: orclcontainer
表12-4「属性の構成エントリに属性として格納されるプロパティ」に、属性の構成エントリに属性として格納される各プロパティの意味を示します。
表12-4 属性の構成エントリに属性として格納されるプロパティ
| プロパティ名 | 説明 | コメント |
|---|---|---|
|
orclDASIsUIField |
このプロパティがDASコンソールに表示されるかどうかを示します。 |
11gリリース1(11.1.1)では使用されません。すべての属性が表示されます。 |
|
orclDASUIType |
singletext、multitext、LOV、DATE、Number、passwordなどのUIフィールドのタイプです。 |
Oracle Internet Directoryセルフ・サービス・コンソールでのみ使用されます。 |
|
orclDASAdminModifiable |
管理者がこのフィールドを変更できるかどうかを示します。 |
11gリリース1(11.1.1)では使用されません。管理者はすべての属性を変更できます。 |
|
orclDASViewAble |
この属性がOracle Internet Directoryセルフ・サービス・コンソールで読取り専用属性かどうかを示します。 |
11gリリース1(11.1.1)では使用されません |
|
displayName |
Oracle Internet Directoryセルフ・サービス・コンソールに表示されるローカライズされた属性名です。 |
|
|
orclDASIsMandatory |
この属性が必須であるかどうかを示します。 |
必須属性が移入されない場合、Oracle Internet Directoryセルフ・サービス・コンソールから警告を受けます。 |
|
orclDASAttrIsFieldForCreate |
ユーザー作成時にかぎりこの属性が公開されるかどうかを示します。 |
11gリリース1(11.1.1)では使用されません |
|
orclDASAttrIsFieldForEdit |
ユーザー編集時にかぎりこの属性が公開されるかどうかを示します。 |
11gリリース1(11.1.1)では使用されません |
|
orclDASAttrToDisplayByDefault |
閉じられたセクションにおいて属性がデフォルトで非表示となるかどうかを示します。 |
11gリリース1(11.1.1)では使用されません |
|
orclDASSelfModifiable |
ユーザーがこの属性を変更できるかどうかを示します。 |
Oracle Internet Directoryセルフ・サービス・コンソールはアプリケーション固有の属性専用のため、11gリリース1(11.1.1)では使用されません。ユーザーは、Oracle Internet Directoryセルフ・サービス・コンソールからユーザー・プリファレンスを変更できません。 |
|
OrclDASAttrDisplayOrder |
アプリケーション固有のセクションに属性が表示される順序です。 |
11gリリース1(11.1.1)では使用されません |
|
OrclDASAttrDefaultValue |
プロビジョニング・コンポーネント(Oracle Internet Directoryセルフ・サービス・コンソール、Oracle Directory Integration and Provisioningおよびバルク・プロビジョニング・ツール)で使用される属性の初期デフォルト値です。 |
Oracle Internet Directoryセルフ・サービス・コンソールのアプリケーション管理ページを使用して変更できます。プラグインまたは管理者により、初期デフォルト値を上書きできます。 |
|
OrclDASAttrObjectClass |
属性が属するLDAPオブジェクト・クラスです。 |
プロビジョニング・システムにより管理されるアプリケーション固有のユーザー・エントリを作成するために使用されます。 |
アプリケーションにアプリケーション固有の属性がある場合、プロビジョニング・システムでその属性のデフォルト値を管理するよう指定できます。これを行うには、$ORACLE_HOME/bin/oidprovtoolにmanage_application_defaults引数を使用します。この引数は、デフォルトでTRUEです。
アプリケーション・プロビジョニング・プラグインの詳細は、次を参照してください。
イベント伝播の構成パラメータは、プロファイルのバージョンによって異なります。表12-5「イベント伝播のパラメータ」に、イベント伝播の構成パラメータをリストし、説明します。
表12-5 イベント伝播のパラメータ
| パラメータ | サポートされるプロビジョニング・プロファイルのバージョン | 説明 |
|---|---|---|
|
profile_mode |
2.0,.3.0 |
アプリケーションでOracle Internet Directoryからの発信プロビジョニング・イベントの受信、着信イベントの送信、またはその両方を実行するかどうかを示します。値は、OUTBOUND(デフォルト)、INBOUND、BOTHです。 |
|
Schedule |
1.1、2.0、3.0 |
保留イベントが伝播されるまでのスケジューリング間隔です。 |
|
enable_bootstrap |
3.0 |
アプリケーション・ブートストラップ用のイベントを有効にします。これにより、アプリケーションでのプロビジョニング・プロファイルの作成前に、Oracle Internet Directoryに存在するユーザーについてアプリケーションに通知するよう指定します。 |
|
enable_upgrade |
3.0 |
アプリケーション・ユーザーのアップグレード用のイベントを有効にします。これにより、アップグレードの前に、Oracle Internet Directoryに存在するユーザーについてアプリケーションに通知するよう指定します。アップグレードの前から存在するアプリケーションの場合、そのアプリケーションにユーザーがすでに存在している可能性があります。このようなユーザーについては、通常の新規ユーザーとは異なる処理するよう、Oracle Directory Integration and Provisioningでアプリケーションにアップグレード・イベントを送信します。 |
|
lastchangenumber |
3.0 |
アプリケーションへのイベントの送信元にする必要があるOracle Internet Directoryの変更番号です。 |
|
max_prov_failure_limit |
3.0 |
アプリケーションにユーザーをプロビジョニングする際に、Oracle Directory Integration and Provisioningサーバーで試行する最大回数です。 |
|
max_events_per_invocation |
2.0、3.0 |
バルク・イベント伝播の場合、このパラメータにより、1回のイベント・インタフェースの起動中にパッケージ化して送信できるイベントの最大数を指定します。 |
|
max_events_per_schedule |
2.0 |
プロファイルの1回の実行でOracle Directory Integration and Provisioningがアプリケーションに送信するイベントの最大数です。デフォルトは25です。多くのプロファイルおよびアプリケーションが存在するデプロイメントの場合、これにより、マルチスレッド化されたOracle Directory Integration and Provisioningを使用して複数のプロファイルのスレッドを実行できます。 |
|
event_subscription |
1.1、2.0、3.0 |
アプリケーションがイベント伝播サービスから受信するOUTBOUNDイベントのタイプを定義します。書式は次のとおりです。 Object_Type:Domain:Operation(Attributes,…) 次に例を示します。 USER:cn=users,dc=example,dc=com:ADD(*) この例では、作成されたユーザーが指定ドメインに存在する場合、USER_ADDイベントを送信し、すべての属性も送信するよう指定しています。 USER:cn=users,dc=example,dc=com:MODIFY(cn,sn.mail,telephonenumber) この例では、変更されたユーザーが指定ドメインに存在し、リストされた属性のいずれかが変更された場合、USER_MODIFYイベントを送信するよう指定しています。 USER:cn=users,dc=example,dc=com:DELETE この例では、指定ドメインのユーザーが削除された場合、USER_DELETEイベントを送信するよう指定しています。 |
|
event_permitted_operations |
2.0 |
アプリケーションがOracle Directory Integration and Provisioningサーバーへの送信権限を持つINBOUNDイベントのタイプを定義します。書式は次のとおりです。 Object_Type:Domain:Operation(Attributes,…) 次に例を示します。 IDENTITY:cn=users,dc=example,dc=com:ADD(*) この例では、指定ドメインに対してIDENTITY_ADDイベントを許可すると同時に、すべての属性も許可するよう指定しています。つまり、アプリケーションでOracle Internet Directoryにユーザーを作成できます。 IDENTITY:cn=users,dc=example,dc=com:MODIFY(cn,sn.mail,telephonenumber) この例では、リストされている属性に対してのみIDENTITY_MODIFYを許可するよう指定しています。他の属性は、暗黙的に無視されます。つまり、アプリケーションで、リストされているOracle Internet Directoryのユーザー属性を変更できます。 IDENTITY:cn=users,dc=example,dc=com:DELETE アプリケーションによるOracle Internet Directoryのユーザーの削除を許可するよう指定しています。 |
|
event_mapping_rules |
2.0 |
INBOUNDプロファイルの場合、このパラメータにより、アプリケーションおよび修飾フィルタ条件から取得するオブジェクトの型を指定して、このイベントの対象ドメインを決定します。複数の値を指定できます。書式は次のとおりです。 Object_Type: Filter_condition: Domain_Of_Interest 次に例を示します。 EMP::cn=users,dc=example,dc=com 受け取ったオブジェクト型が EMP:l=AMERICA:l=AMER,cn=users,dc=example,dc=com 受け取ったオブジェクト型が |
Oracleプロビジョニング・サービスでは、プロビジョニング統合アプリケーションごとに、ユーザーのプロビジョニング・ステータスがOracle Internet Directoryに記録されます。この詳細は、『Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド』の「プロビジョニングのデプロイおよび構成」の章を参照してください。
oracle.idm.user.provisioning.configuration.Configurationクラスを使用すると、プロビジョニング・スキーマの情報を取得できます。oracle.idm.user.provisioning.configuration.Applicationクラスを使用すると、登録アプリケーションのメタデータを取得できます。これらのクラスは、oracle.idm.provisioning.configurationパッケージに記述されています。
Configurationクラスでは、アプリケーション構成にアクセスできます。Configurationオブジェクトを構成するには、レルムを指定する必要があります。次に例を示します。
Configuration cfg = new Configuration ("us");
これで、Configurationクラスのメソッドを使用して、レルム内の一部またはすべてのアプリケーション構成を取得できます。レルムのLDAPコンテキストを指定する必要があります。
Configurationオブジェクトは、作成時にOracle Internet Directoryメタデータへのアクセスを必要とするため、パフォーマンスにかなりの影響を与えます。ベスト・プラクティスは、アプリケーションの初期化中にConfigurationオブジェクトを一度作成し、後は必要とされるすべての操作でこのオブジェクトを再利用することです。
Applicationオブジェクトは、アプリケーション・インスタンスを示します。このオブジェクトのメソッドにより、インフラストラクチャの登録アプリケーションに関するメタデータを取得できます。
Oracle Directory Integration and ProvisioningまたはOracle Delegated Administration Servicesでは、プロビジョニング・プラグインを起動する際、プロビジョニング対象のユーザーに関する情報を渡します。デプロイされたアプリケーションでは、ユーザー・オブジェクトを使用してユーザーを変更できます。
ユーザー管理用のプロビジョニング・クラスにより、次の操作を実行できます。
ベース・ユーザーの作成、変更および削除
アプリケーション固有のユーザー情報の作成、変更および削除
ベース・ユーザーの検索
アプリケーションのユーザー・プロビジョニング・ステータスの取得
この項の項目は次のとおりです。
Oracle Identity Managementリポジトリでのユーザーの作成は、2つのステップで構成されます。
指定したレルムに基本ユーザー情報を作成します。この情報は、ベース・ユーザーと呼ばれます。
アプリケーション固有のユーザー属性(フットプリント)を作成します。この情報は、アプリケーション・ユーザーと呼ばれます。
リポジトリ内のベース・ユーザーとアプリケーション・ユーザーの組合せは、Oracle Identity Managementユーザーと呼ばれます。メソッドには、ベース・ユーザーのみを作成するものと、Oracle Identity Managementユーザーの両構成要素を作成するものがあります。
ユーザーの作成に必要な最低限の情報は、ベース・ユーザーを示す属性のセットです。属性は、名前/値ペアの形式を取ります。これらのユーザー属性は、oracle.ldap.util.ModPropertySetクラスを使用するJavaオブジェクトとして示されます。
一部のユーザー作成メソッドでは、Oracle Identity Managementのユーザー・リポジトリに作成するエントリの識別名を指定する必要があります。それ以外のメソッドでは、識別名は必要ありません。かわりに、ユーザー作成先のレルムから取得されたメタデータ構成情報を使用して、Oracle Identity Managementユーザーが構成されます。
ベース・ユーザーとアプリケーション・ユーザーの作成に成功すると、作成メソッドによってIdmUserオブジェクトが戻されます。このオブジェクトを使用して、ベース・ユーザーとアプリケーション・ユーザーの属性を管理します。
Oracle Identity Managementリポジトリでベース・ユーザーを変更すると、次の処理が行われます。
ベース・ユーザー情報の変更
アプリケーション・ユーザー情報の作成または変更
Oracle Identity Managementユーザーを変更するには、次の情報を指定する必要があります。
ユーザーの識別名、GUIDまたはIdmUserオブジェクト参照
ベース・ユーザー属性に対する変更操作(oracle.ldap.util.ModPropertySetで指定)
一部のユーザー変更メソッドは、ベース・ユーザー属性のみを変更します。それ以外のメソッドは、アプリケーション・ユーザー属性も変更します。
Oracle Identity Managementリポジトリでベース・ユーザーを削除すると、次の処理が行われます。
ベース・ユーザー情報の削除
アプリケーション・ユーザー情報の削除
Oracle Identity Managementユーザーを変更するには、識別名、GUIDまたはIdmUserオブジェクト参照を指定する必要があります。
この操作の結果、ベース・ユーザーとアプリケーション・ユーザーの属性が削除されます。
検索メソッドには、次の2つの検索オプションがあります。
GUIDまたは識別名を使用した特定のOracle Identity Managementユーザーの検索
検索フィルタを使用したOracle Identity Managementユーザーのセットの検索
Oracle Identity Managementユーザーを検索するには、識別名またはGUIDを指定する必要があります。
検索メソッドの出力は、次のいずれかになります。
単一のIdmUserオブジェクト
IdmUserオブジェクトのリスト
デバッグとトレース情報を有効にするには、UtilDebug.MODE_PROVISIONING_APIモードを設定します。ログ・メッセージの出力ストリームを指定しない場合、メッセージは標準出力に書き込まれます。
次のスニペットは、UtilDebug.MODE_PROVISIONING_APIモードを設定して出力ストリームを指定する方法を示しています。
Import oracle.ldap.util.UtilDebug;
FileOutputStream logStream = new FileOutputStream("ProvAPI.log")
…
UtilDebug.setDebugMode(UtilDebug.MODE_PROVISIONING_API);
UtilDebug.setPrintStream(logStream);
次のコード例は、ユーザーの作成、変更および検索方法と、アプリケーションのユーザー・プロビジョニング・ステータスの取得方法を示しています。
UtilDebug.setDebugMode(UtilDebug.MODE_PROVISIONING_API);
…
Configuration cfg = new Configuration(realm);
try {
debug("Connecting...");
InitialLdapContext ctx =
ConnectionUtil.getDefaultDirCtx(hostName, port, bindDn, passwd);
debug("Connected...");
UserFactory factory = UserFactoryBuilder.createUserFactory(ctx, cfg);
// Create
ModPropertySet mpSet = new ModPropertySet();
mpSet.addProperty("cn","Heman");
mpSet.addProperty("sn","The Master");
mpSet.addProperty("uid","Heman");
IdmUser idmUser = factory.createUser(mpSet);
// Modify
mpSet = new ModPropertySet();
mpSet.addProperty(LDIF.ATTRIBUTE_CHANGE_TYPE_REPLACE,"sn",
"Heman The Master");
mpSet.addProperty("givenName","Master of the Universe");
factory.modifyUser(idmUser, mpSet);
// Lookup List users = factory.searchUsers(Util.IDTYPE_SIMPLE, "Hema*", null);
….
// Get user provisioning status for an application.
Application app = cfg.getApplication(lCtx, "Files", "FilesInstace");
String status = idmUser.getProvisioningStatus(app);
// Another way to get user provisioning status
String userDn = idmUser.getDNn();
String status = ProvUtil.getUserProvisioningStatus(dirctx,
Util.IDTYPE_DN, userDn, app.getType(), app.getName());
} catch (Exception ex) {
ex.printStackTrace();
//
}
