Oracle Applicationsシステム管理者ガイド - セキュリティ リリース12 E05069-01

目次

前へ

次へ

Oracle User Managementによるアクセス制御

概要

この章では、Oracle User Managementのコア・セキュリティおよび管理機能について説明します。コア・セキュリティには、Oracleの機能およびデータ・セキュリティ・モデルおよびロール・ベースのアクセス制御が含まれます。管理機能は、コア・セキュリティに依存し、委任管理、登録プロセス、およびセルフ・サービスと承認を含みます。

コア・セキュリティおよび管理機能は、後続のレイヤーに実装され、それぞれが先行するレイヤーに依存します。既存の機能およびデータ・セキュリティ・モデルに依存する自動化とスケーラビリティの程度にあわせて、組織はオプションで様々なレイヤーを取り込むことができます。

通常、Oracle User Managementによるアクセス制御は、基本的なシステム管理タスクから開始し、より分散したローカル・モードの管理に移行して、最終的にユーザーが基本的な事前定義済の登録タスクを独自に実行できるようにします。次の図に、レイヤーがどのように相互に依存しているかを示します。

図2-1 Oracle User Managementのレイヤー

Oracle User Managementは、ワークフロー・ビジネス・イベントを介して従来のアプリケーション固有のセキュリティ・メカニズムをサポートします。ユーザーの要求が承認されると、Oracle User Managementはこれらのイベントを呼び出します。組織はこれらのイベントに割り込んで、適切な処理を決定し、必要な追加の権限を割り当てることができます。

機能セキュリティ

図2-2 機能セキュリティ・レイヤー

機能セキュリティは、Oracle Applicationsにおけるアクセス制御の基準レイヤーです。機能セキュリティは、システム内の個別のメニューおよびメニュー・オプションへのユーザーのアクセスを制限しますが、メニュー内に含まれるデータへのアクセスは制限しません。たとえば、組織は機能セキュリティを使用して、顧客に問い合せるために必要なメニューおよびメニュー・オプションを営業担当に提供できます。販売予測ページのボタンなど、ページの特定のコンポーネントへのアクセスを制御することもできます。機能セキュリティの詳細は、「Oracle Application Object Libraryセキュリティ」を参照してください。

データ・セキュリティ

図2-3 データ・セキュリティ・レイヤー

データ・セキュリティは、アクセス制御の次のレイヤーです。データ・セキュリティは機能セキュリティに依存し、ユーザーがアクセス可能なデータ、およびそのデータで実行できる処理について、Oracle Applications内のアクセス制御を提供します。ユーザーがメニューまたはメニュー・オプションを選択すると、Oracle Applicationsは、画面に表示される個別のデータへのアクセスを制限します。たとえば、データ・セキュリティは、Oracle User Management内でローカル管理者がアクセスできるユーザーのセットを制限します。データ・セキュリティ・ポリシーは、データ・セキュリティ・フレームワークを利用するために作成されたアプリケーションに対してのみ定義できます。データ・セキュリティの詳細は、「Oracle Application Object Libraryセキュリティ」を参照してください。

ロール・ベースのアクセス制御（RBAC）

図2-4 ロール・ベースのアクセス制御レイヤー

RBACは次のレイヤーであり、データ・セキュリティおよび機能セキュリティに依存します。RBACを使用すると、アクセス制御はロールを介して定義され、アプリケーションへのユーザー・アクセスが、ユーザーに付与されたロールによって決定されます。Oracle Applicationsにおけるアクセス制御は、National Institute of Standards & Technology（NIST）が最初に提唱したRBAC ANSI規格（ANSI INCITS 359-2004）に厳密に従っています。この規格では、ロールを「組織のコンテキスト内の役職機能で、ロールに割り当てられたユーザーに付与される権限および職責に関してなんらかの意味を持つもの」として定義しています。

ロールは、ユーザーが特定の機能を実行するために必要な職責、権限、機能セキュリティおよびデータ・セキュリティ・ポリシーを統合するように構成できます。これは、1回の設定で実行され、権限、職責およびその他のロールがロールに割り当てられます。権限は、ユーザーに割り当てられたロールに基づいて暗黙的に継承されるため、ユーザーを下位レベルの権限に直接割り当てる必要はありません。組織がロールに対して定義された権限またはロールの継承階層を変更するだけで、そのロールを割り当てられたユーザーは新しい権限のセットを自動的に継承するため、ユーザー権限の一括更新が簡素化されます。

