ヘッダーをスキップ
Oracle® Fusion Middleware Forms Servicesデプロイメント・ガイド
11g リリース1(11.1.1)
B61388-01
  ドキュメント・ライブラリへ
ライブラリ
製品リストへ
製品
目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

11 Forms Servicesセキュリティの概要

Webコンテンツへのユーザー・アクセスを制御し、システムへの侵入者からサイトを保護する機能は非常に重要です。この章では、Oracle Forms Servicesにおけるセキュリティのアーキテクチャと構成について説明します。


関連項目:

セキュリティの詳細は、次のドキュメントを参照してください。
  • Oracle Fusion Middlewareセキュリティ概要』には、Oracle Fusion Middlewareのセキュリティとそのコア機能の概要が記載されています。

  • Oracle Fusion Middleware Oracle Identity Managementスタート・ガイドには、Oracleセキュリティ・インフラストラクチャの管理者用の手引きが記載されています。


11.1 Forms Servicesのシングル・サインオン

Oracle Forms Servicesのシングル・サインオンは、Oracle HTTP ServerのOracleモジュールmod_ossoを通じて利用できます。mod_ossoは、Oracle Single Sign-On Serverに対してユーザーを認証し、次にOracle Internet Directoryをユーザー・リポジトリとして使用してからFormsアプリケーションのリクエストをFormsサーブレットに転送します。

Formsアプリケーションでは、データベース接続文字列がアプリケーションのリクエストとともに渡されます。渡されない場合は、ログイン・ダイアログが表示されます。Oracle Single Sign-On Server環境でデータベース接続情報を取得するには、ユーザーのOracle Single Sign-On Server名、認証されたユーザー名およびユーザーが起動をリクエストしているアプリケーション名を結合して作成される一意キーの値を、Formsサーブレットを使用してOracle Internet Directoryに問い合せます。

リソース・アクセス記述子(RAD)は、各ユーザーおよびアプリケーションに対して定義される、必要なデータベース接続情報を含むOracle Internet Directoryのエントリです。Forms ServletはRADからデータベース接続情報を読み取って、Forms Webアプリケーションを起動するコマンドラインとともに渡します。Forms認証はまだデータベース中心ですが、mod_ossoおよびFormsサーブレットはWebベースのOracle Single Sign-On Server環境に統合されています。

11.1.1 ユーザーのクラスとその権限

従来、Formsアプリケーションでは、アプリケーション・ユーザーの認証にデータベースが使用されています。Oracle Single Sign-On ServerでOracle Forms Servicesを使用するには、ユーザー・アカウントとその接続情報がOracle Internet Directoryで利用可能である必要があります。Oracle Internet Directoryでは、PL/SQL、JavaまたはOracle Delegated Administration Servicesを使用した複数の方法でユーザー・データがプロビジョニングされます。Oracle Delegated Administration Servicesは、Oracle Single Sign-On Serverユーザーおよび委任管理者用のWebベースのユーザー・インタフェースであり、権限を持つOracle Internet Directoryのセルフサービス・データの管理に使用します。

Oracle Internet Directoryでユーザー・アカウントを作成した後は、ユーザーによるFormsアプリケーションの初回リクエスト時に、(このアプリケーションに必要なデータベース接続情報をユーザーが知っていることを前提として)リソース・アクセス記述子(RAD)のエントリを動的に作成できます。

もうひとつの選択肢は、Oracle Delegated Administration Servicesで作成可能なRADのエントリを使用することです。デフォルトのRADエントリには、Oracle Single Sign-On Serverで認証されるすべてのユーザーがアクセスできます。特定のFormsアプリケーションをWebで実行しているときに、すべてのユーザーが同じデータベース接続情報を共有している場合はデフォルトのRADを使用します。このように、ユーザーはそのOracle Single Sign-On Server接続情報によって個別に認証されますが、デフォルトのRADエントリで定義されたアプリケーションでは、すべてのユーザーが共通のデータベース接続(情報)を共有します。

11.1.1.1 ユーザー・アカウントのデフォルトのシングル・サインオン動作

