10g（10.1.3.1.0）
B31857-01
 目次 |
 索引 |
| Oracle Containers for J2EE セキュリティ・ガイド 10g（10.1.3.1.0） B31857-01 |
|
OC4J 10.1.3.1実装には、他のOracle Application Serverシングル・サインオン製品のような、必要な追加インフラストラクチャに依存しない代替Javaシングル・サインオン・ソリューションがパッケージ化されています。このJava SSOは、第13章で説明するOracleAS JAAS ProviderID管理フレームワークに基づいており、次のいずれのデプロイメント・シナリオでもWebアプリケーション間で使用できます。
この章では、OC4J Java SSOについて説明します。この章の内容は次のとおりです。
注意
ここでは、次に示すようなJava SSOの概要について説明します。
Oracle Application ServerでOracle Single Sign-Onを使用するには、Oracle Identity Managementによる個別のOracle Application Serverのインストールが必要です（Oracle Internet Directory、Oracle Single Sign-OnおよびOracle Databaseを含む）。または、Oracle Access Managerのシングル・サインオン・ソリューションを使用するには、Oracle Access Managerを完全にインストールする必要があります。これらのシングル・サインオン・ソリューションは、必要なインフラストラクチャと密接に連携しています。どちらも堅牢ですが、小規模なデプロイメント・シナリオでは実行できず、それ自体ではスタンドアロンOC4Jと併用できません。
または、OC4J 10.1.3.1実装によってJava SSOを提供する方法もあります。この場合、Java SSOはOC4J自体とともにパッケージ化され、使用するIdentity Serverの種類に関係なく、OC4Jとの連携が解除されます。これにより、同じOC4Jインスタンスやクラスタにデプロイされたアプリケーションの認証を一元化し、ユーザーIDを共有することができます。
OC4J Java SSOは、OracleAS JAAS Providerによってサポートされる任意のセキュリティ・プロバイダと併用できます（概要は、「OracleAS JAAS Providerおよびセキュリティ・プロバイダの概要」を参照）。さらに、特定の要件に準拠するログイン・モジュール（カスタム・モジュールを含む）をJava SSOと併用できます。特に、OC4Jに付属するログイン・モジュールRealmLoginModule、LDAPLoginModule、DBTableOraDataSourceLoginModuleは、ID管理フレームワークのIDアサーション機能をサポートし、Java SSOおよびパートナ・アプリケーションと併用できます。（「Oracleコールバック実装」で説明するIdentityCallbackのインスタンスは、アサートするIDの確認に使用されます。）
Java SSOには、専用のJava SSOアプリケーション（OC4Jで事前にデプロイ）とOracleAS JAAS ProviderのID管理フレームワークの実装が含まれています。
この項の内容は次のとおりです。
OC4J Java SSOと特定のアプリケーションが連携する仕組みを説明するため、次の3つの基本的なシナリオを検討します。
通常のJava SSOとの対話は、次のとおりです。
App1などのアプリケーションから、保護されたコンテンツにアクセスしようとします（保護されたURLをリクエスト）。
App1はSSO認証を必要とするため、クライアントはJava SSOによって資格証明を要求されます。
App1にアクセスします。
App1は、CookieのクライアントIDを確認し、保護されたコンテンツへのクライアントのアクセスを許可します。
App2など）の保護されたコンテンツにアクセスしようとします。
App2は、CookieのクライアントIDを確認し、保護されたコンテンツへのクライアントのアクセスを許可します。
Java SSOの使用中は、次のいずれかが起きるまで、ユーザー・セッションはアクティブの状態になります。
Java SSOの使用を共有する一連のアプリケーションは、パートナ・アプリケーションと呼ばれています。パートナ・アプリケーションは、カスタマ・アプリケーションかOracle Application Serverコンソール・アプリケーション（Application Server Control、Oracle BPEL Process ManagerまたはOracle Web Services Managerなど）のいずれかになります。パートナ・アプリケーションはセキュリティ・ドメイン内のアプリケーションの1つであり、Java SSOを使用して認証を委任します。セキュリティ・ドメインでは、複数のアプリケーションが認証プロセスと検証プロセスに使用される共通のIDストア、アルゴリズムおよびキーを共有します。
次の図14-1は、Java SSOロジックのフロー・チャートを示しています。
Java SSOのアプリケーションであるjavassoは、組込みシステム・アプリケーションとしてすべてのOC4Jインスタンスにデプロイされています。このアプリケーションは、ログイン・サーブレットSSOLoginとログアウト・サーブレットSSOLogoutから構成されます。
OC4Jを起動する場合、通常はjavassoが無効になります（Oracle Application Serverの基本インストールを除く）。管理者は、Application Server Controlを使用してjavassoを起動できます。
javassoが有効になった後でJava SSOパートナ・アプリケーションにアクセスしようとすると、プロセスは図14-2のようになります。
App1の保護されたURLにアクセスしようとします。
javassoにリダイレクトされます（具体的にはSSOLoginサーブレット）。
App1のURLがjavassoに渡されます。
javasso機能により、ユーザーに対してJava SSOログイン・ページが表示されます。
javasso機能により、ユーザーはIDストア内の情報に基づいて認証されます。ユーザーが正常に認証されると、SSOLoginサーブレットは認証済IDをJava SSOのCookie（IDトークン）にマップし、対称鍵暗号を使用して署名を行い、Cookieの内容を暗号化します。
App1にリダイレクトされ、保護されたCookieがクライアントに返されます。
App1のコンテンツにアクセスします。
App2の保護されたURLにアクセスしようとすると、認証を受けることなくApp2のコンテンツにアクセスできます。
Java SSOは、第13章「交換可能なID管理フレームワーク」に記載されたID管理フレームワークの実装です。Java SSO実装では、資格証明にCookieを使用します。
Java SSOは、OC4Jとともにインストールされます。Java SSOには、次のものが含まれています。
ORA_OC4J_SSO。
SSOCookieTokenCollector。HTTPリクエストを介して渡されたCookieから資格証明を収集し、CookieのIDトークンを作成してOC4Jに返します。トークンの内容には、内容の整合性を保証するためのユーザーID、発行認証局、トークンの有効期間、デジタル署名が含まれます。
SSOCookieTokenAsserter。ユーザーIDをアサートします。つまり、OC4JからCookieトークンを受信して検証し、Cookie内のIDを確認し、アサートされたIDをIDコールバック・ハンドラでOC4Jに戻します。Cookieトークンをデコードするため、トークン・アサータはすべてのパートナ・アプリケーションとJava SSOアプリケーション間で共有されている共有キーを取得し、Cookieの内容を復号化します。トークン・アサータは、署名を検証してデータを確認します。（Cookieの有効期限が切れている場合はエラーがスローされますが、通常はユーザーがログイン・ページにリダイレクトされます。）
次のJava SSOデプロメント・シナリオは重要です。
javassoアプリケーション、カスタマ・アプリケーション、Application Server Controlが、すべて同じOC4Jインスタンスで実行されます。
Oracle BPEL Process Manager（Business Process Execution Languageエンジン）とOWSM（Oracle Web Services Manager）が、OC4J_SOAインスタンスで実行されます。javassoアプリケーション、カスタマ・アプリケーション、Application Server Controlが、OC4J_Homeインスタンスで実行されます。
system-jazn-data.xmlファイル（ファイルベース・プロバイダ）は、2つのインスタンス間で同期されている必要があります（「ファイルベース・プロバイダと2つのOC4Jインスタンスを使用する場合の考慮事項」を参照）。
Oracle BPEL Process ManagerとOWSMが、OC4J_SOAインスタンスで実行されます。javassoアプリケーション、カスタマ・アプリケーション、Application Server Controlが、OC4J_Homeインスタンスで実行されます。
単一のOracle Internet Directoryインスタンスが、セキュリティ・プロバイダとして使用されます。
javassoアプリケーションとすべてのカスタマ・アプリケーションは、すべてのインスタンスで使用できます。
単一のOracle Internet Directoryインスタンスが、セキュリティ・プロバイダとして使用されます。
ユーザーのJ2EEアプリケーションを標準以外に構成する場合、次の構成手順が必要です。構成手順の詳細は、「Java SSOの設定と構成」に記載されています。
javassoアプリケーションが起動されている必要があります。
jazn.xmlファイルにJava SSOとID管理フレームワーク実装のプロパティが正しく設定されている必要があります。Application Server Controlを使用してプロパティを設定できます。これにより、対称鍵も生成できます。設定は、<jazn>要素の<property>サブ要素に示されています。次の設定があります（デフォルト設定で十分です）。
（トラブルシューティングの項の「資格証明が正しいにもかかわらず、Java SSOログイン・ページに戻る」に記載されているように、必ずCookieドメインを適切に設定してください。）
javassoアプリケーションと同じセキュリティ・プロバイダとIDストアを使用するよう構成されている必要があります。（特に、ファイルベース・プロバイダを使用する場合、同じリポジトリ・ファイルを使用します。複数のOC4Jインスタンスを使用するシナリオは、「ファイルベース・プロバイダと2つのOC4Jインスタンスを使用する場合の考慮事項」を参照してください。）デフォルトでは、javassoはファイルベース・プロバイダを使用するよう構成されていますが、Application Server Controlコンソールを使用すると、この構成を変更できます。カスタマ・アプリケーションであるパートナ・アプリケーションに対しては、デプロイメント中にセキュリティ・プロバイダを構成できます。Application Server Control自体に対しては、Application Server Controlコンソールでセキュリティ・プロバイダを変更する特別な手順があります。含めたい他のOracle Application Serverコンソール・アプリケーションに対して変更が必要な場合、同じように処理するとjavasso用にセキュリティ・プロバイダを変更できます。
<jazn-web-app>要素のauth-method="CUSTOM_AUTH"設定と、orion-application.xmlの<jazn>のサブ要素設定で指定します。ここでは、Java SSOログイン・ページとエラー・ページのローカライゼーションとカスタマイズについて説明します。
Java SSOログイン・ページとエラー・ページには、OC4Jサポートのローカライゼーションが付属しています。これらのページで表示されるコンテンツは、ブラウザの設定に従ってローカライズされます。
カスタム・ログイン・ページまたはカスタム・エラー・ページとJava SSOとの併用は直接はサポートされていませんが、デプロイされたlogin.jspファイル、loginerror.jspファイル、error.jspファイルをカスタマイズし、次のいずれかの処理を実行することができます。
ORACLE_HOME/j2ee/home/applications/javasso/javasso-web/WEB-INF
javasso.earファイルをパッケージしなおし、再度デプロイします。
ここでは、OC4JのJava SSO構成について説明します。この項の内容は次のとおりです。
Application Server Controlを使用してJava SSOとパートナ・アプリケーションを構成することをお薦めします（最初の項を参照）。2番目の項と3番目の項には、結果として設定される構成パラメータとプロパティが記載されています（必要に応じて手動で設定することもできます）。最後の項には、特別な考慮事項とシナリオが記載されています。
Application Server Controlコンソールでは、「Java SSO構成」ページを使用します。このページにナビゲートするには、次の手順を実行します。
この項の以降の部分で、次の項目について説明します。
Oracle Application Serverクラスタ環境の場合、「クラスタ・トポロジ」ページから、必要に応じて任意のOC4Jインスタンスのjavassoアプリケーションを起動できます。
javassoアプリケーションを選択します。
OC4Jスタンドアロン環境でjavassoアプリケーションを起動するには、次の手順に従います。
「Java SSO構成」ページで「インスタンスおよびプロパティ」タブを選択し、Java SSOプロパティを設定します。これにより、新しい対称鍵も生成できます。
「インスタンスおよびプロパティ」ページから、次の項目を指定できます。
AES_128_CBC、AES_192_CBC、AES_256_CBC、DES_EDE_CBCのいずれかを選択します。この情報は、custom.sso.key.alias Java SSOプロパティにコード化されます（「Java SSO構成プロパティ」を参照）。
SSOLoginサーブレットのURL（custom.sso.url.loginプロパティに対応）。複数のホストが存在する場合、完全修飾ドメイン名を使用します。
SSOLogoutサーブレットのURL（custom.sso.url.logoutプロパティに対応）。複数のホストが存在する場合、完全修飾ドメイン名を使用します。
custom.sso.session.timeoutプロパティに対応）。これは非アクティブ・タイムアウトではなく、ハード・タイムアウトです。どのような場合でも、セッションはこの時間が経過するとタイムアウトします。
custom.sso.login.attemptsプロパティに対応）。
Java SSOが適切に構成されていない場合、前述のパラメータを必要に応じて設定した後、「Java SSOの構成」を使用してJava SSOを構成します。これにより、新しい対称鍵が自動的に生成されます。
Java SSOが適切に構成された後で再構成する場合、再構成の適用時に新しい対称鍵を生成するかどうかを指定するチェック・ボックスを使用します。次のいずれかの状況の場合は、新しいキーを生成する必要があります。
前述のパラメータを必要に応じて設定した後、「適用」（「Java SSOの構成」のかわりに表示される）を選択して再構成を適用し、キーを生成します。
設定は、jazn.xmlファイル内の<jazn>要素下の<property>サブ要素に反映されます。クラスタ内では、設定とキーはすべてのOC4Jインスタンスに適用されます。
|
重要
|
使用されるjavassoアプリケーションと、Java SSOを使用する各パートナ・アプリケーションは、すべて同じセキュリティ・プロバイダを使用するように構成されている必要があります。デフォルトでは、javassoはファイルベース・プロバイダを使用するように構成されています。
特定のOC4Jインスタンスでjavassoのセキュリティ・プロバイダを変更するには、Application Server ControlコンソールでそのインスタンスのOC4Jホームページに移動します。スタンドアロン環境では、OC4Jホームページは1つだけです。Oracle Application Serverクラスタ環境では、「クラスタ・トポロジ」ページで該当するOC4Jインスタンスを選択します。
javassoの「編集」タスクに移動します。
javassoの「セキュリティ・プロバイダ」ページで、「セキュリティ・プロバイダの変更」を選択します。各セキュリティ・プロバイダ・タイプには、それを構成するための独自のタスク・セットが必要です。タスクの詳細は、次を参照してください。
前述のように、すべてのパートナ・アプリケーションとjavassoアプリケーションは、同じセキュリティ・プロバイダを使用するように構成されている必要があります。パートナ・アプリケーションであるカスタマ・アプリケーションに対しては、デプロイメント中に適切なセキュリティ・プロバイダを構成します。各セキュリティ・プロバイダ・タイプには、それを構成するための独自のタスク・セットが必要です。タスクの詳細は、次を参照してください。
Java SSOの使用でOracle Application Serverのコンソール・アプリケーションを共有する場合（Application Server Controlなど）、コンソール・アプリケーションが同じセキュリティ・プロバイダを使用していることも確認する必要があります。
Application Server Controlの場合、次の手順に従ってセキュリティ・プロバイダを変更できます。
system-jazn-data.xmlファイルベース・プロバイダ、アプリケーション固有jazn-data.xmlファイルベース・プロバイダ、Oracle Identity Management（「Oracle Internet DirectoryとOC4Jの関連付け」に記載されているように、Oracle Internet Directoryのインスタンスが事前にOC4Jのインスタンスに関連付けられている場合）のどれを使用するかを指定します。
他のコンソール・アプリケーションの場合、セキュリティ・プロバイダを変更する手順は、前の項の「javassoアプリケーション用セキュリティ・プロバイダの構成」で説明したjavassoの場合に似ています。この場合、セキュリティ・プロバイダの変更を有効にするには、アプリケーションを再起動する必要があります。
「Java SSO構成」ページで「関連アプリケーション」タブを選択し、Java SSOを使用できるようにアプリケーションを有効にします。
「関連アプリケーション」ページで、次の手順を実行します。
これにより各アプリケーションに対して、orion-application.xmlファイルの<jazn-web-app>要素にauth-method="CUSTOM_AUTH"が設定されます。
javassoアプリケーションを起動し、Java SSOを使用するようアプリケーションを有効にしてからアプリケーションを起動すると、Java SSOを介してログイン・プロンプトが表示されます。
通常の場合、これまで説明したように、Application Server Controlを使用してJava SSOを構成することをお薦めします。
ここでは、すべてのJava SSO構成プロパティと、OC4Jインストール後のデフォルト設定について説明します。
表14-1は、Java SSOプロパティを示しています。プロパティの設定は、jazn.xmlファイル内の<jazn>要素の<property>サブ要素に反映されます。
Application Server Controlでサポートされないプロパティ（表中で「なし」となっているもの）は、手動で設定する必要があります。
| プロパティ | 説明 | Application Server Controlでの名前 |
|---|---|---|
|
custom.sso.app.url.default |
指定されていない場合、 |
なし |
|
custom.sso.cookie.domain |
Java SSOのCookieが、このDNSドメインに限定されます。デフォルトでは、ドメイン設定がない場合、Cookieは （トラブルシューティングの項の「資格証明が正しいにもかかわらず、Java SSOログイン・ページに戻る」に記載されているように、必ずCookieドメインを適切に設定してください。） |
なし |
|
custom.sso.cookie.path |
デフォルト: |
なし |
|
custom.sso.cookie.secure |
デフォルト: |
なし |
|
custom.sso.key.alias |
Java SSOのCookie IDトークンの内容に署名する際に使用される共有対称鍵を格納します。 |
なし |
|
custom.sso.login.attempts |
デフォルト: 3 |
ログイン試行回数 |
|
custom.sso.session.timeout |
Java SSOのCookieの有効時間（秒）。これは非アクティブ・タイムアウトではなく、ハード・タイムアウトです。どのような場合でも、セッションはこの時間が経過するとタイムアウトします。 デフォルト: 7200 |
セッション・タイムアウト |
|
custom.sso.token.asserter.authtypes |
Java SSOの認証方式。エンド・ユーザーがJava SSOにリダイレクトされた場合に、この認証方式を使用してエンド・ユーザーを認証します。標準的なJ2EE Webアプリケーション認証方式を指定できます。
デフォルト: |
なし |
|
custom.sso.url.login |
|
Java SSOログインURL |
|
custom.sso.url.logout |
|
Java SSOログアウトURL |
デフォルトでは、単一OC4Jインスタンスのインストールの場合、ID管理フレームワーク実装としてJava SSOを使用するようにOC4Jが設定されます。これには、前の項の「Java SSO構成プロパティの説明」で説明したJava SSOプロパティの設定と、「ID管理フレームワーク・プロパティの構成」で説明したID管理フレームワーク・プロパティのJava SSO設定が含まれます。
jazn.xmlに事前に構成されている設定は、次のとおりです。
<jazn provider="XML" location="./system-jazn-data.xml" default-realm="jazn.com"> <!-- properties to configure the 3rd party IDM framework --> <property name="idm.authentication.name" value="JavaSSO" /> <property name="idm.token.asserter.class" value="oracle.security.jazn.sso.SSOCookieTokenAsserter" /> <property name="idm.token.collector.class" value="oracle.security.jazn.sso.SSOCookieTokenCollector" /> <property name="idm.token.type" value="HTTP_COOKIE" /> <property name="idm.token.collector.cookie.1" value="ORA_OC4J_SSO" /> <!-- properties for the out of the box Java SSO --> <property name="custom.sso.url.login" value="/jsso/SSOLogin" /> <property name="custom.sso.url.logout" value="/jsso/SSOLogout" /> <property name="custom.sso.key.alias" value="ssoSymmetricKey" /> </jazn>
|
重要
|
Java SSOを使用する各パートナ・アプリケーションは、Java SSOを有効にするように構成されている必要があります。この場合、Application Server Controlを使用することをお薦めします（「Java SSOを使用するパートナ・アプリケーションの有効化」を参照）。
Java SSOを使用するパートナ・アプリケーションの有効化は、orion-application.xmlファイルの<jazn-web-app>要素内にある認証方式の設定"CUSTOM_AUTH"で指定されます。次に例を示します。
<jazn provider="XML" ... > ... <jazn-web-app auth-method="CUSTOM_AUTH" /> ... </jazn>
これにより、Java SSOの使用とID管理フレームワークの実装が、jazn.xmlの構成に基づいてトリガーされます。
これまではJava SSOの一般的な構成について説明しましたが、ここでは次のような特殊な考慮事項について説明します。
ここでは、SOAインストールなど、2つのOC4Jインスタンスにわたるシングル・サインオン・アクセス用にJava SSOとファイルベース・プロバイダを採用する場合の使用例について説明します。ここで重要になるのは、両方のOC4Jインスタンスに対して、2つのsystem-jazn-data.xmlファイル内のユーザー・アカウントとロールを同期化することです。
次に使用例を示します。
OC4J_HOMEとOC4J_SOAを作成しました（インストーラを使用して作成、またはcreateinstanceを使用して手動で作成）。
OC4J_HOMEでJava SSOをアクティブにし、OC4J_SOAにSOAアプリケーションをデプロイします。
OC4J_HOMEとOC4J_SOAの両方で、ファイルベース・プロバイダを使用します。
デフォルトでは、各OC4Jインスタンスは、それ自体のファイルベース・プロバイダであるsystem-jazn-data.xmlファイルを使用して構成されます。ただし、両方のインスタンスでJava SSOを適切に機能させるには、ユーザー・アカウントとユーザー・ロールが2つのsystem-jazn-data.xmlファイル間で同期化されている必要があります。このためには、OC4Jグループ機能を使用して次の手順を実行します。
JSSO_GROUPを作成します。「OC4Jの基本的なグループ機能」を参照してください。
system-jazn-data.xmlを使用するように構成されていることを確認した後（デフォルト設定）、OC4J_HOMEでJava SSOアプリケーションを起動します。（この使用例では、1つのOC4JインスタンスのみでJava SSOアプリケーションを起動します。）
OC4J_SOAインスタンスにデプロイします。ファイルベース・プロバイダを使用するように各アプリケーションを構成し、各アプリケーションに対してJava SSOを有効にします。
OC4J_HOMEとOC4J_SOAを、JSSO_GROUPのメンバーとして追加します。「OC4Jの基本的なグループ機能」を参照してください。
これらのアプリケーションのユーザーとロールを引き続き管理する場合、JSSO_GROUPに対応するOC4J J2EEServerGroup MBeanを使用し、適切なセキュリティ・プロバイダMBean操作を実行します。このMBeanにより、JSSO_GROUPメンバー間でユーザー・アカウントとロールが同期化されます。「クラスタMBeanブラウザの機能およびJ2EEServerGroup MBean」を参照してください。
複数のOC4Jインスタンスを使用するインストール・タイプの場合、「単一インスタンスOC4Jインストール用デフォルトJava SSOプロパティ設定」で説明するデフォルト構成は適していません。プロパティはjazn.xml内で参照できますが、設定はされていません。
Java SSOのすべての構成およびID管理フレームワークの関連する構成は、インスタンス間で複製されている必要があります。主な問題は、system-jazn-data.xml設定に加えて、jazn.xml内のプロパティやID管理フレームワークのプロパティがApplication Server Controlによって設定されないということです。共有Java SSOキーとApplication Server Controlによって設定されたJava SSOのプロパティは、Application Server Control機能によってすべてのOC4Jインスタンスに対してすでに伝播されています。
必要に応じて次の手順を実行します。
jazn.xml内の関連する他のプロパティ設定をOC4Jインスタンス間で複製します。通常、このようなプロパティに対しては、各OC4Jインスタンスのjazn.xmlファイル内にある構成を手動で複製するのが唯一の方法です。
system-jazn-data.xmlを構成します。（これは、ファイルベース・セキュリティ・プロバイダ、ログイン・モジュール設定、ポリシー設定などの場合です。）OC4Jグループは、「OC4Jの基本的なグループ機能」を参照してください。また、「クラスタMBeanブラウザの機能およびJ2EEServerGroup MBean」では、OC4Jインスタンス間でsystem-jazn-data.xmlのユーザー設定を調整する方法について説明しています。インスタンス間でログイン・モジュール構成をメンテナンスする操作もあります（setLoginModuleなど）。 既存の10.1.3.0.0インストールに対してOC4J 10.1.3.1パッチをインストールする場合、10.1.3.1フレッシュ・インストールとは異なり、「単一インスタンスOC4Jインストール用デフォルトJava SSOプロパティ設定」で説明するデフォルト構成は適していません。これは、jazn.xmlのプロパティが参照されないためです。
この場合、デフォルト構成を手動でjazn.xmlに追加し、「Application Server Controlを使用したJava SSOの構成」で説明する適切なJava SSO構成を実行する必要があります。
Java SSOには、次のユーティリティ・クラスが用意されています。
oracle.security.jazn.sso.util.JSSOUtil
OC4J 10.1.3.1実装では、このクラスは次のAPIを提供します。
Java SSOに付属するJSSOUtilユーティリティ・クラスは、静的logout()メソッドを提供します。アプリケーション固有のログアウトの準備と処理が完了したら、このメソッドはアプリケーション・セッション・ログアウトの最後の手順として使用されます。
logout(HttpServletResponse response, String targetURL)処理中のリクエストに対応するHTTPレスポンス・オブジェクトを指定し、ログアウト後にアプリケーションがリダイレクトされるURLを指定します。アプリケーションは、最初にJava SSOのSSOLogoutサーブレットにダイレクトされ、ここでJava SSO Cookieの設定が解除されてから、指定したターゲットURLにダイレクトされます。
次に例を示します。
JSSOUtil.logout(response, "http://portal.acme.com");
ここでは、前述したJava SSOを使用する場合の重要なアクションを要約します。
開発においては、Java SSOを使用することがほとんどの場合で透過的であり、特別なコーディングを必要としません。統合の1つのポイントはログアウトAPIです（前項の「Java SSOログアウトAPI」を参照）これは、オプションとして使用できます。
構成する場合、次の手順を実行します。詳細は、「Java SSOの設定と構成」を参照してください。Application Server Controlを使用して、すべての手順を実行することができます。
javassoアプリケーションを起動します。
jazn.xml内の<jazn>要素下の<property>要素に書き込まれます。）
javassoアプリケーションを構成します。
javassoと同じセキュリティ・プロバイダを使用するようにパートナ・アプリケーションを構成します。カスタマ・アプリケーションの場合、デプロイメント中にセキュリティ・プロバイダを設定します。Java SSOで共有するOracle Application Serverのコンソール・アプリケーションの場合（Application Server Controlなど）、セキュリティ・プロバイダを適切に変更できます。
orion-application.xmlファイル内にauth-method="CUSTOM_AUTH"が設定されます。）これは、既存アプリケーションをJava SSO対応に変換するために必要な唯一の構成手順です。web.xmlファイルの<login-config>設定は、変更する必要がありません（上書きされます）。ここでは、発生する可能性がある次の問題について説明します。
Java SSOに対して有効になっているパートナ・アプリケーションにアクセスしようとするとページが見つからないというエラーが発生する場合、javassoアプリケーションが実行されていない可能性があります。これをテストするには、SSOLoginサーブレットへのアクセスを行います。次のURLに直接移動できます。
http://host:port/jsso/SSOLogin
または、Java SSOプロパティを構成するApplication Server Controlのページから「ログインURLのテスト」を選択することもできます。
最上位ページのhost:portにリダイレクトされれば、テストは成功です。
javassoアプリケーションを起動する手順は、「javassoアプリケーションの起動」に記載されています。
Java SSOログイン・ページで正しい資格証明を指定したにもかかわらずログイン・ページに戻された場合、次のことが考えられます。
localhostまたはIPアドレスを使用して、パートナ・アプリケーションへアクセスしようとしたため。
javassoアプリケーションに指定したドメインと一致しないパートナ・アプリケーションにアクセスしようとしたため。たとえば、Application Server Controlによって設定されたJava SSOログインURL（およびcustom.sso.url.loginプロパティに対応するログインURL）がhttp://sso.mydomain.com/jsso/SSOLoginとして設定されている場合、http://sso/myapp/index.jspと指定するとアプリケーションにアクセスできません。
custom.sso.cookie.domainプロパティ）が、パートナ・アプリケーションにアクセスしようとしているドメインと一致しないため。たとえば、Cookieドメインが.sso.mydomain.comに設定されている場合、http://app.mydomain.com/myapp/index.jspと指定するとアプリケーションにアクセスできません。ただし、Cookieドメインが.mydomain.comに設定されている場合はアクセスできます。
|
 Copyright © 2006 Oracle Corporation. All Rights Reserved. |
|