組織は、ビジネスの状況を詳細に反映するロールを定義できます。たとえば、ある組織は「従業員」ロールを作成して、そのロールをすべての従業員に割り当てることができます。また、「外部」ロールを作成して、そのロールを顧客および仕入先に割り当てることもできます。その他の例としては、「サポート・エージェント」、「営業担当」、「営業マネージャ」などの特定のロールがあります。これらの例では、各ロールには、担当者を役職機能の範囲に制限する特定のレベルのアクセス権限が含まれます。組織の一部のメンバーには、1つ以上のロールが割り当てられることもあります。たとえば、営業担当には、従業員および営業担当ロールが割り当てられ、営業マネージャには、従業員、営業担当および営業マネージャ・ロールが割り当てられます。ロールおよびロール割当は、ワークフロー・ディレクトリに格納されます。このディレクトリは、実行時にセキュリティ・システムによって解釈されます。

ロール・カテゴリ

Oracle Applications RBACモデルの一部として、Oracle User Managementはロール・カテゴリを導入します。管理者はロール・カテゴリを作成して、ロールと職責をまとめることで、ロールおよび職責の検索プロセスを簡単に実行できるようになります。たとえば、ロールに関連する営業とマーケティングはすべて、「営業およびマーケティング」カテゴリに含めることができます。

ロール継承階層

ロールは、複数の下位ロールおよび上位ロールを含むロール継承階層に含めることができます。ロール継承階層では、上位ロールは下位ロールのすべてのプロパティと、そのロール自体のいずれかの下位ロールを継承します。次の例は、ロール継承階層により、ユーザー・アクセスの制御および管理がどのように大幅に簡略化されるかを示します。

図2-5 ロール継承階層

前述の図では、図の両側の矢印は、メンバーシップ継承と権限継承を示します。丸いボックス内のテキストは、ロールを示します。個人からロールを指す矢印は、この個人がそのロールに割り当てられていることを示します。ロールからロールを指す矢印は、矢印の元のロールが上位ロールで、矢印の先のロールが下位ロールであることを示します。ロールに関連付けられた権限は、すべての上位ロールおよびこれらのロールが割り当てられた個人によって継承されます。

この例では、「従業員」、「マネージャ」などのロールに、特定の機能を備えた一般的な権限が割り当てられています。たとえば、従業員ロールは、すべての従業員が一般的に使用できるメニューへのアクセスを提供し、マネージャ・ロールは、マネージャのみが表示できるメニューへのアクセスを提供します。従業員ロールはマネージャ・ロールの下位ロールであるため、マネージャ・ロールを割り当てられたユーザーは、従業員ロールに関連付けられた権限を自動的に取得します。この例のその他のロールは、営業マネージャと営業担当、またはサポート・マネージャとサポート・エージェントなど、特定の役職機能に関連付けられます。これらのロールは、「販売予測」メニューやサポート・アプリケーションなど、役職固有のメニューおよびデータへのアクセスを提供します。

委任管理

図2-6 委任管理レイヤー

委任管理は、RBACシステムに依存し、ロールおよびユーザー・アカウントの管理に必要なアクセス権を割り当てる機能を組織に提供する権限モデルです。すべてのユーザーを管理する中央の管理者に依存するのではなく、委任管理を使用することで、組織はローカル管理者を作成して、組織のユーザーおよびロールの特定のサブセットを管理するのに十分な権限を付与できます。これにより、より緊密かつ詳細なレベルのセキュリティと、管理機能を簡単に拡大できる機能が組織に提供されます。たとえば、組織は部署または部門レベルで社内の管理者を指定して、（外部の）組織内の人に外部ユーザーの管理を委任できます。委任ポリシーがセキュリティ・ポリシーとして定義されます。委任管理の一部として定義されるデータ・ポリシーのセットは、管理権限と呼ばれます。

管理権限

管理権限は、委任管理者（ローカル管理者）が管理できるユーザー、ロールおよび組織情報を決定します。各権限は個別に付与されますが、この3つは連携して、委任管理者に完全な機能のセットを提供します。

