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

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

この章の内容は次のとおりです。

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

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

関連項目

セキュリティの詳細は、次のドキュメントを参照してください。

• 『Oracle Fusion Middlewareセキュリティ概要』には、Oracle Fusion Middlewareセキュリティと、そのコア機能の概要が記載されています。

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

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

Oracle Forms Servicesでのシングル・サインオンは、Oracle HTTP Server用のOracleモジュールであるwebgateを介して使用できます。webgateアクセス・クライアントは、Oracle Access Manager (OAM)に対してユーザーを認証します。

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

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

ユーザーおよびその権限のクラス

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

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

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

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

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

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

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

保護されるリソース

Formsアプリケーションに対してシングル・サインオンを有効化する場合、次の機能でFormsアプリケーションを保護できます。

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

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

認証およびアクセス強制

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

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

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

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

  Oracle Platform Security ServicesまたはOracle Internet Directoryでリソースを動的に作成できるようにOracle Forms Servicesを構成できます。

  詳細は、「Oracle Access ManagerでのForms Servicesの使用」を参照してください。

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

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

  • Oracle Formsアプリケーションの配布の基本

  • Forms Servicesの構成と管理

  • Oracle Access ManagerでのForms Servicesの使用

  • トレースと診断

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---