| Oracle Access Managerアクセス管理ガイド 10g（10.1.4.3） B55477-01 |
|
 戻る |
 次へ |
アクセス・システムのシングル・サインオン機能により、ユーザーは1回のログインで複数の保護されたURLまたはアプリケーションにアクセスできます。この章を読む前に、第4章「ポリシー・ドメインによるリソースの保護」に記載されている用語や概念をよく理解するようにしてください。
この章の内容は次のとおりです。
シングル・サインオンを構成するには、その前提条件として、アイデンティティ・システムとアクセス・システムが実際に稼働していることが必要です。このためには、ディレクトリ・サーバー、アイデンティティ・システム、ポリシー・マネージャ、アクセス・サーバーおよび少なくとも1つのWebGateまたはアクセス・ゲートをインストールおよび構成する必要があります。詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
シングル・サインオンにより、ユーザーは1つの認証で複数の保護されたリソース（Webページおよびアプリケーション）にアクセスできるようになります。アクセス・システムを使用して、どのようなリソースを保護するか定義し、リソースにアクセスするためのルールを設定することで、Webサイトとアプリケーションを保護できます。次のものに関するルールがあります。
認証: 認証とは、ユーザーが本人の主張するとおりの人物であるかどうかを検証するプロセスのことです。ユーザーを認証するため、WebGateでは、ユーザーのブラウザに対して認証資格証明のリクエストがチャレンジ（情報要求）という形で表示されます。チャレンジとは、チャレンジ・メソッドまたは認証メソッドのことを指しています。
認可: 認可とは、ユーザーがリクエストしたリソースへのアクセス権限を持っているかどうかを判定するプロセスのことです。ユーザーには、ポリシーによって保護されたデータまたはアプリケーションを参照または実行することが必要な場合があります。リクエストされたリソースは、ポリシー・ドメインに属することも、そのドメイン内で特定のポリシー（グローバル・ポリシーとは異なる）によって保護されていることもあります。
1つのリソースへのアクセスの保護の詳細は、第4章「ポリシー・ドメインによるリソースの保護」を参照してください。
シングル・サインオンは様々な方法で実装できます。
シングル・ドメイン: ドメイン（たとえば、mycompany.com）内のURLのセットに対してシングル・サインオンを設定できます。
マルチドメイン: 複数のドメイン（たとえば、mycompany.comおよびyourcompany.com）内のURLセットに対してシングル・サインオンを設定できます。
アプリケーションおよびサード・パーティ製品: たとえば、Oracle Access ManagerとIBM WebSphere Application Server間にシングル・サインオンを設定できます。
最初の2つの実装では、暗号化Cookieが使用されます（「シングル・サインオンのCookie」を参照）。これらの実装を機能させるため、エンドユーザーは、Cookieを受け入れるようにブラウザを設定する必要があります。
|
関連項目:
|
アクセス・システムでは、シングル・ドメインおよびマルチドメインのシングル・サインオンを実装する際に、ObSSOCookieと呼ばれる暗号化Cookieを使用します。WebGateでは、認証が成功すると、ユーザーのブラウザにObSSOCookieを送信します。すると、このCookieが、今度は、それ以下のレベルの認証を必要とする他の保護リソースに対する認証メカニズムとして機能します。
ユーザーがブラウザまたは他のリソースへのアクセスをリクエストすると、そのリクエストはアクセス・サーバーに転送されます。ユーザーがログインして、ObSSOCookieが設定されます。アクセス・サーバーでは、URLに対してObSSOCookieを含んだセッション・トークンを生成します。認可資格証明を供給するようユーザーに要求せずにCookieが以降の認可に使用されることで、シングル・サインオンが機能します。
Cookieが生成されると、Cookieの一部は暗号化セッション・トークンとして使用されます。暗号化セッション・トークンには次の情報が含まれます。
認証されたユーザーの識別名（DN）
ユーザーを認証した認証スキームのレベル
詳細は、「認証と認証スキームの概要」を参照してください。
Cookieの発行先となったクライアントのIPアドレス
初めにCookieが発行された時間
最後にCookieが更新された時間
ユーザーがアイドル状態でない場合、Cookieは一定の時間間隔で更新され、セッションがタイムアウトしないようにします。更新間隔は、アイドル・セッション・タイムアウト・パラメータ値の1/4の値です。詳細は、「アクセス・ゲート・プロファイルの表示」を参照してください。
暗号化されていないObSSOCookieデータは、次のとおりです。
Cookieの有効期間
Cookieが有効なドメイン
CookieがSSLを使用してのみ送信できるかどうかを設定するオプションのフラグ
ObSSOCookieは、安全なユーザー認証を行うためのメカニズムです。アクセス・システムによりCookieが生成されると、セッション・トークンのMD-5ハッシュが取られます。ユーザーの認証にObSSOCookieが使用される際、MD-5ハッシュが元のCookieの内容と比較され、Cookieが改ざんされていないかが確認されます。MD-5は一方向ハッシュであるため、復号化はできません。アクセス・サーバーは、セッション・トークンを再度ハッシュ化して、その出力をすでにCookie内に存在するトークンのハッシュと比較します。2つのハッシュが一致しない場合、Cookieは破損しています。セッション・トークンが改ざんされた場合、ハッシュは一致しないものであるとシステムでは想定しています。
シングル・サインオンCookieには、ユーザー名やパスワードなどのユーザー資格証明は含まれていません。
ObSSOCookieの構成は、マスター管理者またはマスター・アクセス管理者によって実行される1回かぎりのアクティビティです。Cookieは、共有シークレットと呼ばれる構成可能な暗号化鍵を使用して暗号化されます。
Oracle Access Manager 10.1.4では、共有シークレットが再生成され、使用する暗号の構成を変更しなかった場合にのみ、ObSSOCookieがグランドファザリングされます。Oracle Access Managerでは、ObSSOCookieの復号化の際、必ず最新の共有シークレットを使用しようとします。これができない場合は、古い方の共有シークレットを使用します。これができない場合、アクセス・システムでは新規の共有シークレットが生成されたかどうかをアクセス・サーバーに問い合せます。いずれの鍵も使用できなかった場合、ユーザーは再認証を受けることを要求されます。
共有シークレット暗号化アルゴリズムは、Oracle Access Manager全体に対しての設定です。ObSSOCookieだけでなく、すべての暗号化Cookieに影響します。
以前のWebGateは10.1.4のアクセス・サーバーと共存できますが、すべてアップグレードすることをお薦めします。異なるリリースのWebGateが混在している環境では、最も古いWebGateに対応する暗号化スキームを使用してください。たとえば、次のようにします。
同一システム内にリリース5.xと10.1.4のWebGateが共存している場合は、RC4を暗号化スキームとして使用します。
同一システム内にリリース6.xと10.1.4のWebGateが共存している場合は、RC6を暗号化スキームとして使用します。
同一システム内にリリース7.0または10.1.4のWebGateのみが共存している場合は、AES暗号化スキームを使用します。
リリース6より古いWebGateでシングル・サインオンを使用する場合は、すべてのWebGateのアップグレードが完了するまで、RC4暗号化アルゴリズムを引き続き使用する必要があります。また、リリース6のWebGateでは、以前のWebGateと新規WebGateとの互換性の保持およびシングル・サインオンの機能のためにRC6が必要です。新しいアクセス・サーバーと以前のWebGateとの間の下位互換性の詳細は、『Oracle Access Managerアップグレード・ガイド』を参照してください。
|
注意: 管理者には暗号化アルゴリズムとしてAESを使用することをお薦めします。RC4やRC6より強力なアルゴリズムであるためです。RC6暗号化はOracle Access Manager 10.1.4で非推奨となり、将来のリリースではサポートされなくなります。 |
鍵を生成し、アクセス・システム・コンソールを使用してObSSOCookieを暗号化します。
詳細は、「共有シークレット鍵の作成」を参照してください。
SSLを使用してのみObSSOCookieを送信するかどうかを設定します。
詳細は、「認証スキーム内のObSSOCookieの保護」を参照してください。
最も単純な形式のシングル・サインオンは、シングル・ドメインで実行されるものです。たとえば、いくつかのホスト上にあるいくつかの制限付きWebサイトを、ドメインmycompany.com内でホストしているとします。適切な権限のあるユーザーが1回認証されただけでこの制限された領域のすべてまたはサブセットにアクセスできるように、シングル・サインオンを設定できます。
シングル・ドメインのシングル・サインオンが機能するには、最低限2つのWebGateを持つ、完全に機能するOracle Access Managerシステムが必要です（後続の各項を参照）。
この項の残りの内容は次のとおりです。
シングル・ドメインのシングル・サインオンでは、ObSSOCookieは、domain1.comなど特定のドメインと関連付けられます。ユーザーは、サーバー（foo1.domain1.comなど）を保護するWebGateの認証を受け、ObSSOCookieが設定されます。次に、ユーザーが、そのドメインの別のサーバー（foo2.domain1.comなど）にあるリソースをリクエストします。この2回目のリクエストでは同じObSSOCookieを使用でき、ユーザーは、そのドメイン内の別のサーバー上の情報をリクエストした場合でも、再認証を受ける必要がありません。
シングル・ドメインのシングル・サインオンは、ドメイン用に構成されたObSSOCookieをWebGate間でやりとりすることで機能します。たとえば、ユーザーが、Webブラウザを介し、WebGate1によって保護されたHost1上のpage1.htmlをリクエストしたとします。図7-1に含まれるプロセスの概要は、Host1上のWebGate1がユーザーにユーザー名とパスワードを要求する際に発生する各イベントを示したものです。アクセス・サーバーは、ユーザーの認証を承認すると、ユーザーにpage1.htmlへのアクセス権を与える権限をWebGate1に与えます。これにより、WebGate1では、ユーザーに対してpage1.htmlへのアクセス権をObSSOCookieとともに与えます。
このユーザーが今度はHost2にアクセスしようとする場合、ユーザーのWebブラウザは、WebGate2に対して、Host2内のページに関するリクエストをObSSOCookieとともに送信します。2つのWebGateが同じCookieドメインを持つ場合、WebGate2ではObSSOCookieを確認してユーザーを認証する判定を下します。つまり、ユーザーは再認証を受ける必要がなくなります。
図7-1におけるプロセス・フローは、次のとおりです。
ユーザーがhost1.domain1.com上のpage1.htmlをリクエストします。
このサーバーを保護するWebGateが、認証チャレンジを表示します。
ユーザーが資格証明を提示し、これがWebGateによってアクセス・サーバーに渡されます。
アクセス・サーバーはユーザーを認証し、ObSSOCookieを渡します。
WebGateにより、page1.htmlがユーザーに表示されます。
ユーザーがhost2.domain1.com上のpage2.htmlをリクエストします。
このサーバーは別のWebGateによって保護されており、このWebGateと最初のWebGateとの間にはシングル・ドメインのシングル・サインオンが構成されています。このため、今回のリクエストにはObSSOCookieが含まれます。
WebGateは、アクセス・サーバーにObSSOCookieを渡します。すると、アクセス・サーバーがCookieを検証して、page2.htmlを提供します。
シングル・サインオン用のシングル・ドメインの構成の概要を次に示します。
タスク概要: シングル・ドメインのシングル・サインオンの有効化
ベンダーの指示に従ってディレクトリ・サーバーとWebサーバーをインストールします。
Oracle Access Managerシステムをインストールし、設定して、稼働するようにします（『Oracle Access Managerインストレーション・ガイド』を参照）。
アイデンティティ・システムをインストールして設定します。
アクセス・システムをインストールして設定します。
WebGateを設定します（「WebGateを構成する手順」を参照）。
このWebGateによって保護されているリソースへのアクセス制御を構成します（「タスク概要: シングル・サインオンの認証および認可スキームの定義」を参照）。
2番目のWebGateを設定します（「シングル・サインオンの2番目のWebGateを構成する手順」を参照）。
2番目のWebGateによって保護されているもう1つのリソースへのアクセス制御を構成します。ここでも、「タスク概要: シングル・サインオンの認証および認可スキームの定義」を参照します。
2つのWebGateに対して同一のプライマリCookieドメインを指定します。
この項では、アクセス・システムのインストールと設定の一環としてWebGateのインストールを完了していることが前提です。詳細は、「前提条件」を参照してください。
アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
WebGateを構成し（「アクセス・ゲートの追加」を参照）、必ず次の操作を行ってください。
「プライマリHTTP Cookieドメイン」にドメイン名を指定します。
たとえば、次のようにします。
host1.mycompany.com
|
注意: より汎用性が高いドメイン名を指定するほど、シングル・サインオン実装の対象となる範囲は広くなります。たとえば、b.comをプライマリCookieドメインとして指定した場合、ユーザーはb.comとa.b.comのリソースに対してシングル・サインオンを実行できます。しかし、a.b.comをプライマリCookieドメインとして指定した場合は、ユーザーはb.comのリソースのリクエスト時に再認証を受ける必要があります。 |
ユーザー・セッション・タイムアウトの値を設定して、ObSSOCookieの持続時間を定義します。このタイムアウトを設定するには、アクセス・サーバーの2つのパラメータを使用します。
最大ユーザー・セッション時間: ユーザーの再認証が必要となるまでにリソースへのユーザー接続が続行される秒数を指定します。
アイドル・セッション時間: ユーザー・アクティビティなしでCookieが有効でいられる秒数を指定します。短いセッションほど、ユーザーはより頻繁に再認証を受けることが必要になります。短いセッションほど安全です。不正なユーザーが無人状態のブラウザにアクセスしたり、傍受されたCookieが攻撃に再利用されるために使用できる時間が短くなるためです。
これらのパラメータの詳細は、第3章「WebGateおよびアクセス・サーバーの構成」を参照してください。
ユーザーが完全修飾ドメイン名を指定するための方法を複数構成します。
シングル・サインオンが機能するには、ユーザーは完全修飾ドメイン名を入力する必要があります。ドメイン名を指定する代替的な方法を作成しておくことができます（「ホスト識別子とホスト・コンテキストの使用方法」を参照）。優先ホストを指定しない場合、様々な既知のIPアドレスとURLがすべて「ホスト識別子」にリストされるようにする必要があります。これが、ユーザーがIPアドレスを入力することなく認証と認可を迂回できるようにする唯一の方法です。
2番目のWebGateによって保護されているもう1つのリソースへのアクセス制御を構成します。次のタスク概要を参照してください。
タスク概要: シングル・サインオンの認証および認可スキームの定義
ドメインの認証スキームとそのスキームのレベルを作成します。
2つのWebGateで異なる認証スキームが使用されている場合、厳格なスキームで認証されたユーザーは、緩いスキームでも認証されますが、その逆はできません。
たとえば、レベル2として定義されたBasic Over LDAP認証スキームがあるリソースへのアクセス権を付与されているユーザーは、それ以下のレベルのスキームがある他のリソースにアクセスできます。これに対して、ユーザーがより厳格な認証チャレンジ（レベル5のクライアント証明書と呼ばれるスキームなど）のあるリソースにアクセスしようとする場合には、再認証を受けることが必要です。
認可スキームを作成します（「認可スキームの追加」を参照）。
次の点に留意して、認可スキームを評価します。
シングル・サインオンを使用するユーザーは、認証テストには成功できても、第2または第3のリソースにアクセスしようとする際、認可テストに失敗する可能性もあります。ドメイン内の各リソースには固有の認可スキームを設定できるためです。
次の手順を参照して、シングル・サインオンの2番目のWebGateを構成します。
同じドメイン内のリソースのセットに対する2番目のWebGateを構成します。
最初のWebGateと同じドメイン構成を2番目のWebGateに与え、2番目のWebGateが最初のWebGateと同じインストールのアクセス・サーバーと通信するようにします。詳細は、「アクセス・ゲートとWebGateの構成」および「アクセス・ゲートおよびWebGateのアクセス・サーバーとの関連付け」を参照してください。
たとえば、次に対してWebGateを設定します。
host2.mycompany.com
アクセス・システム・コンソールで、「アクセス・システム構成」→「アクセス・ゲート構成」の順にクリックします。
最初のWebGateのリンクをクリックします。
「変更」をクリックします。
「プライマリHTTP Cookieドメイン」フィールドに、ドメインを.domain.domainの形式で入力します。
たとえば、次のようにします。
oracle.com
「保存」をクリックします。
「戻る」をクリックします。
2番目のWebGateを選択し、「変更」をクリックして、同じドメインを入力します。
|
注意: 2つのWebGateには、同一のプライマリHTTP Cookieドメインを指定する必要があります。 |
作業内容を保存します。
2つのWebGateを設定し終わると、両者間でのシングル・サインオンが機能します。保護対象とするWebサーバーごとにWebGateをインストールする必要があります。
シングル・サインオン構成でリバース・プロキシを使用する場合は、必ずIPValidationパラメータをfalseに設定するか、アクセス・ゲート構成のIPValidationExceptionsリストにそのプロキシのIPアドレスを追加します。その他の場合は、リバース・プロキシによってクライアントのIPアドレスは隠されます。詳細は、「WebGate用IPアドレス検証の構成」を参照してください。
リバース・プロキシが、認証の成功後、ObSSOCookieをOracle WebLogicに渡さないケースがあります。この問題を回避するため、Oracle WebLogicでリバース・プロキシを使用するときは、Basic Over LDAPではなくフォーム・ベース認証を使用してください。
|
関連項目: 『Oracle Fusion Middlewareセキュリティ・ガイド』のOracle Fusion MiddlewareのSSOの構成に関する章 |
WebGateではデフォルトで、logout.gifとlogout.jpgを除いて、「logout.」（ピリオド「.」を含む）を含んだURLを受信するとユーザーをログアウトさせます。たとえば、logout.htmlやlogout.plなどです。WebGateはこの文字列のあるURLを受信すると、ObSSOCookieの値を「logout」に設定します。
また、WebGateでは指定のURLを、シングル・サインオン・ドメインからユーザーをログアウトさせる信号として処理します。このログアウトURLは、「アクセス・ゲート構成」ページで構成します。詳細は、「アクセス・ゲート構成パラメータ」を参照してください。構成を指定しない場合は、デフォルトの動作が使用されます。
たとえば、次のログアウトURLを構成できます。
/access/oblix/lang/%lang%/logout.html
/logout.htm
最初のURLの例で、%lang%は、特定の言語パックのためのディレクトリを表します。
WebGateのLogOutURLs設定にカスタムURLを指定すると、デフォルトの動作を無効化できます。ログアウトURLは複数個指定できます。詳細は、「アクセス・ゲート構成パラメータ」を参照してください。ブラウザのリクエストごとに、構成済ログアウトURLのリストがスキャンされ、ユーザーをシングル・サインオン・ドメインからログアウトさせるかどうかが判定されます。UNIXコンピュータでは、ログアウトURLで大/小文字が区別されます。
マルチドメインのシングル・サインオンを使用することで、ユーザー認証は複数のドメインのすべてのホストで成功します。マルチドメインのシングル・サインオンの主な目的は、各ドメインからのObSSOCookieをユーザーに提供することです。複数のドメイン間でCookieをやりとりすることはできません。アクセス・システムで複数のドメイン間でのシングル・サインオンを実現するには、認証用のプライマリ・ドメインを指定する必要があります。このプライマリ・ドメインは、すべての認証の中央ハブとして機能します。ユーザーがどのドメインから認証を受けようとしているかを問わず、各WebGateでは、1つのURLとして表現されたプライマリ・ドメインにユーザーをリダイレクトします。
マルチドメインのシングル・サインオンの実装方法および機能は、シングル・ドメインのシングル・サインオンの場合とほぼ同様です。ただし、次の相違点に注意してください（詳細は、「シングル・ドメインのシングル・サインオン」を参照してください）。
シングル・ドメインのシングル・サインオンの場合、1つのドメインでWebGateを構成します。一方、マルチドメインのシングル・サインオンの場合は、各ドメインの各認証サーバー上でWebGateを構成し、認証サーバーの1つをプライマリ認証サーバーに指定します。
シングル・ドメインのシングル・サインオンの場合、WebGateにより、特定のドメインのObSSOCookieがユーザーに提供され、そのCookieがドメイン内のすべての保護リソースに対して有効となります。一方、マルチドメインのシングル・サインオンの場合、一連のリダイレクトにより、各ドメインの指定WebGateからの様々なObSSOCookieがユーザーに提供されます。
マルチドメインのシングル・サインオンが機能するには、すべてのドメインのWebGateが認証スキームの完全セットに対するアクセス権を備えている必要があります。つまり、使用環境にあるすべてのアクセス・サーバーが同一のポリシー・ディレクトリを使用する必要があるということです。このディレクトリは、レプリケートしてもかまいません。
マルチドメインのシングル・サインオンが機能するのはWebGateでのみで、アクセス・ゲートでは機能しません。たとえば、「アプリケーションのシングル・サインオン」に記載したアプリケーションは、独自のシングル・サインオン・メソッドを備えています。アクセス・ゲート・ベースのシングル・サインオンのスキームとWebGateベースのマルチドメインのシングル・サインオンのスキームを統合するには、これらのアクセス・ゲートのフロントエンドとして機能するプロキシを構成する必要があります。
図7-2に、複数のドメインからのObSSOCookieをユーザーに提供するプロセスを示します。図の説明が続きます。
ユーザーがブラウザからWebページのリクエストを開始します。
たとえば、host1.domain1.com/page1.htmlがリクエストされます。
host1.domain1.comのWebGate1が、認証リクエストをプライマリ認証サーバー宛てにユーザーのブラウザ経由で返送します。
この例では、host2.domain2.comがプライマリ認証サーバーに指定されています。
認証のリクエストは、ユーザーのブラウザからプライマリ認証サーバーに送信されます。
このリクエストはアクセス・サーバーで受信されます。ユーザーがログインし、domain2.comのObSSOCookieが設定されます。アクセス・サーバーでも、URLに対してObSSOCookieを含んだセッション・トークンを生成します。
セッション・トークンとObSSOCookieがユーザーのブラウザに戻されます。
セッション・トークンとObSSOCookieがhost1.domain1.comに送信されます。
host1.domain1.comのWebGateは、独自ドメイン（domain1.com）のObSSOCookieを設定し、リソースresource host1.domain1.com/page1.htmlに対するユーザーの元のリクエストに対するレスポンスを戻します。
これ以降にユーザーがhost3.domain3.comにリクエストを送信すると、同じリダイレクション・セットが生成され、このドメインのCookieが設定されます。
プライマリ・ドメインのObSSOCookieが設定済のため、ユーザーはdomain3にログインする必要がなくなります。
前述したように、マルチドメインのシングル・サインオンの実装は、シングル・ドメインのシングル・サインオンの実装と似ています。
「タスク概要: シングル・ドメインのシングル・サインオンの有効化」を手引きとして使用しつつ、「マルチドメインのシングル・サインオン」に記載されている相違点も必ず理解するようにしてください。
リダイレクションを実装します（「リダイレクションによるマルチドメインのシングル・サインオンの有効化」を参照）。
実装をテストします（「マルチドメインのシングル・サインオンのテスト」を参照）。
ログアウトを構成します（「マルチドメインのシングル・サインオン・セッションからのログアウト」を参照）。
この項の残りの内容は次のとおりです。
マルチドメインSSO構成に含まれる各WebGateでは、認証スキームをリダイレクション・ルールとともに定義する必要があります。たとえば、3つの認証サーバーがあり、それぞれ別個のドメインにあるとします。
host1.domain1.com
host2.domain2.com（プライマリ認証サーバー）
host3.domain3.com
各WebGateで設定できるのは、独自ドメインのObSSOCookieのみです。そのため、ユーザーがログイン時にプライマリ認証サーバーにリダイレクトされるようにリダイレクション・ルールを作成する必要があります。この例では、プライマリ認証サーバーはhost2.domain2.comです。
|
注意: リダイレクション・ルールは、プライマリ認証サーバーでも必要です。 |
詳細は、次の手順を参照してください。
アクセス・システム・コンソールで、「アクセス・サーバー構成」→「認証管理」の順にクリックします。
認証スキームのリンクをクリックします。
「チャレンジ・リダイレクト」フィールドで、マルチドメインのシングル・サインオン・スキームのプライマリ認証サーバーを入力します。
マルチドメインSSOスキームの各ドメインのWebGateと、それらのドメインのリソースを保護しているすべての認証スキームについて、これらのステップを繰り返します。
この手順により、すべてのドメインのサーバーがプライマリ認証サーバーにリダイレクトされます。
個々のドメイン内で、すべてのWebGateが同じプライマリHTTP Cookieドメインを使用するように構成されていることを確認します。「WebGateの構成」を参照してください。
|
注意: シングル・ドメイン内でプライマリCookieドメインを指定しない場合、個々のドメイン内の他のWebGateではマルチドメインのObSSOCookieを使用できません。 |
マルチドメインのシングル・サインオンをテストします（「マルチドメインのシングル・サインオン」を参照）。
マルチドメインのシングル・サインオン構成をテストするには、Cookieを受信したら通知するようにブラウザを設定します。シングル・サインオンが稼働していれば、構成した各ドメインからセッションCookieの通知を受信できます。
アプリケーションからログアウトすると、アクセス・システムにより、現在のドメインのObSSOCookieのみが削除されます。たとえば、domain1、domain2およびdomain3にログインし、domain1からログアウトした場合、domain1のObSSOCookieのみが削除されます。
Cookieのタイムアウトは、常に、認証を実行するコンピュータによって決定されます。たとえば、www.a.comでCookieの有効期限を1時間に設定し、www.b.comで30分に設定したとします。ユーザーがwww.b.comを訪れ、認証のためにwww.a.comにリダイレクトされます。30分後にwww.b.comのCookieが期限切れになり、ユーザーはwww.a.comにリダイレクトされます。www.a.comのCookieはまだ有効なので、ユーザーは再認証を要求されません。ドメインwww.b.comでは、新しいCookieを設定し、タイムアウトの値をゼロからカウントし始めます。アイドル・セッション・タイムアウトと最大ユーザー・セッション・タイムアウトの詳細は、「アクセス・ゲート構成パラメータ」を参照してください。
www.a.comのタイムアウト値を他のドメインのタイムアウト値未満に設定できます。これにより、他のドメインのCookieのいずれかが期限切れになったときには必ず認証が行われます。この設定の短所は、www.a.comの有効期限が短すぎるとシングル・サインオンが行われない可能性があることです。www.a.comのCookieが、シングル・サインオンでのユーザーの次回の試行の前に期限切れになることがあるためです。シングル・サインオン機能と有効期限ポリシーとの間のバランスの判断が必要となります。
|
警告: ユーザーに対してマルチドメインのシングル・サインオンを構成する場合は、必ずすべてのブラウザ・ウィンドウを閉じるか、ログインしているすべてのドメインから明示的にログアウトするようユーザーに指示してください。 |
アクセス・システムにより、高信頼性のWebを作成できます。これは、ユーザーの資格証明が1回検証されると、ユーザーが実行するアプリケーションに提供されるものです。この資格証明を使用することで、アプリケーションは独自のメカニズムでユーザーを再認証する必要がなくなります。アプリケーションのシングル・サインオンを使用すると、アクセス・システムによって認証されたユーザーは再認証なしでアプリケーションにアクセスできます。
Cookieの使用: アプリケーションがユーザーの本人証明のために抽出するブラウザのCookieに対して、特定の値が設定されます。
どちらの方法でのシングル・サインオンにも、追加のプログラミングが必要です。
ヘッダー変数は、アクセス・システムによって認識または保護されているWebサーバーへのみリダイレクトできます。認証アクションとして渡されるヘッダー変数は、ユーザー・セッション全体にわたっては永続しません。認証アクションの詳細は、「認証アクションの管理」を参照してください。
たとえば、ユーザーの認証時、ヘッダー変数をポータル索引ページにリダイレクトすることができます。
http://mycompany.com/authnsuccess.htm
認証アクションにより、認証失敗時には、ユーザーはエラー・ページまたは自己登録スクリプトにリダイレクトされます。
http://mycompany.com/authnfail.htm
この項の残りの内容は次のとおりです。
アプリケーションのシングル・サインオンの追加情報は、『Oracle Access Manager統合ガイド』を参照してください。次にOracleが保証する統合をいくつか示します。
Oracle Identity Federationとの統合: フェデレーテッド認証とフェデレーテッド認可を有効にします。『Oracle Access Manager統合ガイド』ではフェデレーテッド認可について説明しています。フェデレーテッド認証とフェデレーテッド認可については、『Oracle Secure Federation Services Administration Guide』を参照してください。
OracleAS、OC4Jとの統合: Oracle AS上で稼働するアプリケーション（Oracle eBusiness Suiteなど）間でOracle Access Managerシングル・サインオンとID管理を有効にします。
RSA SecurIDとの統合: SecurIDは、RSA Security社の2要素認証製品です。アクセス・システムでは、システム固有のSecurID認証のためのプラグインとその他のコンポーネントを用意しています。
mySAPとの統合: mySAPアプリケーションやその他のOracle Access Managerで保護されるエンタープライズ・リソースおよびエンタープライズ・アプリケーションに対して、Oracle Access Managerシングル・サインオンを有効にします。また、Oracle Access Manager認証スキームをmySAPアプリケーション用に構成することもできます。
Plumtree Corporate Portalとの統合: 統合されたIDベースのWebアクセス管理機能を持った、カスタマイズされた安全なビジネス・ポータルを作成できるWebエンタープライズ・ソリューションを企業に提供します。このソリューションでは、Plumtree Corporate Portalはエンタープライズのイントラネットまたはエクストラネットのゲートウェイとして機能し、ユーザーがエンタープライズによってホストされているアプリケーションとコンテンツにアクセスする際には必ずこのゲートウェイを経由します。
WebSphere用コネクタ: IBM WebSphereで稼働するアプリケーションをOracle Access Managerのアクセス制御機能およびID管理機能と統合できるようにします。WebSphere用コネクタを使用すると、WebSphere上のJ2EEリソースとアプリケーションがアクセス・システムを使用して認証、認可、監査およびシングル・サインオンを行うことができます。また、アイデンティティ・システムにより、委任管理、動的グループ、ワークフローなどのID管理機能を実行できます。
WebLogic SSPI用セキュリティ・プロバイダ: Oracle（旧称はBEA）WebLogicプラットフォームにデプロイされているJ2EEアプリケーション間でのシングル・サインオンを実現します。セキュリティ・プロバイダにより、WebLogicの管理者は、Oracle Access Managerを使用してビジネス・アプリケーションへのアクセスを制御できます。セキュリティ・プロバイダでは、WebLogic Portalのリソースに対する認証を行い、Oracle Access ManagerとWebLogic PortalのWebアプリケーションの間でのシングル・サインオンをサポートします。また、セキュリティ・プロバイダには、ユーザー管理機能とグループ管理機能も備わっています。
アクセス・システムでは、自身で保護するリソースにアクセスする各ユーザーまたはアプリケーションに対してObSSOCookieを設定します。ObSSOCookieにより、ユーザーは、同等以下の認証レベルを持つアクセス・システムで保護されているその他のリソースにアクセスできます。「シングル・サインオン・ログアウトURLの構成」の手順に従ってログアウト・フォームとログアウトURLを構成した場合は、SSOログアウトURLをコールすると、ObSSOCookieが削除されます。このため、ユーザーは、次回アクセス・システムで保護されているリソースにアクセスする際には再認証が必要となります。
詳細は、「シングル・サインオン・ログアウトURLの構成」を参照してください。
アクセス・システムでは、アイデンティティ・システムを、他のリソースの場合と完全に同様の方法で保護できます。
アクセス・システムのインストール時に、アクセス・システムでアイデンティティ・システムのアプリケーションを保護するよう指定できます。この指定により、次の2つのポリシー・ドメインが自動的に作成されます。
/accessで始まるアクセス・システム・アプリケーションを保護するポリシー・ドメイン
/identityで始まるアイデンティティ・システム・アプリケーションを保護するポリシー・ドメイン
詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
この項の残りの内容は次のとおりです。
アクセス・システムのインストール時には、自動的にポリシー・ドメインを構成してアイデンティティ・システム・アプリケーションを保護するオプションを指定できますが、ポリシー・ドメインはこの後の各手順を使用していつでも手動で構成できます。
アイデンティティ・システム・アプリケーションを保護するポリシー・ドメインを作成する手順
「ポリシー・マネージャ」で、新規のポリシー・ドメインを作成します（第4章「ポリシー・ドメインによるリソースの保護」を参照）。
「リソース」タブで、リソース・タイプとしてhttp、URL接頭辞として/identityを入力します。
「デフォルト・ルール」タブで、選択したチャレンジ・メソッドを使用して、アイデンティティ・アプリケーションを保護する認証ルールを作成します。
Oracle Access and Identity Basic Over LDAP認証スキームには、非アクティブなユーザーがアイデンティティ・システムにアクセスできないようにする機能が組み込まれています。
「デフォルト・ルール」タブで、ユーザー・アクセスを制御する認可ルールを作成します。
認可ルールを構成する際には、次の図を参考として使用してください。
次に、主要なアイデンティティ・システムの機能（ロスト・パスワード管理や自己登録など）へのアクセスを可能にするポリシーを作成します。
次の4つの画面で、ポリシーの概要を示します。
|
注意: ポリシーごとに、匿名認証スキームを構成して、アクセスを許可または拒否するユーザーを構成します。 |
アクセス・システム・アプリケーションを保護するポリシー・ドメインを作成する手順
「ポリシー・マネージャ」で、新規のポリシー・ドメインを作成します。
「リソース」タブで、リソース・タイプとしてhttp、URL接頭辞として/accessを入力します。
「デフォルト・ルール」タブで、選択したチャレンジ・メソッドを使用して、アクセス・システム・アプリケーションを保護する認証ルールを作成します。
「デフォルト・ルール」タブで、該当するユーザーのアクセスを許可または拒否する認可ルールを作成します。
前の項の「アイデンティティ・システム・アプリケーションを保護するポリシー・ドメインを作成する手順」のステップ4と同じアクションを追加します。
Oracle Access Managerの共通JavaScript、gifなどへのアクセスを許可するポリシーを作成します。
匿名認証スキームを構成し、アクセスを許可または拒否するユーザーを構成します。
別のシステム（アクセス・システムなど）と接続するためアイデンティティ・システムでシングル・サインオンが有効になっている場合、アクションを使用してヘッダー変数にユーザー・タイプを定義できます。アクセス・システムでは、このユーザー・タイプを取得して表示します（obnavigation.xmlファイルに、対応する正しい値がある場合）。ユーザー・タイプが設定されていない場合は、アクセス・システムではobnavigation.xmlファイルに定義されたデフォルト値を使用します。
トラブルシューティングの詳細は、付録E「Oracle Access Managerのトラブルシューティング」を参照してください。
Windows環境では、すべてのプロセスとスレッドはセキュリティ・コンテキストで実行されます。偽装はセキュリティ・コンテキストで実行するスレッドの機能で、スレッドを所有するプロセスの機能とは異なります。
サービスは、クライアントのセキュリティ・コンテキストで実行すると、特定の範囲についてクライアントとして機能します。サービスのスレッドの1つは、アクセス・トークン（クライアントの資格証明を表す保護されたオブジェクト）を使用して、クライアントのオブジェクトへのアクセス権を取得します。
偽装の第一の目的は、クライアントの識別情報に対するアクセス・チェックを起動することです。IISで有効化された偽装はオーバーライドされます。偽装の有効化の詳細は、『Oracle Access Manager統合ガイド』を参照してください。
トラブルシューティングの詳細は、付録E「Oracle Access Managerのトラブルシューティング」を参照してください。