• ユーザー管理権限: ローカル管理者には、ローカル管理者が管理できるユーザーを決定するユーザー管理権限を付与する必要があります。ローカル管理者には、ユーザーのサブセットごとに異なる権限を付与できます。たとえば、ローカル管理者には、あるユーザーのセットについては問合せの権限のみ付与し、別のユーザーのセットについてはフル権限（更新およびパスワードのリセットを含む）を付与できます。ローカル管理者は、管理権限を持っていないユーザーを問い合せることはできません。

• ロール管理権限: ロール管理権限は、ローカル管理者が自分で管理するユーザーのセットに対して直接割当ておよび取消し可能なロールを定義します。

• 組織管理権限: 組織管理権限は、ローカル管理者がOracle User Managementで表示できる外部組織を定義します。この権限により、ローカル管理者に組織内のユーザーを表示する権限（ユーザー管理権限）が追加で付与されている場合、管理者は組織に基づいてユーザーを検索できます。ユーザー管理権限によって、管理者はその組織に新しいユーザーを登録できます。

Oracle Applicationsは、従来のシステム管理者レベルの管理権限も引き続きサポートします。この管理権限は、指定されたユーザーのグループがすべてのユーザーおよびアクセス権限を管理します。Oracle User Managementには、事前に定義されたセキュリティ管理者ロールが付属しています。このロールは、システム・アカウントおよびシステム内のすべてのロールを含むすべてのユーザーを管理する権限を管理者に付与します。

プロキシ・ユーザーへの委任

多数のビジネス・シナリオで、Oracle E-Business Suiteのユーザーが、特定のE-Business Suite機能の実行時に自分のかわりに処理を行う（自分のプロキシ・ユーザーとして代行する）権限を付与することが必要になります。従来、委任者はこの権限付与を行うために、特定のアプリケーションのパスワードを他のユーザーに与えていました。特定のアプリケーションについて他のユーザーのパスワードを与えられた委任ユーザーは、そのアプリケーション内でのみ委任者のIDと権限を引き受けることができます。

E-Business SuiteとOracle Application Server 10g Single Sign-On（SSO）の統合により、この従来の方法は安全でなくなりました。委任者がSSOパスワードへの委任アクセス権限を付与すると、委任ユーザーは特定のアプリケーションのみでなく、委任者がアクセス権限を持つ各SSO対応アプリケーションにアクセス可能になります。委任者から委任ユーザーに対して、制限付きで監査可能な方法で権限を委任できるように、新しいメカニズムが設計されました。

重要: プロキシ・ユーザー・メカニズムを使用すると、すべてを委任するか何も委任しないかを選択できます。ただし、開始日と終了日を定義して、プロキシ・アクセスの期間を制限できます。

委任の例

多数の一般的な使用例で、ユーザーが自分の代理として別のユーザーにE-Business Suiteとの対話を許可することが必要になる可能性があります。

• 役員がアシスタントに、自分の代理として、選択したビジネス・アプリケーションにアクセスすることを許可する場合。

• 役員とアシスタントの例に似ていますが、より限定された期間を対象として、たとえば、マネージャの外出中に同僚や部下に制限付きの代理権限を付与するなどの場合。

• ユーザーが、ヘルプ・デスクのスタッフに問題を調査し支援してもらうために、ヘルプ・デスクのスタッフに自分のE-Business Suiteアカウントへの期間制限付きアクセス権限を付与する場合。

• プロキシ・ユーザー・メカニズムを使用すると、このようなユーザーは、SYSADMINなどのアカウントへの制限付きで監査可能なアクセス権限を取得できます。他の方法では、SYSADMINを共有にする必要があるため、監査が難しくなります。

• 会社は、監査を行うために、特定のユーザー（監査人）に従業員のE-Business Suiteアカウントへのアクセス権限（通常は読取り専用）を付与することが必要になる場合があります。

ユーザーによるプロキシ機能へのアクセス権限は、セキュリティ管理者ロールにより制御されます。このロールを持つユーザーが、代行の委任ユーザーを作成できるユーザー・セットを決定します。

プロビジョニング・サービス

図2-7 プロビジョニング・サービス・レイヤー

プロビジョニング・サービスは登録プロセスとしてモデル化されており、エンド・ユーザーが、新しいアカウントを要求したりシステムへの追加のアクセス権を要求するなど、自己の登録タスクを実行できるようにします。また、登録プロセスでは、管理者はより迅速かつ効率的な方法で新しいユーザー・アカウントの作成やロールの割当てを行えます。登録プロセスでは、これを実行するために、次に示す登録の主要なコンポーネントをカプセル化しています。