デフォルトでは、OracleAS Single Sign-On Serverが有効となり、プロキシ・ユーザーは使用されません。Oracle Formsユーザーは、OracleAS Single Sign-On Serverで認証を行い、アイデンティティ・ストア(通常はOracle Internet Directory)からリソース・アクセス記述子を取得し、これらの資格証明を使用してデータベースに接続する必要があります。

11.1.1.2 データベース・プロキシ機能を使用するユーザー

Oracle Single Sign-On ServerパラメータssoProxyConnectが新たに追加されました。これをtrueに設定すると、ユーザーはプロキシ・ユーザーとして接続できるようになります。ユーザーはOracle Single Sign-On Serverで認証を行うように求められ、プロキシ・ユーザーのユーザー名とパスワードを保持するリソース・アクセス記述子が構成されます。データベース管理者は、プロキシ接続を許可するために、データベース構成を追加で実装する必要があります。

11.1.2 保護されるリソース

Formsアプリケーションに対してOracle Single Sign-On Serverを有効化する場合、次の機能でFormsアプリケーションを保護できます。

11.1.2.1 動的ディレクティブ

動的ディレクティブmod_ossoは、Oracle Single Sign-On Serverで保護されたFormsアプリケーションを実行します。必要に応じ、このディレクティブを使用して、同じOracle Forms Servicesインスタンスから保護されていないFormsアプリケーションを実行できます。これらのアプリケーションは、同じ構成ファイルとFormsサーブレットを使用します。アプリケーションに対するシングル・サインオンは、formsweb.cfg構成ファイルのアプリケーション定義にあるOracleAS Single Sign-On Serverパラメータを使用して有効化します。

11.1.2.2 Oracle Internet Directoryにおける動的リソースの作成

以前のOracle Forms Servicesの一部のリリースでは、特定のアプリケーションおよびユーザーでRAD定義が見つからない場合に、エラー・メッセージが表示され、認証済にもかかわらずユーザーはそのFormsアプリケーションを実行できませんでした。Oracle Forms Servicesのこのリリースでは、RAD定義が存在しない場合は、ユーザーがOracle Forms Servicesを構成してリアルタイムにこのアプリケーションのRADを作成できます。DASページにリダイレクトする機能は、シングル・サインオン・パラメータssoDynamicResourceCreateで実現しています。

11.1.2.3 シングル・サインオン使用時のデータベース・パスワードの期限切れ

以前のOracle Forms Servicesの一部のリリースでは、データベース・パスワードが期限切れの場合、Oracle Internet DirectoryのRAD情報は更新されませんでした。そのため、ユーザーは、Formsアプリケーションへの接続時にデータベース・パスワードを更新していました。Oracle Forms Servicesのこのリリースでは、Formsによるデータベース・パスワードの更新に伴ってOracle Internet DirectoryのRAD情報も自動的に更新されます。Oracle Forms Servicesのこの機能を使用するために、追加構成を行う必要はありません。

11.1.3 認証およびアクセス強制

ユーザーによるOracle Forms Services URLの初回リクエスト時など(パートナ・アプリケーションからのリクエスト時も含む)、Oracle Forms ServicesにおけるOracle Single Sign-On Serverサポートの認証フローの詳細は、第9.1.1項「認証フロー」を参照してください。

11.1.4 Oracle Identity Management Infrastructureの使用

Oracle Forms Servicesでは、最小限の構成でOracle Internet Directoryとの統合が強化されています。FormsアプリケーションにOracle Single Sign-On Serverサーバーを構成するとき、Oracle Forms Servicesでは、構成と相互作用の大部分がOracle Internet Directoryで処理されます。

11gにはリポジトリAPIがないことから、Oracle FormsとIdentity Managementの統合では、Formsアプリケーションの配布でFormsとOracle Internet Directory(OID)ホスト間の関係が確立されるときにFormsアプリケーションのIDが登録されます。このプロセスは、Oracle Internet Directoryとの関連付けと呼ばれています。Forms識別名(formsDN)やパスワードなどの関連する情報はCredential Storage Framework(CSF)に格納されます。実行時には、必要な情報がCSFから抽出された後、Oracle Internet DirectoryとのJNDI接続が確立します。Oracle FormsとIdentity Managementの統合には次の統合があります。

  • ブートストラップ時の統合: パスワードを割り当てられたFormsアプリケーション・エンティティ(および識別名)がOracle Internet Directoryに作成されます。

  • 実行時の統合: 以前は、Oracle Internet Directoryへの接続ではリポジトリAPIを使用していました。11gでは、JNDIコールを使用してOracle Internet Directoryに直接接続します。

