| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11g リリース1(11.1.1) B56235-06 |
|
 前 |
 次 |
この章では、OracleAS SSO (OSSO) 10gを使用してSSOを実装する方法について説明します。内容は次のとおりです。
OracleAS Single Sign-Onソリューションは、Webアプリケーションへのシングル・サインオン・アクセスを提供します。Oracle Internet Directoryは、LDAPベースのリポジトリです。
このソリューションは、Oracle WebLogic Serverにデプロイされていて、シングル・サインオンがまだ実装されていないアプリケーションを対象としています。OSSOソリューションの構成に関する要件と手順については、「OSSO IDアサーション・プロバイダの新規ユーザー」を参照してください。
JPSログイン・モジュールを介してOracleAS Single Sign-Onソリューションを使用していて、OSSOにリクエストを動的にリダイレクトするアプリケーションは、新しいOSSOソリューションの影響を受けることはありません。この場合、この項の説明に従って新しいOSSO認証プロバイダを構成する必要はありません。
この項の内容は次のとおりです。
この項では、OracleAS Single Sign-On IDアサーション・プロバイダの実装時に想定される動作について説明します。この項の内容は次のとおりです。
図18-1は、OSSO IDアサーション・プロバイダを含む、Oracle WebLogicセキュリティ・フレームワーク内のコンポーネントの配置を示しています。詳細は、図の後に説明します。
図18-1 Oracle WebLogicセキュリティ・フレームワーク内のOSSOコンポーネントの配置
図の最上部に、Oracle HTTP Serverがインストールされています。このインストールにはmod_weblogicとmod_ossoが含まれています。これらは、アイデンティティ・トークンをプロバイダとOracle WebLogic Serverに渡すために必要になります。Oracle WebLogic Serverには、パートナ・アプリケーションとIDアサーション・プロバイダが含まれています。図の右側にある10g OracleAS Single Sign-Onサーバー(OSSO Server)は、ディレクトリ・サーバーおよびOracle HTTP Serverと直接通信します。
|
注意: 説明を簡潔にするために、この章では、Apache用WebLogic Serverプラグインの汎用名(mod_weblogic)を使用します。Oracle HTTP Serverの10gと11gでは、このプラグインが次の名前になります。
|
図18-2は、IDアサーション・プロバイダでOSSOを実装した場合に発生する処理を示しています。詳細は、図の後に説明します。
保護されたリソースに対するリクエストが初めて中間層のWebサーバーに到達すると、そのリクエストは、ユーザー資格証明を要求する10g OracleAS Single Sign-Onサーバーにリダイレクトされます。証明書ベースの認証の場合は、ログイン・ページは表示されません。ユーザーが正常に認証されると、そのユーザーによるすべての後続リクエストでは、JAASサブジェクトの移入前に、OSSO IDアサーション・プロバイダがユーザー・アイデンティティをアサートするだけで済みます。サブジェクトは、ダウンストリーム・アプリケーションによって使用されます。
たとえば、フロントエンドにOracle HTTP ServerがデプロイされているOracle WebLogic Serverにアプリケーションが存在するとします。このアプリケーションは、mod_osso構成のリソース・マッピングを使用して保護されます。これについては、次のプロセス概要で説明します。
ユーザーが保護されたアプリケーションをリクエストします。
Oracle HTTP Serverはリクエストをインターセプトし、mod_ossoを使用してリクエストを処理して、既存の有効なOracle HTTP Server Cookieがあるかどうかをチェックします。
有効なOracle HTTP Server Cookieがない場合、mod_ossoはOracleAS SSO Serverにリダイレクトし、SSO Serverは認証中にディレクトリと通信します。
正常に認証されると、mod_ossoはOSSOサーバーによって移入された暗号化済のユーザー・アイデンティティを復号化し、ヘッダーにユーザー属性を設定します。
mod_weblogicが後続処理を完了し、リクエストをOracle WebLogic Serverにリダイレクトします。
WebLogicセキュリティ・レイヤーにより、設定と指定された順序に従ってプロバイダが呼び出されます。たとえば、セキュリティ・レイヤーによって次のものが呼び出されます。
Oracle HTTP Serverを介してレスポンスがユーザーに送信され、アプリケーションへのアクセスが許可されます。
この項では、Oracle HTTP Serverによって送信されるヘッダーとヘッダーに設定されるトークン、およびOSSO IDアサーション・プロバイダが使用するヘッダーについて説明します。アプリケーションでJAASサブジェクトを使用する必要がある場合は、OSSO IDアサーション・プロバイダを構成してください。
表 18-1は、Oracle HTTP Serverによって設定されるヘッダー(mod_ossoおよびmod_weblogic)のリストを示しています。アプリケーション・ロジックで、ユーザー情報の識別にJAASサブジェクトを使用するアプリケーションは、OSSO IDアサーション・プロバイダを使用するよう構成されている必要があります。OSSO IDアサーション・プロバイダは、表内の太字で示されているOracleAS SSOトークン・タイプ(Proxy-Remote-User)を使用します。OSSO IDアサーション・プロバイダはProxy-Remote-Userヘッダーを検索し、ユーザーのアイデンティティをアサートします。その後、OID認証プロバイダがJAASサブジェクトを移入します。
表 18-1 Oracle HTTP Serverによって送信されるヘッダー
| 属性 | サンプル値 | 説明 |
|---|---|---|
|
Cookie |
OHS-Stads42.us.oracle.com:7777=....... |
Cookie |
|
Osso-User-Guid |
4F4E3D2BF4BFE250E040548CE9816D7E |
認証されたユーザーのGUID |
|
Osso-User-Dn |
cn=orcladmin,cn=users, dc=us,dc=oracle,dc=com |
認証されたユーザーのDN |
|
Osso-Subscriber |
DEFAULT COMPANY |
サブスクライバ名 |
|
Osso-Subscriber-Dn |
dc=us,dc=oracle,dc=com |
サブスクライバのベースDN |
|
Osso-Subscriber-Guid |
4F4E3D2BF410E250E040548CE9816D7E |
サブスクライバのGUID |
|
Proxy-Remote-User |
ORCLADMIN |
認証されたユーザー |
|
Proxy-Auth-Type |
Basic SSO |
認証タイプ |
ユーザー情報の識別にJAASサブジェクトを必要としないアプリケーションは、request.getHeader() APIを使用してヘッダーを直接読み取ることができます。このようなアプリケーションは、必要なヘッダーを自由に読み取ることができます。ユーザー情報を含むヘッダーは、Osso-User-Dn、Osso-User-GuidおよびProxy-Remote-Userです。
新しいOracleAS Single Sign-Onソリューションでは、OSSO IDアサーション・プロバイダが提供されています。これは、Oracle WebLogic Serverで使用可能な2つの新しい認証プロバイダの1つです。
アプリケーションでOSSOソリューションを使用するには、次のタスクで説明されているコンポーネントが必要です。
|
注意: コンポーネントがすでにインストールおよび設定されている場合、新しいコンポーネントは必要ありません。デプロイメントに該当しない手順は省略できます。 |
タスクの概要: OSSO IDアサーション・プロバイダのデプロイおよび構成
次のコンポーネントをインストールします。
OracleAS Single Sign-On Server 10g (10g OSSO Server)
|
関連項目: Oracle Technology NetworkにあるOracle Application Serverのインストレーション・ガイド( |
10g OSSO Serverで使用するように構成されたOracle Internet Directory。ディレクトリ・サーバーがデプロイメント用に調整されていることを確認してください。
|
関連項目: 次のリリース11g (11.1.1.1.0)のマニュアル
|
次のWebサーバーのいずれか1つ(Apache 2に基づく)。
Oracle WebLogic ServerのフロントエンドとしてのOracle HTTP Server 11g。このインストールには、mod_ossoとmod_weblogicが含まれています。
リリース10.1.3のOracle HTTP ServerのCompanion CDに含まれているOHS 10g。これには、mod_ossoが含まれています。ただし、mod_weblogicを追加する必要があります。
|
関連項目: 次のリリース11g (11.1.1.1.0)のマニュアル
|
Oracle WebLogic Server 10.3.1以降
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』 |
Oracle Identity Management、Oracle SOA Suite、Oracle WebCenterなどのOracle Fusion Middleware製品が必要です。該当する製品の次のパスに、Oracle WebLogic ServerによるOSSOのために必要なプロバイダが含まれています。
ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
|
関連項目:
|
「mod_weblogicの構成」の説明に従って、Oracle WebLogic Serverにリクエストを転送するようにmod_weblogicを構成します。
「OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録」の説明に従って、モジュールmod_ossoをパートナ・アプリケーションとして10g SSO Serverに登録します。
「Webリソースを保護するためのmod_ossoの構成」の説明に従って、mod_ossoを構成します。
「OSSO用WebLogicドメインへのプロバイダの追加」の説明に従って、OSSO IDアサーション・プロバイダを適切なドメインに追加します。
「Oracle WebLogic Serverとその他のエンティティの間の信頼の確立」の説明に従って、接続フィルタを構成します。
「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明に従って、アプリケーションによるソリューションの使用を構成します。
「OSSO IDアサーション・プロバイダのデプロイメントのトラブルシューティング」を参照して、OSSO IDアサーション・プロバイダの実装に関する問題を特定して解決します。
Oracle HTTP Serverのhttpd.confファイルを直接編集するか、別のファイルにmod_weblogic構成を追加して、そのファイルをhttpd.confに含めることができます。
次に、2つの異なるWebサーバー・リリース向けの手順について説明します。デプロイメントに応じて、必要な手順を実行してください。
OHS 11gにはmod_wl_ohs.soが含まれています。この場合、手順1を省略します。
OHS 10gには、mod_weblogic (mod_wl_.so)が含まれていません。Oracle HTTP Server 10gがインストールされている場合、ステップ1から開始して、構成を行う前に、mod_wl_20.soをコピーしてください。
|
注意: Oracle HTTP Serverの10gと11gでは、このプラグインが次の名前になります。
|
mod_weblogicをインストールして構成するには
Oracle HTTP Server 10.1.3: 次の例のように、mod_wl_20.soをOracle HTTP Serverモジュール・ディレクトリにコピーします。
コピー元: WL_HOME/wlserver_10.0/server/plugin/linux/i686
コピー先: ORACLE_HOME/ohs/modules
Oracle HTTP Serverのhttpd.confファイルを見つけます。例:
Oracle HTTP Server 10.1.3:
ORACLE_HOME/ohs/conf/httpd.conf
Oracle HTTP Server 11g:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
適切な構成ファイルを含めるか、構成自体を直接含めて、mod_weblogic構成がhttpd.confに含まれていることを確認します。たとえば、Oracle HTTP Server 10gの場合は次のようにします。
LoadModule weblogic_module ${ORACLE_HOME}/ohs/modules/mod_wl_20.so
<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>
<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>
mod_ossoモジュールは、OracleASアプリケーションへの認証を提供するOracle HTTP Serverモジュールです。このモジュールはOracle HTTP Server上に存在します。これにより、ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onによって保護されているアプリケーションが、ユーザー名とパスワードのかわりにHTTPヘッダーを受け入れるようになります。これらのヘッダーの値は、mod_osso Cookieに格納されます。
mod_ossoモジュールは着信リクエストを調べて、リクエストされたリソースが保護されているかどうかを特定することにより、Oracle HTTP Serverに対するシングル・サインオンを可能にします。保護されている場合、Oracle HTTP Server Cookieが取得されます。
状況によっては、10.1.4のOracle Identity Managerのシングル・サインオン登録ツール(ssoreg.shまたはssoreg.bat)を使用して、Oracle HTTP Serverのmod_ossoを登録する必要があります。表18-2は、このために使用するパラメータと値の概要を示しています。登録ツールを実行すると、osso.confファイル内のmod_osso登録レコードが更新されます。このツールを実行するたびに、このファイルが生成されます。
表18-2 Oracle HTTP Serverのmod_ossoを登録するためのssoregパラメータ
| パラメータ | 説明 |
|---|---|
|
-oracle_home_path |
10.1.4 SSO Oracle_Homeのパス。 |
|
-site_name |
対象となる任意のサイト名。 |
|
-config_mod_osso |
TRUE。TRUEに設定すると、このパラメータは、登録中のアプリケーションがmod_ossoであることを示します。osso.confを生成するには、config_mod_ossoを含める必要があります。 |
|
-mod_osso_url |
フロンドエンドOracle HTTP Serverのホスト:ポートのURL。これは、パートナ・アプリケーションへのアクセスに使用されるURLです。値は、URL形式(http://oracle_http_host.domain:port)で指定する必要があります。 |
|
-update_mode |
オプション。デフォルト値のCREATEでは、新しいレコードが生成されます。 |
|
-remote_midtier |
登録するmod_ossoパートナ・アプリケーションがリモート中間層にあることを指定します。このオプションは、構成するmod_ossoパートナ・アプリケーションが別のORACLE_HOMEに存在し、OracleAS Single Sign-Onサーバーが現在のORACLE_HOMEでローカルに実行されている場合にのみ使用してください。 |
|
-config_file |
osso.confが生成されるパス。 |
|
[-admin_info |
オプション。mod_osso管理者のユーザー名。このパラメータを省略すると、「パートナ・アプリケーションの編集」ページの「管理者情報」フィールドが空白になります。 |
|
admin_id |
オプション。電子メール・アドレスや管理者などに関する追加情報。このパラメータを省略すると、「パートナ・アプリケーションの編集」ページの「管理者の電子メール」フィールドが空白になります。 |
|
<VirtualHost ...> |
ホスト名。オプション。このパラメータは、Oracle HTTP仮想ホストをシングル・サインオン・サーバーに登録している場合にのみ指定してください。仮想ホストを登録していない場合、このパラメータは省略します。 HTTP仮想ホストを作成している場合、httpd.confファイルを使用して、保護された各URLに対するディレクティブを入力します。 |
|
関連項目: Oracle Technology Networkにある(
|
次の手順には、mod_ossoを登録するためのサンプル・コマンドが記載されています。その値は、使用する環境によって異なります。
mod_ossoを登録するには
次の10.1.4のOracle Identity Managerディレクトリのパスに移動します。
ORACLE_HOME/sso/bin/ssoreg
環境に応じて、次のパラメータと値を指定してssoregを実行します。たとえば、Unixでは、次のようになります。
./ssoreg.sh -oracle_home_path \OraHome -site_name wls_server -config_mod_osso TRUE -mod_osso_url http://oracle_http_host.domain:7788 -update_mode CREATE -remote_midtier -config_file \tmp\osso.conf
必要なOracle HTTP Serverのモジュールmod_ossoが登録されていることを確認します。
mod_ossoは、リクエストしたURLが保護されるよう構成されている場合にのみ、ユーザーをシングル・サインオン・サーバーにリダイレクトします。URLは、静的または動的に保護できます。静的ディレクティブは、ユーザー操作からmod_ossoに制御を渡すことでアプリケーションを保護します。動的ディレクティブは、アプリケーションを保護するだけでなく、アプリケーションによるユーザー・アクセスの規制も可能にします。
詳細は、次を参照してください:
mod_osso.confファイルにディレクティブを適用することにより、mod_ossoを使用してURLを静的に保護できます。リクエストが適切にインターセプトされるように、mod_ossoを構成する必要があります。さらに、保護されるURIの場所、タイムアウト時間および認証方式を指定します。httpd.confファイルにおけるweblogic_module文のロード箇所より前に、mod_osso.confのinclude文を配置することをお薦めします。
次の手順では、mod_osso.confファイルを編集してmod_ossoを構成する方法について説明します。この手順には、2つの異なるリリース向けの詳細が示されています。OHSデプロイメントの指示に従ってください。
Oracle HTTP Server 11g: 手順2と手順4のAuthType Ossoが必要です。手順5のパス名は、Oracle HTTP Server 11gでは異なります。
Oracle HTTP Server 10g: 手順3と手順4のAuthType Basicが必要です。手順5のパス名は、Oracle HTTP Server 10gでは異なります。
Webリソースを保護するためにmod_ossoを構成するには
osso.confを生成場所から次の場所にコピーします。
コピー元: /tmp/osso.conf
コピー先:
ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
Oracle HTTP Server 11g: 編集するために、mod_osso.confを無効なディレクトリからmoduleconfディレクトリにコピーします。例:
コピー元:
ORACLE_INSTANCE/config/OHS/<ohs_name>/disabled/mod_osso.conf
コピー先:
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
Oracle HTTP Server 10g: 編集するために、mod_osso.confを見つけます。例:
ORACLE_HOME/ohs/conf/mod_osso.conf
mod_osso.confを編集して、デプロイメントに応じた値を使用して次の情報を追加します。ここでは、例としてOracle HTTP Serverを使用します(10gの場合はパスが異なります)。
LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
#Location is the URI you want to protect
<Location />
require valid-user
#OHS 11g AuthType Osso
#OHS 10g AuthType Basic
AuthType Osso
</Location>
</IfModule>
編集するために、httpd.confファイルを見つけます。例:
Oracle HTTP Server 10.1.3:
ORACLE_HOME/ohs/config/httpd.conf
Oracle HTTP Server 11g:
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
httpd.confで、環境に応じたmod_osso.confファイルのパスが含まれていることを確認します。例:
include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
Oracle HTTP Serverを再起動します。
|
ヒント: リクエストのインターセプトが正常に機能しない場合、httpd.conf内でLoadModule weblogic_module文の前にmod_osso.confのinclude文を配置してください。 |
動的ディレクティブを使用するアプリケーションでは、mod_ossoによる保護が1つ以上の動的ディレクティブとして直接アプリケーションに書き込まれるため、mod_osso.confへの入力は必要ありません。
動的ディレクティブは、特殊なエラー・コードを含むHTTPレスポンス・ヘッダーです。これにより、アプリケーションは複雑なシングル・サインオン・プロトコルを実装することなく、シングル・サインオン・システムから詳細な機能をリクエストできます。アプリケーションからシンプルなHTTPレスポンスの一部としてディレクティブを受け取ると、mod_ossoは適切なシングル・サインオン・プロトコル・メッセージを作成し、それをシングル・サインオン・サーバーに通信します。
OracleASでは、JavaサーブレットおよびJSP向けの動的ディレクティブがサポートされています。現時点では、PL/SQLアプリケーション向けの動的ディレクティブはサポートされていません。次のJSPは、このようなディレクティブの組込み方法を示しています。対応する静的アプリケーションと同様、これらの動的サンプル・アプリケーションではユーザー情報が生成されます。
例18-1 動的ディレクティブによるSSO認証
home.jspには、request.getUserPrincipal().getName()メソッドを使用してセッション内のユーザーをチェックするssodynauth.jspが含まれています。ユーザーが存在しない場合、動的ディレクティブ499(簡易認証のリクエスト)が発行されます。重要な行は太字で示されています。
//home.jsp <%@ include file="ssodynauth.jsp" %> <% //page content goes here %> //ssodynauth.jsp <% response.setHeader("Cache-Control", "no-cache"); response.setHeader("Pragma", "no-cache"); response.setHeader("Expires", "0"); %> <% // Check for user String ssoUser = null; try ( //ssoUser = request.getRemoteUser(); ssoUser = request.getUserPrincipal( ).getName( ); ssoUser = ssoUser.trim( ); } catch(Exception e) { ssoUser = null; } // If user is not authenticated then generate // dynamic directive for authentication if((ssoUser == null) || (ssoUser.length() < 1)) { response.sendError(499, "Oracle SSO"); return; }%>
|
関連項目: Oracle Technology NetworkのOracle Identity Managementアプリケーション開発者ガイド 10g (10.1.4.0.1) 原典部品番号: B15997-01 ( |
例18-2 動的ディレクティブによるSSOログアウト
グローバル・ログアウト(シングル・ログアウトとも呼ばれます)を実現するには、アプリケーションによってセッションが無効化された後にOSSOログアウトがコールされる必要があります。logout.jspにより、動的ディレクティブ470 (OSSOログアウトのリクエスト)が発行されます。ログアウト後の戻りURLを指定するために、アプリケーションによってosso-return-logoutが設定されます。
動的ディレクティブによるSSOログアウトの重要な行は、次の例で太字で示されています。11gでは、SSOFilterによってセッション同期が処理されます。
//logout.jsp
<%@page session="false"%>
<%
response.setHeader("Osso-Return-Url", "http://my.oracle.com/");
HttpSession session = null;
session = request.getSession();
if (null != session )
{
// necessary for achieving SLO
session.invalidate();
}
response.sendError(470, "Oracle SSO");
%>
|
関連項目:
|
OSSO IDアサーション・プロバイダをWebLogicドメインに追加する必要があります。OSSO IDアサーション・プロバイダに加えて、次の認証プロバイダをお薦めします。
これらのプロバイダは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して追加できます。
|
関連項目:
|
次の手順では、Oracle WebLogic管理コンソールを使用して認証プロバイダを追加する方法を示します。開始する前に、次の条件に注意してください。
ステップ10: アプリケーションでOracle Internet Directoryユーザーと大/小文字が一致しているユーザー(大文字、小文字、先頭大文字)が要求される場合は、「取得したユーザー名をプリンシパルとして使用する」を選択します。要求されない場合は、選択しないでください。
OSSO IDアサーション用のWebLogicドメインにプロバイダを追加するには
WebLogic管理コンソールにログインします。
OSSO IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。
デフォルト認証プロバイダ:
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
デフォルト認証プロバイダをクリックします。
制御フラグをOPTIONALに設定し、「保存」をクリックします。
OID認証プロバイダ: このプロバイダを次の手順で追加します。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「新規」をクリックして、名前とタイプを入力します。
名前:OID認証プロバイダ
タイプ: OracleInternetDirectoryAuthenticator
「保存」をクリックします。
新しく追加された認証プロバイダをクリックして、「設定」ページを表示します。デフォルト設定を保持します。Oracle Internet Directory構成が有効であることを確認するまで、制御フラグを変更しないでください。
|
注意: OID認証プロバイダが唯一のプロバイダである場合、WebLogic Serverのユーザー・アカウントとそのアカウントに付与されたグループ・メンバーシップがOracle Internet Directoryで作成されていることを確認してください。作成されていない場合、WebLogicドメインは正常に開始されません。 |
「プロバイダ固有」タブをクリックして、次の必要な設定を指定します。
ログイン例外の原因を伝播: 選択。
プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。
ホスト: Oracle Internet Directoryのホスト名。
取得したユーザー名をプリンシパルとして使用する: 選択。
資格証明: LDAPの管理ユーザー・パスワード。例: password。
資格証明の確認: 例: password。
グループ・ベースDN: Oracle Internet Directoryのグループ検索ベース。
ユーザー・ベースDN: Oracle Internet Directoryのユーザー検索ベース。
ポート: Oracle Internet Directoryのポート。
プロバイダの並べ替え: プロバイダによってサブジェクトにプリンシパルが移入される順序は重要であり、レルム内のすべてのプロバイダのリストを並べ替えて、新しく追加されたプロバイダをリストの先頭に移動できます。
すべての構成設定を保存します。
変更を有効にするために、Oracle WebLogic Serverを停止してから再起動します。
WebLogic管理コンソールにログインします。
「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。
「ユーザーとグループ」タブを選択して、構成された認証プロバイダに含まれているユーザーとグループのリストを確認します。
Oracle Internet Directory構成のユーザー名が表示されます。これは、この構成が機能していることを暗黙的に表しています。
- Oracle Internet Directoryインスタンスが正常に構成されている場合、制御フラグを変更できます。
- Oracle Internet Directory認証のみでアプリケーションのユーザーを識別できる場合、SUFFICIENTフラグを選択します。SUFFICIENTは、ユーザーがOracle Internet Directoryに対して認証された場合、その他の認証は処理されないことを意味します。REQUIREDは、別のプロバイダによってユーザーがすでに認証されている場合でも、認証プロバイダによって正常に認証される必要があることを意味します。
アプリケーションでOracle Internet Directoryユーザーと大/小文字が一致しているユーザーが要求される場合: 「取得したユーザー名をプリンシパルとして使用する」を選択します。要求されない場合は、選択しないでください。
変更を保存します。
変更をアクティブ化して、Oracle WebLogic Serverを再起動します。
Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。
|
注意: この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。WebLogic管理コンソールで。 |
ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。これは、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。これは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。
接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。
targetAddress localAddress localPort action protocols
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項 |
表18-3は、接続フィルタの各パラメータを説明しています。
表18-3 接続フィルタ・ルール
| パラメータ | 説明 |
|---|---|
|
target |
フィルタ対象の1つ以上のシステムを指定します。 |
|
localAddress |
WebLogic Serverインスタンスのホスト・アドレスを定義します。(アスタリスク(*)を指定すると、すべてのローカルIPアドレスが返されます。) |
|
localPort |
WebLogic Serverインスタンスのリスニング・ポートを定義します。(アスタリスク(*)を指定すると、サーバー上のすべての使用可能なポートが返されます。) |
|
action |
実行するアクションを指定します。この値は、allowまたはdenyである必要があります。 |
|
protocols |
フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。 |
「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。
11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」の下の「ドメイン」をクリックします。
「セキュリティ」タブ→「フィルタ」タブをクリックします。
「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。
ドメインで使用する次の接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。
適切な接続フィルタ・ルールの構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
この項では、OSSO IDアサーション・プロバイダ用のアプリケーション認証方式の作成方法について説明します。
|
関連項目: 『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』 |
Oracle WebLogic Serverは、複数のauth-methodsの追加をサポートしています。WebLogicアプリケーション・コンソールでOSSO IDアサーション・プロバイダを設定している場合、OSSO IDアサーション・プロバイダを使用するWebアプリケーションのauth-methodがCLIENT-CERTに設定されている必要があります。
Oracle WebLogic Serverにアプリケーションをデプロイした後、次の手順で説明されているように、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素にCLIENT-CERTが含まれている必要があります。
OSSO IDアサーション・プロバイダ用にweb.xmlを編集するには
アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。例:
WEB-INF/web.xml
該当するレルムのauth-methodを検索し、CLIENT-CERTと入力します。例:
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myRealm</realm-name>
</login-config>
ファイルを保存します。
アプリケーションを再デプロイして再起動します。
アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。
Fusion Middleware 11gには、コンテナ・ユーザー・セッションとSSOセッションを同期する新しいコンポーネントが導入されています。SSO同期フィルタは、Oracle WebLogicシステム・フィルタの実装です。SSO同期フィルタは、コンテナへのすべてのリクエストをインターセプトし、保護されたリソース・リクエストを操作して、コンテナのユーザー・セッションとOSSOのユーザー識別ヘッダー(Proxy-Remote-User)、またはOracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データとの同期を試みます。
SSO同期フィルタは、Javaサーブレット仕様バージョン2.3に基づくサーブレット・フィルタの実装です。SSO同期フィルタにより、アプリケーションはSSOユーザー・セッションを追跡して各セッションと同期する必要がなくなります。アプリケーションは、コンテナのユーザー・セッションと同期するだけで済みます。
SSO同期フィルタは、コンテナへの各リクエストをインターセプトし、そのリクエストに添付されているHTTPヘッダーに基づいて操作するかどうかを決定します。フィルタは、SSOエージェントがこれらのヘッダーをWeb層で設定していることを必要とします。保護されていないアプリケーション領域にアクセスする場合、フィルタはパススルーとして機能します。保護されたリソースにアクセスした後、Web層のSSOエージェントは、Oracle Access ManagerなどのSSOシステムで認証を実行するようユーザーに指示します。認証後、Oracle Access Manager IDアサーション・プロバイダによってユーザー・アイデンティティがJAASサブジェクトとしてコンテナに確立され、ユーザー・セッションが作成されます。WebLogicでは、ユーザー・セッション・データがHTTPセッションCookieの一部(JSESSIONID)として保持されます。
アプリケーション・リソースへの後続アクセスでは、SSO同期フィルタに次の2つの情報が提供されます。
OSSOのユーザー識別ヘッダー(Proxy-Remote-User)
Oracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データ
SSO同期フィルタの役割は、コンテナのユーザー・アイデンティティとSSOセッションのユーザー・アイデンティティが一致していることを確認することです。不一致がある場合、フィルタはそのコンテナのユーザー・セッションを無効にします。このため、ダウンストリーム・アプリケーションはコンテナのユーザー・セッションを追跡するだけで済み、使用しているSSO環境に関係なく一貫した方法で作用できます。
注意:
デフォルトで有効: SSO同期フィルタは、構成されたトークンからユーザー情報をフェッチし、既存セッション(存在する場合)からユーザーを取得し、CurrentSessionUserが着信SSOユーザーと一致していない場合はセッションを無効にしてリクエストされたURLにリダイレクトします。そうでない場合、リクエストは単にパススルーされます。
ドメインでOSSOまたはOracle Access Managerアサーション・プロバイダを構成していない場合、フィルタはWebLogic Serverの起動中に自動的に無効になります。
デフォルトですべてのURIに対して有効(/*): アプリケーション・コードでの変更は不要です。
OSSOトークン/ヘッダーに対する構成: Proxy-Remote-Userが検索され、大/小文字を区別しない一致が実行されます。
Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_REMOTE_USERとREMOTE_USERが検索され、大/小文字を区別しない一致が実行されます。
グローバル・ログアウト: SSO同期フィルタは、OSSOまたはOracle Access Managerソリューションを使用するOracle Fusion Middlewareアプリケーションに対してシングル・ログアウト操作を提供します。これは、シングル・サインオンと同様に処理されます。グローバル・ログアウトが実行されると、セッションのクリーンアップが実行されていないアプリケーションに対して後続アクセスが行われたときに、SSOフィルタによってセッションが調整されます。
OSSOまたはOracle Access Managerソリューションを使用するアプリケーションは、OSSOログアウトまたはOracle Access Managerログアウトをコールする前にそのセッションを無効にする必要があります。OSSOログアウトの詳細は、「動的ディレクティブによるSSOログアウト」を参照してください。Oracle Access Managerログアウトの詳細は、「Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成」を参照してください。
アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。
様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shにEXTRA_JAVA_PROPERTIESがあるか確認します。表18-4に、各プロパティと同期動作を示します。
表18-4 SSO同期フィルタの各プロパティと同期動作
| 領域 | 優先システム・プロパティ | システム・プロパティのデフォルト値 | 同期フィルタのデフォルト動作 |
|---|---|---|---|
|
ステータス(有効または無効) |
sso.filter.enable |
構成なし |
有効 |
|
大/小文字を区別した一致 |
sso.filter.name.exact.match |
構成なし |
大/小文字を区別しない一致 |
|
構成されたトークン |
sso.filter.ssotoken |
構成なし |
|
|
URIマッピング |
なし |
なし |
/* |
一部のアプリケーションに対してフィルタを有効にすることはできません。SSO同期フィルタは、システム・フィルタです。このため、デプロイされているすべてのアプリケーションに対して有効になります(URIマッピングは/*)。
|
注意: 一部のアプリケーションに対してフィルタを有効にすることはできません。 |
次の手順に、SSO同期フィルタのプロパティと動作の変更に関するヒントを示します。
SSO同期フィルタのプロパティと動作を変更するには
フィルタの無効化: システム・プロパティsso.filter.enableをfalseに変更し(jvmに-Dとして渡す)、Oracle WebLogic Serverを再起動します。これにより、フィルタ・ステータスが切り替わります。
ユーザー識別ヘッダーと事前構成済同期フィルタ・トークンの不一致: システム・プロパティsso.filter.ssotokenを使用して、同期フィルタによって検索されるSSOトークンを上書きします。
たとえば、WebLogic Serverの起動スクリプト(-Dsso.filter.ssotoken=HEADERNAME)でWebLogic Server JVMに渡し、サーバーを再起動します。
Oracleサポート・サービスにお問合せの際は、「WebLogic管理コンソールでのデバッグの設定」の説明に従ってデバッグを設定するように求められる場合があります。
この項で説明するトラブルシューティング項目は、次のカテゴリに分かれています。
|
関連項目:
|
この項では、次のトラブルシューティング項目について説明します。
OHSがSSOにリダイレクトしない - 内部サーバー・エラー500
この問題の原因として可能性が高いのは、不適切な構成です。
次のサンプルでは、Oracle HTTP Server 11gを使用しています。Oracle HTTP Server 10gを使用している場合は、パス名が異なります。
それに対処する手順は、次のとおりです。
ファイルmod_osso.confを開き、リソースが保護されていることを確認します。例:
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
<Location /protected-resource-uri> require valid-user AuthType Basic </Location>
osso.confが存在しており、mod_osso.confに組み込まれていることを確認します。ここでは、例としてOracle HTTP Server 11gを使用します(10gの場合はパスが異なります)。
OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf
|
注意: osso.confの場所は特に設定されていません。値は登録時に決定され、任意の絶対パスになります。 |
httpd.confに、mod_osso.confが組み込まれていることを確認します。ここでは、例としてOracle HTTP Server 11gを使用します(10gの場合はパスが異なります)。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
前述の設定をすべて適切に指定してもSSOの登録が正常に完了しない場合、SSOの再登録が必要になります。
SSOを登録するには、プラットフォームに適したssoregツールを使用して次の手順を実行します。例:
10.1.4のORACLE_HOME/sso/binにあるssoreg.shを実行し、ファイルosso.confを作成します。次に、ファイル/tmp/osso.confを作成するこのユーティリティの使用例を示します(例示のためにのみ、引数を別の行に記述しています)。
>ssoreg.sh -oracle_home_path /OraHome
-site_name wls_server
-config_mod_osso TRUE
-mod_osso_url http://host.domain.com:6666
-update_mode CREATE
-remote_midtier
-config_file /tmp/osso.conf
生成されたosso.confを、別のファイル・システム・ディレクトリにコピーします。例: ORACLE_INSTANCE/config/OHS/<ohs_name>/osso。
OHSを再起動します。
属性AuthNameは必要か
ログ・メッセージは、属性AuthNameが必要なことを示している場合があり、特定のバージョンのApacheにはこの属性が必要です。
この例では、Oracle HTTP Server 11gを使用しています。Oracle HTTP Server 10gを使用している場合は、パス名が異なります。
この属性を組み込むには、ファイルmod_osso.confを編集し、次の断片を挿入します。
LoadModule osso_module modules/mod_osso.so <IfModule mod_osso.c> OssoIdleTimeout off OssoIpCheck on OssoConfigFile ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf <Location /> AuthName "Oracle Single Sign On" require valid-user AuthType Basic </Location> </IfModule>
URLリクエストがSSOにリダイレクトされない
URLリクエストを発行したとき、SSOにリダイレクトされるかわりに基本ポップアップが表示される場合は、URLリクエストがApache認証モジュールにインターセプトされた可能性が高いです。
この問題に対処する方法は、次のとおりです。
ファイルhttpd.confを編集し、次の断片に示すように、認可モジュールのロードをコメント・アウトします。
ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf
LoadModule access_module modules/mod_access.so #LoadModule auth_module modules/mod_auth.so #LoadModule auth_anon_module modules/mod_auth_anon.so #LoadModule auth_db_module modules/mod_auth_dbm.so LoadModule proxy_module modules/mod_proxy.so
OHSを再起動します。
エラー404 - 「見つかりません」が発行される(OHS側)
このエラーは通常、次の形式です。
The requested URL <request-uri> was not found on this server
WebLogicリダイレクトが実行されておらず、リクエストが、使用できないOHSリソースを使用しようとしている可能性が高いです。
この問題に対処するには、次の断片に示すようにmod_weblogicがファイルhttpd.confに組み込まれていることと、WebLogicハンドラがリクエスト・パターンに対して設定されていることを確認します。
#httpd.conf <IfModule mod_weblogic.c> WebLogicHost <host> WebLogicPort yourWlsPortNumber </IfModule> <Location /request-uri-pattern> SetHandler weblogic-handler </Location>
エラー404 - 「見つかりません」が発行される(Oracle WebLogic Server側)
このエラーは通常、次の形式です。
Error 404--Not Found
原因
このメッセージは、Oracle WebLogic Serverがリソースを見つけられないことを通知します。
解決策
この問題に対処するには、リソースがサーバーにデプロイされていることを確認します。たとえば、パターンが/private1/Helloである場合、ルートがprivate1であるサーバー上でHelloにアクセスできるかどうかを確認します。
Oracle SSOの失敗 - リクエストを処理できません
問題
次のようなメッセージを受信します。
Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or Oracle HTTP Server single sign-on is incorrectly configured. Please notify your administrator.
解決策
Oracle HTTP Server httpd.confファイルを変更し、ServerNameにポート番号を追加してWebサーバーを再起動します。例:
変更前: ServerName host.domain.com
変更後: ServerName host.domain.com:port
スタンドアロンのWebLogic Serverにデプロイされたアプリケーション用のOSSOソリューション
この章では、Oracle Fusion Middleware Oracle WebLogic Serverにデプロイされたアプリケーションのシングル・サインオン(SSO)の構成方法を説明しています。一方、(Fusion Middlewareが組み込まれていない)スタンドアロンのOracle WebLogic Serverにデプロイされたアプリケーションの詳細は次のとおりです。
OSSOでのOracle Fusion Middleware: 必須OSSO IDアサーション・プロバイダ(ossoiap.jar)は、Oracle Fusion MiddlewareのOracle Identity Management、Oracle SOA SuiteまたはOracle WebCenterのインストール時に自動的に設定されます。
|
注意: OSSOでのOracle Fusion Middlewareにより、Oracle HTTP Server 10gまたは11g Webサーバーのどちらでも使用できます。 |
OSSOでのスタンドアロンOracle WebLogic Server: 必須OSSO IDアサーション・プロバイダ(ossoiap.jar)を、ここで説明したように、Oracle Web層から入手する必要があります。
|
注意: Fusion Middlewareがない場合には、OSSOにはOracle HTTP Server 11gが必要です。 |
OSSOをOracle Fusion Middlewareアプリケーションで使用しても、他のアプリケーションで使用しても、IDアサーション・プロバイダは「OSSO IDアサーション・プロバイダの使用」の説明にある同じ機能を実行します。
以下に記載されているのは、セッションを無効するためのシングル・ログアウトおよびSSO CookieとJSESSIONID Cookieの間の同期を構成してテストする際に使用できる、追加事項、オプション、詳細などです。必須のファイルはOracle Web層から入手する必要があります。
タスクの概要: スタンドアロンのWebLogic Server上のアプリケーションで使用するOSSO IDアサーション・プロバイダのデプロイおよび構成
Oracle WebLogic Server 10.3.1以降とその他の必須コンポーネントを次のとおりインストールします。
「タスクの概要: スタンドアロンのWebLogic Server上のアプリケーション用OSSO IDアサーション・プロバイダのデプロイおよび構成」の説明にあるステップ1のaからdを実行します。
ステップ1eを省略して、使用するアプリケーションをかわりにデプロイします。
webloginドメイン拡張テンプレートを使用してWebLogicセキュリティ・ドメインを作成します。この拡張テンプレートは、Oracle WebLogic Serverに付属しており、$WLS_HOME/common/bin/config.shから使用できます。
「mod_weblogicの構成」の説明に従って、Oracle WebLogic Serverにリクエストを転送するようにmod_weblogicを構成します。
「OSSO IDアサーション・プロバイダの新規ユーザー」の説明に従って、モジュールmod_ossoをパートナ・アプリケーションとして10g SSO Serverに登録して構成します。
「OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録」で説明されている手順を実行します。
「Webリソースを保護するためのmod_ossoの構成」で説明されている手順を実行します。
認証プロバイダを、次のように適切なセキュリティ・ドメインに追加します。
OSSO IDアサーション・プロバイダ(ossoiap.jar)を次のOracle Web層から入手します。
$ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
ossoiap.jarを$WLS_HOME/wlserver_10.x/server/lib/mbeantypeにコピーし、Oracle WebLogic Serverを再起動します。
「OSSO用WebLogicドメインへのプロバイダの追加」の説明に従って、プロバイダを構成します。
「Oracle WebLogic Serverとその他のエンティティ間の信頼の確立」の説明に従って、Oracle WebLogicの接続フィルタ・メカニズムを構成し、アクセス制御リストを作成して、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストからのリクエストを受け入れます。
|
注意: Oracle WebLogic Serverのホストとポートを使用し、保護されたアプリケーションをテストして、デフォルトの認証プロバイダでそのアプリケーションが機能していることを確認します。 |
「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明に従って、OSSO IDアサーション・プロバイダ用のアプリケーション認証メソッドを構成します(アプリケーションEARファイル内のすべてのweb.xmlファイルで、要素auth-methodにCLIENT-CERTが含まれている必要があります)。
|
注意: Oracle HTTP Serverのホストとポートを使用してアプリケーションにアクセスする際に、OSSOが認証したユーザーを使用してアプリケーションをテストします。 |
オプション: 次のように、シングル・ログアウト(セッション無効化およびSSO CookieとJSESSIONID Cookieとの同期)を構成およびテストできます。
次のとおり、ssofilter.jarを入手し、それを使用できるようにOracle WebLogic Serverを構成します。
1. ssofilter.jarを次のOracle Web層から入手します。
$ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar
2. それをOracle Middlewareホームの適切なディレクトリにコピーします(例: WLS_INSTALL/Oracle/Middleware/modules)。
3. Oracle WebLogic Serverのクラスパスにssofilter.jarの絶対パスを追加します(setDomainEnv.shスクリプトのPOST_CLASSPATH変数またはCLASSPATH変数を編集します)。
次のように、system-filters.warをシステム・フィルタとしてデプロイします。
1. system-filters.warを次のOracle Web層から入手します。
$ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war
2. system-filters.warをOracle Middlewareホームの適切なディレクトリにコピーします(例: WLS_INSTALL/Oracle/Middleware/modules directory)。
3. system-filters.warをアプリケーション・ライブラリとしてデプロイします。WebLogic管理コンソールから、「デプロイ」をクリックして、「新規」を選択してファイルの場所を選択します。
4. プロンプトが表示されたら、Oracle WebLogic Serverを再起動します。
次のようにログを有効化してSSOFilterが機能していることを確認します。
1. WebLogic管理コンソールから、「ドメイン」→「環境」→「サーバー」→「管理サーバー」をクリックします。
2. 「ロギング」タブをクリックします。
3. 「詳細」ドロップダウンで、「デバッグ」として「ログの最低の重大度」を選択します。
4. 「詳細」ドロップダウンで「メッセージの宛先」を選択し、「デバッグ」として「ログ・ファイル: 重大度」を選択します。
5. 変更内容を保存して、Oracle WebLogic Serverを再起動します。
SSOFilterがシステム・フィルタとしてロードされていることを確認します。
1. DomainHome/Servers/AdminServer/log/AdminServer.logファイルを開きます。
2. 「SSOFilter」を検索して、<Debug>メッセージが表示されることを確認します。このメッセージは、SSOFilterの初期化を示し、フィルタのロードを確認するものです。
フィルタの機能をテストして、SSO CookieおよびJSESSIONID Cookieがユーザーのログアウト後にクリーンアップされ、ログアウト後のアプリケーションへのアクセス試行では、再度ログインする必要があることを確認します。
|
注意: OSSO IDアサーション・プロバイダがWebLogicセキュリティ・ドメインで構成されるようにする必要があります。そうしないと、フィルタの初期化実行中にフィルタが自動的に無効になります。 |
アプリケーションでログアウトのテストをして、セッションが正確に終了していることを確認します。
「常に監査するユーザー」で指定したSSOユーザーに対する大文字指定
Oracle HTTP Serverの監査の構成にある「常に監査するユーザー」セクションでSSOユーザーを指定する場合、SSOユーザー名を大文字で指定する必要があります。
カンマ区切りのリストで複数のユーザーを指定して、これらのユーザーが開始した監査イベントにこの監査フレームワークが適用されるようにすることができます。監査は、指定された監査レベルやフィルタとは関係なく行われます。これは、あらゆるタイプの認証に当てはまります。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査ポリシーの管理」の章で監査の構成と管理に関する項を参照してください。
この項では、次のトラブルシューティング項目について説明します。
エラー403 - 禁止
このメッセージは、ユーザーがリソースにアクセスするために必要なパーミッションを持っていないことを通知します。このメッセージは、たとえば、アプリケーションがWLSグループSSOUsersに属するユーザーにアクセスを許可するように構成されていて、アサートされたユーザーが別のグループに属している場合に表示されます。
これがパーミッションの問題ではないと確認した場合は、デフォルトのID認証プロバイダのJAAS制御フラグがREQUIREDに設定されているかどうかを確認し、設定されている場合は、その設定を必要に応じてOPTIONALまたはSUFFICIENTに変更します。
エラー401 - 未認可
このメッセージは、リソースにアクセスするには、ユーザーは最初に認証が必要なことを通知します。
解決策
ユーザーが本当に認証されているかどうかを確認します。
SSOを使用した認証を最初に受けずにサーバーにアクセスしようとしていないかどうかを確認します。
OSSO IDアサーションが起動されていない
保護されたソースに対してOSSO IDアサーション・プロバイダを呼び出せない状況には、通常、不適切な構成が関与しています。環境に、「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明のような構成が正確に組み込まれていることを確認してください。
アプリケーション・リソース(URL)へのアクセス時にJSESSIONID Cookieが見つからない場合、WebLogic Serverは、JSESSIONIDをURLの一部として含めることによりURLの再書込みを行います。対象のURLが保護されているときは、再書込みしたURLのマッチングが、Oracle Access ManagerとOSSO Webエージェントでは困難な場合があります。
不一致の問題を回避するには、mod_osso.confに指定されている保護されたリソースの最後にアスタリスク(*)を追加します。たとえば、次のような保護されたURLがあるとします。
/myapp/login
これは、mod_ossoエントリの次の場所にあります。
<Location /myapp/login*> valid user AuthType OSSO </Location>
Mod_ossoモジュールは、SSO対応ログイン・サーバーとOracle HTTP Serverリスナー間の通信を提供します。mod_ossoモジュールは、mod_osso.confファイルを編集することで制御されます。
Oracle HTTP Server 11gのインストールには、mod_ossoとmod_weblogicが含まれています。
Oracle HTTP Server 10.1.3のリリースのCompanion CDに含まれているOHS 10gには、mod_ossoが含まれています。
|
関連項目: 次の各項とリリース1 (11.1.1)のマニュアル
|
この項の内容は次のとおりです。
OSSO CookieにHTTPOnlyフラグ設定を構成するための新しい構成ディレクティブがmod_ossoに追加されました。新しいディレクティブは、OssoHTTPOnlyです。値は、On(フラグの有効化)またはOff(フラグの無効化)です。デフォルトでは、HTTPOnlyフラグはOnに設定されます。このディレクティブは、構成では設定されません。
このディレクティブは、ブラウザに設定されたOSSO CookieにHttpOnlyフラグを追加します。このフラグの目的は、クロスサイト・スクリプティングを防止することです。このフラグが設定されたCookieは、ブラウザで実行されているJavaScriptコードまたはアプレットからはアクセスできません。このフラグが設定されたCookieは、特定のドメインにhttpまたはhttpsを介してCookieを設定したサーバーにのみ送信されます。
これはVirtualHostディレクティブごとに指定します。グローバル・スコープまたはVirtualHostセクション内でのみ設定できます。次の例は、新しいディレクティブを示しています。
<VirtualHost *.7778> OssoConfigFile conf/osso.conf OssoHTTPOnly On --- --- --- <Location /osso> AuthType Osso --- --- </Location> </VirtualHost>
mod_osso 10gでは、OssoSecureCookiesディレクティブはデフォルトで無効になっています。ただし、mod_osso 11gでは、この動作はデフォルトで有効になっています。mod_osso 11gでOssoSecureCookiesディレクティブを無効にするには、対応する構成ファイルでOssoSecureCookiesをOffに設定する必要があります。mod_ossoを有効にすると、次の場所にmod_osso.confファイルが作成されます。
ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf
OssoSecureCookiesディレクティブを設定する手順は、次のとおりです。
OssoSecureCookies "Off"
ログアウトのためにOracle SSO Serverにリダイレクトしたときに、mod_ossoが問合せに戻りURLをエンコードしません。
この問題を修正するには、エンコードされたURLを渡す必要があります。例: response.setHeader("Osso-Return-Url", encoded-url)。
SSOページを表示しようとしたときに「ページが見つかりません」というエラーが発生する原因としては、次のものが考えられます。
ロード・バランサがない状態で同じOHSとのルーティング関係が複数ある: これはサポートされていません。
ルーティング関係がない
解決策: ルーティング関係が複数ある場合
このoc4j_imに関連付けられていない余分なルーティング関係を見つけて削除します。このoc4j_imに関連付けられているルーティング関係は残しておきます。
次のコマンドを使用して、環境内のルーティング関係をすべて表示します。
asctl:/imha/inst1/ohs_im>ls -a -l oc4j_im_ohs_im_routing_relationship -> /imha/inst12/oc4j_im oc4j_im_ohs_im_routing_relationship_ -> /imha/inst11/oc4j_im
操作環境に対応する値を使用して次のコマンドを使用し、特定のoc4j_imに関連付けられていないルーティング関係を削除します。例:
asctl:/imha/inst1/ohs_im> rmrel(name='oc4j_im_ohs_im_routing_relationship_ ',pt='/imha/inst11/oc4j_im')
OHS Webサーバーとoc4j_imの両方を停止して起動します。
SSOページが表示されたことを確認します。
解決策: ルーティング関係がない場合
デフォルトでは、インストーラによって、各OHSと各oc4j_imの間にルーティング関係が作成されます。OHSとoc4j_imの間にルーティング関係がない場合は作成する必要があります。
操作環境に対応する値を使用して次のコマンドを使用し、ルーティング関係を作成します。
createRoutingRelationship(name='rr1',ut='/imha/inst1/ohs_im',pt='/imha/inst12/ @ oc4j_im')
OHS Webサーバーとoc4j_imの両方を停止して起動します。
SSOページが表示されたことを確認します。
Oracle Fusion Middlewareでは、インターネット・プロトコル・バージョン4 (IPv4)およびインターネット・プロトコル・バージョン6 (IPv6)がサポートされます。IPv6の特筆すべき機能は、Pv4 (32ビット)よりも大きいアドレス空間(128ビット)をサポートしていることです。これにより、Web上でアドレッシングできるコンピュータの数が飛躍的に増えます。
|
関連項目: Oracle Single Sign-on ServerでのIPv6使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。 |