• ユーザーが処理を正常に完了した後に割り当てられる、ロール。

• アカウントやその他の情報を収集するための、オプションの登録ユーザー・インタフェース。

• 承認、確認、拒否およびID検証通知のワークフロー。

• 承認管理取引タイプ。取引タイプは、実行時に解釈される承認ルーティング・ルールのセットを表します。

• 追加アクセスの登録に適格なユーザーのセット（追加アクセス要求登録プロセスに対してのみ適用可能）。

• ID検証の要否。ID検証は、登録要求が処理される前に要求者のEメール・アドレスにEメール通知を送信することで、要求者のIDを確認します。受信者が所定の時間内に応答しない場合、要求は自動的に拒否されます。

• 「管理者によるアカウントの作成」登録プロセスによってユーザーを登録または作成できるローカル管理者のセット

ユーザーが登録プロセスを使用して登録を完了すると、システムはユーザーから必要な情報を取得して、そのユーザーに新しいユーザー・アカウントまたはロール（あるいはその両方）を割り当てます。Oracle User Managementは、セルフ・サービス・アカウント要求、追加アクセス要求および管理者によるアカウントの作成の3種類の登録プロセスをサポートしています。

セルフ・サービス・アカウント要求

セルフ・サービス・アカウント要求は、一般にセルフ・サービス登録と呼ばれ、新しいユーザー・アカウントを要求する方法を提供します。顧客がオンライン・ショップから商品を購入する前に登録する必要がある場合を考えてみます。登録プロセスが完了すると、顧客は登録したWebサイトの一部にアクセスするためのユーザー・アカウントと必要なロールの両方を取得します。

このリリースのOracle User Managementでは、内部の従業員および新しい外部のユーザー向けに、サンプルのセルフ・サービス登録UIを提供しています。組織はこのサンプルのセルフ・サービス登録をコピーし、独自の要件に基づいて拡張できます。また、その他のタイプのユーザーをサポートしたり、アプリケーションに固有の追加情報を取得する場合は、独自の登録UIおよびビジネス・ロジックを拡張または作成できます。

Oracle User Managementは、アプリケーション層に基づいてログイン・ページに様々な登録リンクを表示するためのサポートを、アクセスを提供するログイン・ページに提供しています。登録リンクには、国コードなど、設計時には不明な追加パラメータを含めることができます。この追加パラメータは、後で登録プロセスに使用できます。国コードの例を使用すると、登録プロセスは承認要求を最も適切な承認者に経路指定できます。したがって、ノルウェーからアカウントを要求したすべてのユーザーは、ノルウェーのアカウント承認者に経路指定されます。

注意: アカウントおよびユーザー・アカウントは、FND_USER表に格納されているログイン・アカウントを指します。

追加アクセス要求

ユーザーは、「グローバル作業環境」メニューから使用できるOracle User Managementアクセス要求ツール（ART）を使用して、追加アクセスを要求できます。追加アクセス要求では、セルフ・サービス・アカウント要求と同じOracle User Managementインフラストラクチャおよびプロセス・ロジックを使用します。

追加アクセスとセルフ・サービスの適格性

適格性は、ユーザーがアクセス要求ツールを使用して登録できるロールを定義します。適格性は、特定のロールに登録する資格がある、ワークフロー・ディレクトリに定義されたユーザーのグループを決定します。「追加アクセス」タイプの登録プロセスは、すべてのロールまたはグループで事前に定義されたユーザーのセットに対して使用可能にできます。適格性はデータ・セキュリティ・ポリシーとして定義され、アクセス要求ツールによって実行時に問合せされます。

ロールはワークフロー・ディレクトリに格納されるため、アプリケーションへのアクセス権の付与と適格性の定義の両方に使用できます。これにより、組織は、新しいユーザーが先行するユーザーに初めて承認される場合、新しいユーザーがロールに登録できる差分登録プロセスを定義できます。たとえば、新しいユーザーがAロールに承認されると、ユーザーはBロールに登録できます。ただし、ユーザーがAロールに初めて承認されるのではない場合、ユーザーはBロールには登録できません。

Oracle User Managementは、ワークフロー・ディレクトリに格納されるすべてのグループおよびロールに適格性ポリシーを定義できます。

委任管理と登録プロセス