Oracle Internet Directoryの関連付けと関連付け解除の詳細は、第9.7項「Oracle Internet Directoryの構成」を参照してください。

11.2 Oracle Forms Servicesセキュリティの構成

Oracle Forms Servicesのセキュリティの構成は、Oracle Fusion Middleware Controlで行われます。画面ごとにオンライン・ヘルプを利用できます。詳細は、第4章「Forms Servicesの構成と管理」および第9章「Oracle Single Sign-OnでのForms Servicesの使用」を参照してください。

11.2.1 Oracle FormsのOracle Identity Managementオプションの構成

Oracle Internet Directoryでリソースを動的に作成したり、Oracle Internet Directoryリソースを持たないユーザーが共通リソースを使用できるように、Oracle Forms Servicesを構成することができます。

詳細は、第9章「Oracle Single Sign-OnでのForms Servicesの使用」を参照してください。

11.2.2 Oracle Fusion Middleware Security FrameworkのOracle Formsオプションの構成

Oracle Formsの構成と保護の詳細は、次の各章を参照してください。

11.2.3 RADの保護

RADのセキュリティを強化し、OID管理者が閲覧できないようにするには、次の手順に従います。

  1. ---aci-change.ldif---で囲まれた内容をaci-change.ldifファイルにコピーします。

    ---aci-change.ldif---
    dn: cn=Extended Properties,%s_OracleContextDN%
    changetype: modify
    delete: orclaci
    orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute) by
    guidattr=(orclOwnerGUID)(read,search,compare,write) by
    dnattr=(orclresourceviewers) (read,search, compare, write) by
    groupattr=(orclresourceviewers) (read,search, write) by * (none)
    -
    add: orclaci
    orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute)
    DenyGroupOverride by guidattr=(orclOwnerGUID)(read,search,compare,write) by
    dnattr=(orclresourceviewers) (read,search, compare, write) by
    groupattr=(orclresourceviewers) (read,search, write) by * (none)
    ---aci-change.ldif---
    

    注意:

    aci-change.ldifの中で、orclaci: access to attr=から始まる行は、by * (none)で終わる単独の行なので途中に改行を入れないようにする必要があります。

  2. このLDIFファイルにある%s_OracleContextDN%を、レルム固有のOracleコンテキストが持つ識別名(DN)に置き換えます。

    たとえば、配布でのDNがdc=acme,dc=comである場合、レルム固有のOracleコンテキストはcn=OracleContext,dc=acme,dc=comです。

  3. OID層で次のコマンドを実行します。

    ldapmodify -p <port> -h <host> -D cn=orcladmin -q -v -f aci-change.ldif

  4. このコマンドでは、コマンドライン・パラメータとしてcn=orcladminパスワードを指定していないので、実行するとこのパスワードを要求するメッセージが表示されます。

これらの変更を取り消すには、.ldifファイルにある次の内容を使用して同じコマンドを実行します(前述の注意に留意してください)。

---aci-revert.ldif---
dn: cn=Extended Properties,%s_OracleContextDN%
changetype: modify
delete: orclaci
orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute)
DenyGroupOverride by guidattr=(orclOwnerGUID)(read,search,compare,write) by
dnattr=(orclresourceviewers) (read,search, compare, write) by
groupattr=(orclresourceviewers) (read,search, write) by * (none)
-
add: orclaci
orclaci: access to attr=(orclUserIDAttribute,orclPasswordAttribute) by
guidattr=(orclOwnerGUID)(read,search,compare,write) by
dnattr=(orclresourceviewers) (read,search, compare, write) by
groupattr=(orclresourceviewers) (read,search, write) by * (none)
---aci-revert.ldif---