管理者がユーザーにロールを割り当てる場合、管理者は基本的にユーザーの代表として登録要求を実行します。管理者がユーザーにロールを割り当てる場合、Oracle User Managementは、登録プロセス・メタデータを定義および解釈するために、対応する「追加アクセス (管理者)」登録プロセス（定義されている場合）を呼び出します。登録UIが定義されている場合、Oracle User ManagementはそのUIを呼び出して、管理者は登録プロセスを実行します。通知ワークフローは、登録プロセスがユーザーに割り当てられるロールに対して定義されている場合にのみ呼び出されます。

Oracle Approval Managementに定義されているように、ユーザーへのロールの直接割当は、事前に定義された承認ルーティング・ルールをバイパスします。管理者は、ユーザーに割り当てられているすべてのロールを表示できますが、管理権限を持っていないロールの割当てまたは取消しはできません。ユーザーにロールを割り当てる管理者は、基本的にユーザーを代表して登録要求を実行します。

管理者によるアカウントの作成

管理者は、ユーザー・アクセスを作成および保持するプロセスを合理化するように設計された登録プロセスを利用できます。このタイプの登録プロセスは、管理者、特に委任管理者を対象として、組織のユーザー・セキュリティ・ポリシーを一貫して適用できるようにします。各アカウント作成登録プロセスは、選択された管理者が利用可能です。

登録プロセスのインフラストラクチャ

この項では、Oracle User Managementを介して発行されるすべての登録要求を処理する、一般的なインフラストラクチャのコンポーネントについて説明します。

ユーザー名ポリシー

Oracle User Managementを使用すると、組織は新規ユーザーについて独自のユーザー名ポリシーを定義できます。これには、Eメール・アドレス、氏名「firstname.lastname」（または省略バージョン）、従業員番号、社会保障番号などの書式または他の意味を持つ情報を使用できます。アカウント要求が発行されると、Oracle User Managementは承認プロセスの期間中は指定のユーザー名を予約します。

Oracle User Managementには、Eメール・アドレスでユーザーを識別するデフォルトのユーザー名ポリシーが付属しています。これは、組織が特定のニーズにあわせて簡単にカスタマイズできる、構成可能なインフラストラクチャとして実装されます。

Eメール検証

Oracle User Managementは、登録要求が処理される前に要求者のIDを確認するメカニズムを提供しています。ID検証は、要求者が指定したEメール・アドレスに基づいて行われます。要求者が登録フローを完了すると、Oracle User Managementは要求者にEメール通知を送信します。ユーザーが指定された期間内にEメール通知に応答しなかった場合、要求は自動的に拒否されます。Eメール検証は、セルフ・サービス・アカウント要求に対してのみ適用され、登録プロセスごとに有効または無効にできます。

注意: ID検証を有効にしてセルフ・サービス登録UIを作成する場合、組織でユーザーの要求を処理するために応答が必要であることをUIおよび確認メッセージに示すことをお薦めします。

登録データの一時保存

Oracle User Managementは、要求が承認されるまで登録データを保留状態で保存するメカニズムを提供しています。このデータは、承認の送信に使用されるワークフロー通知、承認管理ルーティング・ルール、および最終宛先表に情報を書き込むビジネス・ロジックに使用できます。Oracle User Managementはこれを実行するために、ワークフロー・ビジネス・イベント・インフラストラクチャの一部であるイベント・オブジェクトを使用します。

登録エンジン

Oracle User Management登録エンジンは、ワークフローを使用して、要求が発行された後に登録プロセスを開始するビジネス・ロジックを定義します。ワークフローの名前は、「UMX登録ワークフロー」（UMXREGWF）です。

このプロセスは、次のとおりです。

• ビジネス・イベントの呼出し

• 登録データの一時保存

• ID検証

• Oracle Approval Managementとの統合ポイント

• ユーザー・アカウントの有効化

• ユーザー名の予約およびリリース

• ロールの割当

• Oracle User Managementスキーマでの登録ステータスの保持

• 通知ワークフローの開始

組織は、すべてのOracle User Managementコードを確認および理解しなくても、登録プロセスのコンポーネント（通知、承認ルーティング・ルール、ユーザー名ポリシーなど）をカスタマイズできます。

ルーティング承認要求

承認者は、各要求タイプ固有のルールに基づいて構成できます。組織は要件に従ってこれらのルールを定義し、承認を必要としない要求のタイプを指定できます。Oracle User Managementは、Oracle Approval Managementとの統合により、承認要求の経路指定を宣言によって構成できる柔軟かつ強力なルール・エンジンを提供します。Oracle User Managementは、登録プロセス中に取得した情報に基づいて承認ルールを設定できるAPIも提供します。このような情報には、「ログイン」ページの「ここで登録」リンクから渡される、設計時点では不明なパラメータなどがあります。

ワークフロー・ビジネス・イベント

Oracle User Managementは、次のワークフロー・ビジネス・イベントを呼び出します。

注意: 前述のUMXイベントは、監査などの集中化された要件にのみ使用することをお薦めします。登録固有の処理には、登録プロセスに対して定義されたカスタム・イベントを使用してください。

コンテキストによって、ビジネス・イベントが呼び出されたときに、Oracle User Management登録エンジンによって次の表に示すイベント・パラメータが自動的に設定されます。登録UI、承認通知またはビジネス・ロジックによってプログラムで取得された追加情報も、イベント・パラメータとして使用できます。

* WF_ROLE_NAMEは、「セルフ・サービス・アカウント作成」または「管理者用アカウント作成」登録プロセスには不要です。このような場合は、NULL値が渡されます。Oracle User Managementビジネス・イベントが呼び出されると、登録UI、承認者または承認通知で取得された追加情報、あるいはビジネス・ロジックで設定された追加情報もパラメータとして使用できます。

サンプル・プログラム

/**************************************************************
This is a sample subscription to any of the above events.

Function custom_logic (p_subscription_guid in raw,
        p_event in out NOCOPY WF_EVENT_T)
Return varchar2 is
        l_first_name varchar2(30);
Begin
        l_first_name :=  p_event.getvalueforparameter ('FIRST_NAME');
// Manipulate the data
End custom_logic;
**************************************************************/

登録ステータス

ユーザーはアクセス要求ツール（ART）を介して要求の登録ステータスを確認し、管理者は「管理」画面を使用して確認できます。保留中の要求については、「情報の表示」アイコンに現在の承認者と確認番号が表示されます。確認番号は、要求を処理するOracle User Management登録ワークフロー（UMXREGWF）ワークフロー・プロセスの番号（ITEM_KEY）を表します。

通知ワークフロー

通知ワークフローを使用すると、組織は各ロールまたは登録プロセスに固有の独自のEメール通知を定義できます。通知には、次のものが含まれます。

Oracle Approval Management Engineによって決定された承認を必要とする要求ごとに、Oracle User Managementは、承認を要求するための通知ワークフローを呼び出します。通知ワークフローを作成すると、承認者は登録プロセスで発行された情報を確認して、変更を加え、必要に応じて追加情報を提供できます。

変更または追加情報をOracle User Management登録エンジンに渡して、さらに処理することもできます。たとえば、Oracle User Managementを使用してiSP（Internet Supplier Portal）にセルフ・サービス登録機能を提供する場合、承認者は、サイトおよび担当制限に関する情報を要求者に提供できます。注釈など、前の承認者が入力した情報は、後任の承認者も使用できます。

Oracle User Managementは、次のサンプル通知ワークフローを提供しています。組織はこのワークフローを直接使用したり、要件に基づいてコピーまたは変更できます。

セルフ・サービスおよび承認

図2-8 セルフ・サービスおよび承認レイヤー

必要に応じて登録プロセスが構成されると、ユーザーは、新しいユーザー・アカウントの取得、システムへの追加アクセスの要求など、セルフ・サービス登録タスクを実行できます。組織はOracle Approvals Managementエンジンを使用し、この要求にあわせてカスタマイズされた承認ルーティングを作成できます。たとえば、ユーザーが特に重要なロールを要求できるように設定できます。ただし、ユーザーにロールを付与する前に、組織は2人の上席スタッフ・メンバー（マネージャおよび副社長など）が要求を承認する必要があることを指定できます。

Oracle User Managementは、紛失パスワードをリセットするセルフ・サービス機能も提供しています。また、次のセルフ・サービス登録プロセスが用意されています。

• 従業員セルフ・サービス登録

• 顧客セルフ・サービス登録（外部の個人）

組織は既存のフォームでこれらの登録プロセスを使用したり、独自の登録プロセスを作成するための参照用として使用できます。

Copyright © 1994, 2006, Oracle. All rights reserved.