| Oracle Access Managerアクセス管理ガイド 10g（10.1.4.3） B55477-01 |
|
 戻る |
 次へ |
認証とは、ユーザーが本人の主張するとおりの人物であるかどうかを検証するプロセスのことです。アクセス・システムでは、ポリシー・ドメインおよびポリシーの認証ルールを構成してリソースを保護できます。認証ルールには、認証スキームが含まれます。認証スキームは、ユーザーのアイデンティティを検証する方法を提供します。
この章では、認証スキーム、認証ルールおよび認証ルールの想定内の結果に関連付けるアクションについて説明します。
この章の内容は次のとおりです。
|
注意: ポリシー・ドメインおよびポリシーには、認証スキーム、認可ルール、認可条件式および監査ルールが含まれます。詳細は、「ユーザー認可の構成」を参照してください。ポリシー・ドメインを定義した後、ポリシー・ドメインの認証ルール、認可ルール、認可条件式および監査ルールを任意の順序で定義できます。 |
アクセス・システムを使用して、認証スキームと認証ルールを定義します。これらのスキームおよびルールは、ポリシー・ドメイン内のリソースにアクセスしようとするユーザーの認証方法を設定します。ユーザーを認証するには、そのユーザーに関する情報を取得して処理し、ユーザーが本人の主張するとおりの人物であるかどうかを検証します。
この項の残りの内容は次のとおりです。
|
注意: アクセス・サーバーにリクエストを送信する前に、コンテキスト固有の情報を収集する高度な認証方法もあります。コンテキスト固有の情報は、情報の外部コールの形を取ることができます。このトピックは、フォーム・ベース認証に関する章で説明します。詳細は、「認証リクエストのデータに対する外部コールの使用」を参照してください。 |
この章を読む前に、次の章を参照してください。
この章は、アクセス・ゲートおよびアクセス・サーバーの構成方法について説明しています。構成は、作成するポリシー・ドメインを有効にする前に行う必要があります。
この章は、ポリシー・ドメイン、ポリシー、リソースおよびマスター監査ルールについて説明しています。認証スキームとともにポリシー・ドメインおよびリソースを構成する必要があります。
この章は、認可スキーム、ルールおよび条件式の作成について説明しています。認証スキームを構成する前に、認証メソッドのタイプについての一般知識が最低限必要です。
認証を構成するには、次のコンポーネントを作成します。
認証スキーム: 認証スキームには、ユーザーに資格証明を要求するための方式が含まれます。
認証スキームには、1つ以上のステップも含まれます。各ステップには、認証プロセスの一部を実行する1つ以上のプラグインが含まれます。
認証プラグイン: 通常、プラグインには、ユーザーに資格証明を要求するための方式が実装されています。
アクセス・システムには、デフォルトのチャレンジ・プラグインが用意されています。これらのプラグインを単独で使用することも、カスタム・プラグインと交換または併用することもできます。
アクセス・システムには、資格証明マッピング・プラグインも用意されています。このプラグインは、リソースを要求するユーザーの資格証明とLDAPディレクトリ内のユーザー・プロファイルを照合します。
認証ルール: 認証スキームを構成した後、認証ルールにそれを含めることができます。
ポリシー・ドメインごとに、デフォルトの認証ルールを指定します。ポリシー・ドメイン内のポリシーごとに、認証ルールを作成することもできます。
アクセス・システムを使用してユーザー認証を行うには、ディレクトリの構造が次のいずれかに該当する必要があります。
すべてのユーザー情報が単一ディレクトリの1つのブランチに格納されている。
ユーザー情報が複数のディレクトリ・サーバーに格納されているが、すべてのディレクトリで同じスキーマを使用している。
ユーザー・プロファイル情報をディレクトリの複数のブランチに論理的に分割していて、各ブランチに独自の検索ベースがある。
単一ディレクトリの検索: 認証を使用して、単一ディレクトリの単一の検索ベースを検索できます。この場合、情報がそのディレクトリで見つからないと、ユーザーを認証できず、検索が終了します。
同じタイプの2つのディレクトリの検索: 連鎖認証を使用して、同じOracle Access Managerインスタンスで管理される同じタイプのディレクトリを2つ以上検索できます。
2つのディレクトリの連続検索: 同じタイプのディレクトリを2つ使用して、ユーザーの情報を格納します。あるユーザーに関する情報が見つかるまで、各ディレクトリを検索することもできます。最初のディレクトリで情報が見つかったら、検索プロセスを終了します。最初のディレクトリで情報が見つからなかった場合は、ユーザーのステータスに応じて、次のディレクトリを検索するか、検索を終了することができます。
条件に基づいた2つの異なるディレクトリの検索: 別の連鎖認証スキームを作成して、2つの異なるディレクトリを検索することもできます。たとえば、このスキームでは、ユーザーが従業員の場合は一方のディレクトリを検索し、ユーザーがベンダーの場合は他方のディレクトリを検索するように指定できます。どちらの条件においても、ユーザー情報が最初のディレクトリで見つからなかった場合、第3のディレクトリを検索してから認証プロセスを終了するよう、スキームに指定できます。
同一ディレクトリの複数ブランチの検索: 連鎖認証を使用して、同一ディレクトリの複数ブランチでユーザー・プロファイルを検索できます。いくつかのユーザー・プロファイルをあるブランチに、別のいくつかのプロファイルを別のブランチに、さらにいくつかのプロファイルをさらに別のブランチに格納できます。たとえば、ディレクトリの3番目のブランチにレガシー・データが含まれている場合、3番目のブランチでのユーザー・プロファイルの検索は、他の2つのブランチでユーザーの情報が見つからなかった場合にのみ実行できます。これを実現する認証スキームを構成するには、認証スキームのステップにプラグインを含め、このプラグインを実行することで、最初の検索ベースから開始し、ユーザーの資格証明をユーザー・プロファイルにマップし、ユーザー・プロファイルが見つかった場合には資格証明を処理して検索を終了できます。最初のブランチにユーザー・プロファイルが見つからなかった場合は、スキームのステップを使用して、次の検索ベースを検索するように指示できます。
認証スキームは、ポリシー・ドメインまたはポリシーを使用して保護されたリソースに対してユーザーがアクセスを要求した場合に実行する認証の方法を指定します。認証スキームは、認証ルールの一部です。1ステップしか含まれない単純な認証スキームもあります。連鎖認証の場合、認証スキームには複数のステップが含まれ、これらのステップが特定の条件に応じて相互に結合されて、様々な動作が生成されます。
マスター・アクセス管理者のみが、認証スキームを作成できます。詳細は、「ポリシー・ドメイン管理の委任」を参照してください。
認証スキームは、次の主要コンポーネントで構成されています。
一般情報: 認証スキームの一般情報には、ユーザー・アイデンティティの認証時に、ユーザーに資格証明を要求するための方式や、スキームのセキュリティ・レベルなどのデータが含まれます。
詳細は、「認証スキームの定義および管理」を参照してください。
プラグイン: 認証スキームに1つ以上のプラグインを追加して、ユーザーの資格証明を処理します。
スキームに追加したプラグインのみを、スキームのステップで使用できます。詳細は、「認証のプラグイン」を参照してください。
ステップ: 認証スキームには、1つ以上のステップを含めることができます。各ステップには、1つ以上のプラグインを含める必要があります。
ステップには、そのステップ内での配置順に実行されるプラグインのグループが含まれます。詳細は、「認証ステップの概要」を参照してください。
認証フロー: 認証スキームの各ステップを実行する際に予定される実行順序です。
詳細は、「認証フローの構成」を参照してください。
次の認証スキームは、ポリシー・マネージャの設定時に構成されます。
Oracle Access and Identity Basic Over LDAP: ほとんどのディレクトリ・タイプ用のOracle Access Manager関連のリソース（URL）の保護に使用されます。
AD Forest用のOracle Access and Identity: Oracle Access ManagerシステムをActive Directory構成にインストールした場合にのみ設定されます。
このスキームを使用して、Active Directory用のOracle Access Manager関連のリソース（URL）を保護できます。
匿名: 特定のOracle Access ManagerのURLを非保護とするために使用されます。
匿名認証スキームでは、アクセス・システムで保護しないOracle Access Manager固有のURL（自己登録やロスト・パスワード管理のためのWebページなど）にユーザーがアクセスできます。このスキームでは、「なし」のチャレンジ・メソッドを使用します。つまり、ユーザーに対するチャレンジは行われず、ユーザーが資格証明を入力する必要はありません。
設定中に、ユーザー・ディレクトリ内の構成情報に基づいて、次の2つの認証スキームも構成している場合があります。
Basic Over LDAP: この組込みWebサーバー・チャレンジ・メカニズムでは、ユーザーにログインIDおよびパスワードの入力を要求します。
提示された資格証明は、LDAPディレクトリ・サーバー内のユーザーのプロファイルと比較されます。
クライアント証明書: この認証スキーマは、証明書によるユーザー識別方式です。
この方式を使用するには、証明書がブラウザにインストールされていて、WebサーバーがSSL対応である必要があります。
定義するすべての認証スキームに、チャレンジ・メソッドを含める必要があります。アクセス・システムに付属のチャレンジ・メソッドまたはカスタムのチャレンジ・メソッドを使用できます。
|
注意: アクセス・システムに付属のスキームを使用する場合、プラグイン・パラメータobMappingFilterを必ず実際のディレクトリおよび環境に合せて適切に設定してください。詳細は、表5-2を参照してください。 |
インストール時に構成されるチャレンジ・メソッドおよびスキーム
マスター管理者がアクセス・システムのインストール中にチャレンジ・メソッドを選択した場合、アクセス・システムによって認証スキームが自動的に構成されます。インストール・プロセス時のこれらのスキームの構成の詳細は、『Oracle Access Managerインストレーション・ガイド』を参照してください。
アクセス・システムでは、次の5つのチャレンジ・メソッドがサポートされています。
なし: ユーザーは資格証明情報の入力を要求されません。このメソッドでは、自己登録など、アクセス・システムで保護対象としないアイデンティティ・システム固有のリソース（URL）へのアクセスが許可されます。このメソッドは、ポリシー・マネージャの設定時に構成できる匿名認証スキームで使用されます。チャレンジ・パラメータは使用されません。
Basic: ユーザーは、Webサーバーにより表示されたウィンドウにユーザー名とパスワードを入力する必要があります。
「チャレンジ・パラメータの概要」で説明するように、このメソッドではチャレンジ・パラメータが必要です。このメソッドは、SSLにリダイレクトできます。詳細は、「BasicおよびX.509証明書（クライアント証明書）の概要」を参照してください。
クライアント証明書（X509証明書）: 認証を受けるには、ユーザーのブラウザで、SSLを介したX.509デジタル証明書を、WebGateを使用してアクセス・サーバーに提示する必要があります。
チャレンジ・パラメータは使用されません。ユーザーの組織では、証明書の取得方法を決定できます。詳細は、「BasicおよびX.509証明書（クライアント証明書）の概要」を参照してください。
フォーム: このメソッドは、「Basic」チャレンジ・メソッドに似ていますが、ユーザーが情報を入力するのはカスタムHTMLフォームにおいてです。
作成するフォームで、ユーザーに入力を要求する情報を選択できます。「チャレンジ・パラメータの概要」で説明するように、チャレンジ・パラメータが使用されます。ユーザーを別のサイトにリダイレクトするフォーム・ベース認証の詳細は、「フォーム・ベース認証」を参照してください。
外部: 外部チャレンジ・メソッド（Oracle Access Manager外）を使用します。
このメソッドでは、独自の認証チャレンジ・メソッドを使用できます。
「外部」を使用する場合、チャレンジ・パラメータcredsを指定する必要があります。このパラメータは、外部チャレンジ・メソッドにより設定されるサーバー変数のスペース区切りのリストです。詳細は、『Oracle Access Managerカスタマイズ・ガイド』を参照してください。
BasicおよびX.509証明書（クライアント証明書）の概要
Oracle Access Managerでは、公開鍵暗号化とX.509証明書を使用したクライアント証明書認証がサポートされています。クライアント証明書のチャレンジ・メソッドでは、ブラウザとWebサーバーに組み込むSecure Sockets Layerバージョン3（SSLv3）証明書認証プロトコルが使用されます。クライアント証明書を使用してユーザーを認証するには、クライアント証明書を処理するように構成されているWebサーバーとのSSL接続を、クライアントが確立する必要があります。
BasicでもX.509証明書でも、非SSL接続を介して受信した未認証のリクエストを処理するよう、アクセス・ゲートを構成できます。
クライアント証明書のチャレンジ・メソッドでは、前述のとおり、ユーザーのブラウザを別のサーバーにリダイレクトしてSSL接続を確立するようにアクセス・ゲートを構成します。アクセス・ゲートは、証明書を認証した後、ユーザーのブラウザを元のURLに再びリダイレクトします。
|
注意: Basic認証は、非ASCIIのログイン資格証明では失敗します。非ASCIIのユーザー資格証明は、「フォーム・ベース認証」で説明されているように、フォーム・ベース（「フォーム」）認証でのみサポートされます。 |
チャレンジ・パラメータの概要
チャレンジ・パラメータは短いテキスト文字列で、エンドユーザーが入力する必要のあるユーザー名とパスワードを思い出すためのヒントとして使用されます。
LDAPディレクトリに対するテキスト文字列の例は次のとおりです。
realm:LDAP username + password
チャレンジ・メソッドが「Basic」、「フォーム」および「外部」の場合は、チャレンジ・パラメータが必要です。チャレンジ・メソッドが「なし」または「X509証明書」の場合は、チャレンジ・パラメータは使用されません。
sensitivecredsチャレンジ・パラメータの概要
WebGateで認証エラーが発生してエラー・ページが表示される際に機密情報が表示されないようにする、「Basic」および「フォーム」チャレンジ・メソッド用の新しいチャレンジ・パラメータが提供されています。この新しいチャレンジ・パラメータは次のとおりです。
sensitivecreds
認証スキームには、チャレンジ・パラメータsensitivecredsと、その後に続けて、エラー・ページに表示しないフィールドの名前を示す資格証明の値のスペース区切りのリストを含める必要があります。次に例を示します。
sensitivecreds:password ssn sensitivecreds:password creditcardnumber secret-code sensitivecreds:password creditcardnumber secret\\ code
スペース文字は、各資格証明の値の区切り文字としてのみ使用されます。資格証明の値にスペース文字を単独で含めることはできません。資格証明の値にスペースを定義するには（たとえば、シークレット・コードなど）、値の最初の要素の一部にエスケープ文字\\を使用する必要があります（例: secret\\）。これにより、後続の要素は、別のフィールドではなく最初の要素の一部として解釈されます。つまり、secret\\ codeは、ページ上ではsecret codeとなります。エスケープ文字\\がない場合、値（ code）に含まれるスペースは、2つの個別のフィールド間の区切り文字とみなされます。
次に、例の値について説明します。
最初の例では、passwordは抑止する1つ目のフィールドの名前であり、ssnは抑止する2つ目のフィールドの名前です。資格証明の値にスペースは含まれていません。
2番目の例では、passwordは抑止する1つ目のフィールドの名前であり、creditcardnumberは抑止する2つ目のフィールドの名前であり、secret-codeは抑止する3つ目のフィールドの名前です。
3番目の例では、passwordは抑止する1つ目のフィールドの名前であり、creditcardnumberは抑止する2つ目のフィールドの名前であり、secret\\ codeは抑止する3つ目のフィールドの名前です。ここで、secret\\ codeは、スペースを含む値secret codeを表しています。
|
注意: sensitivecredsを使用する場合は、エラー・ページに表示しないパスワードを受け入れるプラグインをすべて、認証スキームに含める必要があります。 |
sensitivecredsを使用する場合、次の機能に特別な要件や制約はありません。これらは通常どおりに定義できます。
チャレンジ・リダイレクト
ステップ
認証フロー
プラグインは、認証スキームのエンジンです。プラグインにより、チャレンジ・メソッドの実装、ディレクトリ内のユーザー・プロファイルのエントリへのユーザー資格証明のマップ、ユーザー資格証明の処理、認証プロセスに関連するカスタム・タスクの実行などが行われます。認証スキームに組み入れるプラグインには、次の2種類があります。
アクセス・システムに付属のプラグイン
カスタム・プラグイン
認証スキームの基本情報を定義すると、チャレンジ・メソッド用のプラグインを追加できます。詳細は、「認証チャレンジ・メソッド用のアクセス・システム・プラグイン」を参照してください。
各認証スキームには、チャレンジ・メソッド（要求方式）と、ユーザーが提示した資格証明をディレクトリに格納されているそのユーザーのプロファイルにマップする方法を含める必要があります。認証スキームの作成時には、スキームでユーザーの資格証明の要求、マップおよび検証などを行う方法を定義します。たとえば、スキームのチャレンジ・メソッドでは、ユーザーにパスワードの入力か、自分のIDを証明する証明書の提示を要求できます。
認証スキームに、追加の処理を実行するプラグインを含めることもできます。たとえば、プラグインを使用して、条件に基づいて複数のディレクトリを検索し、他のプロセスの結果に基づいてタスクを実行することもできます。認証スキームを作成した後、スキームにプラグインを追加し、スキームのステップおよびステップの実行順序を構成できます。
既存の認証スキームを表示して、作成する認証スキームがすでに定義されているかどうかを確認します。
「認証スキームのリストおよび表示」を参照してください。
必要に応じて、新規の認証スキームを作成します。
「新規認証スキームの定義」を参照してください。
スキームを有効化または無効化します。
「認証スキームの有効化および無効化」を参照してください。
必要に応じてスキームを変更します。
「認証スキームの変更」を参照してください。
不要になった認証スキームを削除します。
「認証スキームの削除」を参照してください。
複数の検索ベース（非結合ドメインまたはレルムとも呼ばれる）を使用する場合のスキームを設定します。
「複数検索ベース使用時の認証スキームの構成」を参照してください。
この項の残りの内容は次のとおりです。
既存の認証スキームをリストして、作成するスキームがまだ定義されていないことを確認できます。スキームの詳細を表示することもできます。
|
注意: 既存のスキームを変更すると、そのスキームはバージョン6.5より前のシステムでは使用できなくなります。 |
アクセス・システムのランディング・ページで、「アクセス・システム・コンソール」リンクをクリックします。
「ポリシー・マネージャ」で作業している場合は、ページの最上部にある「アクセス・システム・コンソール」のリンクをクリックします。
「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
表示する認証スキームの名前をクリックします。
「認証スキームの詳細」ページが表示されます。
認証スキームを定義する前に、次のことを決定しておく必要があります。
スキームの一意の名前と、その動作の簡単な説明
スキームを含む認証ルールを作成する委任アクセス管理者(Delegated Access Administrator)が、リストからスキームを選択します。各スキームの説明を入力すると、管理者のタスクが簡素化されます。
認証スキームのセキュリティ・レベル
スキームのセキュリティ・レベルは、ユーザーからの資格証明の送信の保護に使用されるチャレンジ・メソッドとセキュリティの強度を示します。セキュリティ・レベルは、整数で表されます。
ユーザーは、特定のレベルでリソースに対して認証された後、同じポリシー・ドメイン内または別のポリシー・ドメイン内の他のリソースに対しても、そのリソースのセキュリティ・レベルが元のリソース以下の場合、自動的に認証されます。詳細は「認証スキームのセキュリティ・レベルの変更」および「シングル・サインオンの構成」を参照してください。
ユーザーの資格証明を取得するためのチャレンジのタイプとパラメータ
チャレンジ・メソッドには、認証の実行方法と、ユーザーの認証に必要な情報を指定します。各認証スキームは、1つのチャレンジ・メソッドのみを持つことができます。認証の成功は、チャレンジのレスポンスで取得したユーザーの資格証明が、ディレクトリ内のただ1つのDNのみに一致する場合です。
チャレンジ・パラメータは、通常、認証を実行するための追加情報を（大部分の場合、ユーザーに要求して）WebGateに提供します。チャレンジ・パラメータは、「名前:値」の書式で入力されます。
ユーザーを、Secure Sockets Layer（SSL）対応のサーバーを使用して認証する必要があるかどうか
ユーザー・リクエストを別のサーバーにリダイレクトして処理する場合は、チャレンジ・リダイレクトとして指定されているサーバーのURL
認証スキームでは、認証を適切に実行するために、別のURLへのリクエストのリダイレクションが必要な場合があります。たとえば、リソースに対する認証リクエストをHTTPで行うが、認証スキームでは認証をHTTPS（セキュアHTTP）で行う必要がある場合に、リダイレクションが使用されます。WebGateは、リダイレクトをユーザーのブラウザに送信し、認証スキームで定義されているURLをリクエストするように指示します。認証の完了後、WebGateは、リクエストされた元のリソースにブラウザを再びリダイレクトします。
また、リダイレクションは、マルチドメインのシングル・サインオン（SSO）の実行にも必要です。マルチドメインでのシングル・サインオンにチャレンジ・リダイレクトが使用される方法の詳細は、「マルチドメインのシングル・サインオン」を参照してください。
スキームを有効にするかどうか
このページには、認証スキームを有効に設定できるラジオ・ボタンがあります。スキームの有効化および無効化の詳細は、「認証スキームの有効化および無効化」を参照してください。
アクセス・サーバーのキャッシュを新しい情報、およびスキームへの変更に基づいて自動的に更新するかどうか
このページには、キャッシュを更新するかどうかを指定できるチェック・ボックスがあります。
アクセス・システムのランディング・ページで、「アクセス・システム・コンソール」リンクをクリックします。
「ポリシー・マネージャ」で作業している場合は、ページの最上部にある「アクセス・システム・コンソール」のリンクをクリックします。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックし、左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証スキームのリスト」ページで、「追加」をクリックします。
次のスクリーン・ショットに示すように、「一般」タブが選択された「新規認証スキームの定義」ページが表示されます。
「名前」フィールドで、認証スキームの名前を指定します。
各認証スキームには一意の名前を付ける必要があります。
「説明」フィールドで、スキームの簡単な説明を入力します。
たとえば、説明として、スキームの用途と動作を入力できます。
「レベル」フィールドで、スキームのセキュリティ・レベルに対応する整数を入力します。
「チャレンジ・メソッド」フィールドで、使用する認証スキームのチャレンジ・メソッドに対応するラジオ・ボタンをクリックします（各認証スキームは次のチャレンジ・メソッドのいずれか1つのみを持つことができます。「チャレンジ・メソッドの概要」を参照してください）。
チャレンジ・メソッドに「フォーム」、「Basic」または「外部」を選択した場合は、「チャレンジ・パラメータ」を指定します。
「Basic」チャレンジ・メソッドの場合は、エンドユーザーがリクエストしたリソースに対する自分のユーザー名およびパスワードを思い出すためのヒントとして使用する短いテキスト文字列を入力します。
LDAPディレクトリに対するテキスト文字列の例は次のとおりです。
realm:LDAP username + password
|
関連項目: 「Basic」チャレンジ・メソッドを使用していて、WebGateで認証エラーが発生したときにエラー・ページに機密情報が表示されないようにする場合は、「sensitivecredsチャレンジ・パラメータの概要」を参照してください。 |
「フォーム」チャレンジ・メソッドを選択した場合は、「チャレンジ・パラメータ」フィールドに次のパラメータを入力する必要があります。
エンドユーザーをSSL対応サーバーで認証するかどうかを設定します。
「はい」をクリックすると、リクエストは「チャレンジ・リダイレクト」フィールドで指定するHTTPSサーバーにルーティングされます。
「チャレンジ・リダイレクト」フィールドで、認証がリソースWebサーバーで行われない場合にこのリクエストのリダイレクト先とする別のサーバーのURLを入力します。
指定したプライマリ認証サーバーのホストURLを使用します。次に例を示します。
https://www.yourcompany.com
認証スキームの追加または変更時に「チャレンジ・リダイレクト」フィールドに入力するホスト名を、ホスト名識別子リストに追加する必要があります。詳細は、「ホスト識別子の追加」を参照してください。
「保存」（または「取消」）をクリックします。
「保存」をクリックすると、「認証スキームの詳細」表示ページが表示されます。このページには、新規認証スキーム用に入力した情報が表示されます。
「取消」をクリックすると、構成は保存されず、すべての認証スキームをリストしたページが再表示されます。
必要に応じて次のタスクに進み、認証スキームの定義を完了してください。
既存の認証スキームの内容は変更できます。新規認証スキームを定義した場合、それを変更するには、タブを選択し、表示されたページで情報を変更します。
10.4.1より前のバージョンのOracle Access Managerでは、スキームを変更する前に、そのスキームがアクティブないずれのポリシー・ドメインの認証ルールにも含まれていないことを確認し、スキームを無効にする必要がありました。これらのアクションは、現在では不要です。
認証スキームをルール内で使用する場合は、そのスキームを有効にしておく必要があります。無効なスキームをアクティブなドメインまたはポリシー内で使用しても、そのリソースは保護されません。
次の手順は、既存のスキームを変更する方法を示します。
|
注意: 既存の認証スキームは、旧リリースのアクセス・システムと互換性があります。ただし、旧リリースの認証スキームを変更した場合、そのスキームは6.5以降のバージョンのアクセス・サーバーでは作動しますが、それより前のアクセス・サーバーでは作動しません。 |
スキームがアクティブないずれのポリシー・ドメインの認証ルールにも含まれていないことを確認します。
詳細は、「認証スキームの有効化および無効化」を参照してください。
アクセス・システムのランディング・ページに移動し、「アクセス・システム・コンソール」リンクをクリックします。
「ポリシー・マネージャ」で作業している場合は、ページの最上部にある「アクセス・システム・コンソール」のリンクをクリックします。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
変更する認証スキームの名前をクリックします。
「認証スキームの詳細」ページが表示されます。このページから、「プラグイン」、「ステップ」、「認証フロー」など、他のタブを選択できます。
「変更」をクリックします。
次のスクリーン・ショットに示すように、「認証スキームを変更中」ページが表示されます。このページから、スキームの一般情報を変更できます。
Oracle Access and Identity Basic Over LDAP認証スキームを変更する場合は、「チャレンジ・パラメータ」フィールドにASCII文字を入力する必要があります。
スキームのその他の部分を変更するには、次のようにします。
その部分に対応するタブを選択します。
表示されたページで「変更」をクリックします。
そのページにある構成プロセスを行います。
「保存」をクリックします。
必要に応じて、スキームを有効にします。
認証スキームをルール内で使用する場合は、そのスキームを有効にしておく必要があります。無効なスキームをアクティブなドメインまたはポリシー内で使用しても、そのリソースは保護されません。
ディレクトリで複数の検索ベース（ディレクトリ・タイプに応じて非結合ドメインまたは複数レルムとも呼ばれる）を使用している場合は、異なる検索ベース（非結合ドメイン）に存在する同一ユーザーIDを持つユーザーを検索できるよう、認証スキームを構成する必要があります。
複数のディレクトリ検索ベース（すなわち、非結合ドメインまたはレルム）の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
複数の検索ベース（非結合ドメインまたはレルムとも呼ばれる）用に認証スキームを構成する手順
Active Directoryで、AD Forest用のOracle Access and Identity Basic Over LDAPのプラグインを認証スキームに追加します。
詳細は、「認証スキームへのプラグインの追加」を参照してください。
その他のプラットフォーム用には、次のようなカスタム認証スキームを作成します。
obMappingBase="%domain%",obMappingFilter="(&(& (objectclass=objectclassname)(loginattribute=%userid%))(|(! (obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))",obdomain="domain"
内容は次のとおりです。
objectclassnameは、Personオブジェクト・クラスの名前（例: gensiteorgperson）
loginattributeは、Personオブジェクト・クラスの属性の名前（例: genuserid）
%domain%および%userid%要素には、ユーザー・ドメインおよびユーザーIDが抽出されます。
次に例を示します。
credential_mapping obMappingBase="%domain%",obMappingFilter="(&(& (objectclass=gensiteorgperson)(genuserid=%userid%))(|(! (obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED)))",obdomain="domain"
このプラグインを変更します。
オブジェクト・クラスを実際のユーザー・オブジェクト・クラスに変更します。
genuseridを実際のユーザー・オブジェクト・クラスで構成されているログイン属性に変更します。
このスキームを使用した認証が成功したときに行う認証アクションを定義する際、次の値を設定する必要があります。
タイプ: HEADERVAR
|
注意: これは、デフォルトのIdentityドメインとアクセス・ポリシー・ドメインの両方に行う必要があります。 |
名前: HTTP_OBLIX_UID
戻り属性: obuniqueid
詳細は、「認証アクションの設定」を参照してください。
|
注意: これは、デフォルトのIdentityドメインとアクセス・ポリシー・ドメインの両方に行う必要があります。 |
さらに、次の構成ファイルの変更を行う必要があります。
次のパスでglobalparams.xmlファイルを検索します。
PolicyManager_install_dir/access/oblix/apps/common/bin/globalparams.xml
同じ変更を次のアイデンティティ・サーバー・ファイルでも行います。
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
作成した認証スキームは、有効にしないかぎり無効です。認証スキームは、その構成の終了後にのみ有効にすることをお薦めします。
スキームを無効にする前に、そのスキームがアクティブないずれかのポリシー・ドメインの認証ルールで使用されていないかどうかを確認してください。スキームが無効にされると、次のような状況が発生するためです。
スキームが認証ルール用に利用できなくなります。
そのスキームでそれまで保護されていたリソースが、そのリソースへのアクセスをリクエストするユーザーからアクセスできなくなります。
無効にされた認証スキームを含んだ認証ルールで保護されているリソースへのアクセスが試行されると、次のエラー・メッセージが報告されます。
The authentication scheme SchemeID is invalid or has been disabled
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
「認証スキームのリスト」ページで、有効または無効にするスキームをクリックします。
「認証スキームの詳細」ページが表示されます。
「変更」をクリックします。
「認証スキームを変更中」ページが次のように表示されます。
該当するラジオ・ボタンを選択して、認証スキームを有効または無効にします。
「保存」をクリックします。
アクセス・システムでは、ObSSOCookieという暗号化Cookieを使用してシングル・サインオンを実装します。詳細は、「シングル・サインオンの構成」を参照してください。
チャレンジ・パラメータを指定して、ObSSOCookieがSSL接続を介してのみ送信され、CookieがセキュアでないWebサーバーに返信されないようにできます。
認証スキームを作成します。
詳細は、「認証スキームの定義および管理」を参照してください。
「チャレンジ・パラメータ」フィールドで、フィールドをもう1つ追加し、次のとおりに指定してObSSOCookieを保護します。
ssoCookie:httponly
|
注意: 「チャレンジ・パラメータ」では大/小文字を区別します。ssoCookieのCおよびSecureのSは大文字で入力してください。 |
「SSL必須」フィールドで「はい」をクリックし、エンドユーザーがSSL対応サーバーで認証されるようにします。
ユーザーがシングル・セッションだけでなく特定の期間ログインしていられるように認証スキームを構成できます。これを行うには、チャレンジ・パラメータssoCookie:max-ageを認証スキームに追加します。これにより、単一セッションでのみ存続するCookieではなく、永続Cookieが、いくつかのブラウザに生成されます。永続Cookie機能は、Internet ExplorerおよびMozillaブラウザで使用できます。
「新規認証スキームの定義」の説明に従って、認証スキームを定義します。
このスキームのチャレンジ・パラメータに次の内容を追加します。
ssoCookie:max-age=time-in seconds
ここで、time-in-secondsは、Cookieが期限切れになるまでの時間間隔を表します。たとえば、ssoCookie:max-age=2592000の設定では、Cookieは30日（2592000秒）で期限切れになるように設定されます。
Cookieは、アプリケーションにより、HTTPリクエストまたはレスポンスに設定できるテキスト文字列です。Webサイトでは、Cookieを使用して、ユーザーが以前に訪れたページなどのユーザーに関する情報を取得できます。認証スキームのcredsチャレンジ・パラメータに、Cookie名を含めることができます。ユーザーがこのタイプのスキームによって保護されたリソースへのアクセスを試行し、ログインが必要な場合、WebGateはCookieの値を取得し（Cookieが存在する場合）、他の資格証明とともにアクセス・サーバーにCookieの値を送信します。認証プラグインでは、他の資格証明を抽出する場合と同じ方法を使用してCookieの値を取得できます。
ブラウザCookieを資格証明として認証スキームに含める手順
アクセス・システムのランディング・ページで、「アクセス・システム・コンソール」リンクをクリックします。
「ポリシー・マネージャ」で作業している場合は、ページの最上部にある「アクセス・システム・コンソール」のリンクをクリックします。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックし、左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
認証スキームを作成するには、「認証スキームのリスト」ページで「追加」をクリックします。
Basic Over LDAPなどの既存認証スキームを変更することもできます。
認証スキームに、Cookieの名前をチャレンジ・パラメータとして含めます。次に例を示します。
creds:MyDomain
認証スキームのOracleに付属のプラグインまたはカスタムのプラグインで、Cookieの資格証明の値を使用します。
たとえば、credential_mappingプラグインでは、次のようなObMappingFilterパラメータを使用して、Cookieの資格証明の値をユーザー属性と比較できます。
obMappingBase="o=Company,c=US",obMappingFilter="(&(objectclass= gensiteorgperson)(uid=%userid%)(domain=%MyDomain%))"
この例では、MyDomainというCookieの値をdomainというユーザー属性と比較しています。認証は、ユーザーのCookieの値が適切な場合にのみ成功します。
認証プラグインは、ユーザー認証プロセスに関与する実行可能な共有ライブラリです。プラグインは、認証スキームのエンジンです。プラグインにより、チャレンジ・メソッドの実装、ディレクトリ内のユーザー・プロファイルのエントリへのユーザー資格証明のマップ、ユーザー資格証明の処理、認証プロセスに関連するカスタム・タスクの実行などが行われます。
認証スキームのステップには、1つ以上のプラグインを組み入れます。プラグインは、ステップに追加する前に、認証スキームに追加する必要があります。認証スキームには、そのステップで使用されるすべてのプラグインを追加する必要があります。
この項の残りの内容は次のとおりです。
アクセス・システムには、アクセス・システムでデフォルトでサポートされるチャレンジ・メソッドを実装するためのプラグインと、資格証明マッピング・プラグインが付属しています。各認証スキームには、ユーザー資格証明をディレクトリ内のユーザー・プロファイルと照合するための資格証明マッピング・プラグインを組み入れる必要があります。この目的には、アクセス・システムに付属のプラグインを使用することも、あるいはそれを、同じ動作を実装するカスタム・プラグインに置き換えることもできます。これらのプラグインとそのパラメータの詳細は、「認証チャレンジ・メソッド用のアクセス・システム・プラグイン」を参照してください。
プラグインは、ステップ内に組み入れます。アクセス・システムに付属のプラグインの実行が失敗すると、そのプラグインが含まれるステップは失敗します。ステップとプラグインの詳細は、「認証ステップの概要」を参照してください。
認証プロセスに関する目的に合ったカスタム・プラグインを作成できます。たとえば、複数ディレクトリの検索または単一ディレクトリの複数ブランチの検索に使用するカスタム・プラグインを作成できます。また、ある部門のユーザー・プロファイルをディレクトリの特定ブランチに格納し、別の部門のユーザー・プロファイルを同じディレクトリの別のブランチに格納している場合は、特定の条件に基づいて各ブランチを連続して検索することもできます。
アクセス・システムでは、C、C++、Visual Basicなど、Microsoft .NET Frameworkでサポートされているすべての言語での認証プラグインの作成をサポートしています。
カスタム・プラグインの実行が失敗した場合、結果は、このプラグインにより戻されたリターン・コードか、認証スキームの認証フローに従って次に実行されるステップに依存します。
認証に使用するプラグインの作成方法の詳細は、『Oracle Access Manager開発者ガイド』の認証プラグインAPIに関する章を参照してください。
認証フローの詳細は、「認証フローの構成」を参照してください。
作成されるカスタム・プラグインは次の4つのステータス・コードのいずれかを戻すものと、アクセス・サーバーでは想定しています。
ObAnPluginStatusContinue
ObAnPluginStatusAllowed
ObAnPluginStatusDenied
ObAnPluginStatusAbort
これらのリターン・コードの意味と、アクセス・サーバーがこれらのコードを解釈して応答する方法の詳細は、『Oracle Access Manager開発者ガイド』の認証プラグインAPIに関する章を参照してください。
カスタム・プラグインは、任意の数の認証スキームで使用できます。プラグインの名前は、認証スキーム間で一意となるように変更する必要があります。プラグインを認証スキームに追加すると、アクセス・サーバーによってそのプラグインにIDが透過的に割り当てられます。この番号は、アクセス・システムの内部で管理されます。番号の変更や削除はできません。
アクセス・システムではIDを使用してプラグインを追跡するため、プラグインの実行順序はその配置順のみには依存せず、単一のプラグインを次のように再利用できます。
1つのステップ内で他のプラグインと組み合せて使用できます。
1つのステップ内で複数回使用できます。
1つのステップには、様々なパラメータを指定した、プラグインの複数のインスタンスを含めることができます。
同じ認証スキームの複数のステップに使用できます。
認証スキームのセキュリティ・レベルを変更するカスタム・プラグインを作成できます。特定の条件に基づいて認証スキームのセキュリティ・レベルを上げることが必要となる場合があります。認証スキームのセキュリティ・レベルを、ユーザーのログイン元のアプリケーションによって変更する場合などです。たとえば、Active Directoryとリバース・プロキシがユーザーのログイン元として使用可能な場合、Active Directoryからログインしたユーザーにはある認証セキュリティ・レベルを使用し、リバース・プロキシからログインしたユーザーには別のセキュリティ・レベルを使用するように設定できます。
コードにより、ユーザーのログイン元を判別し、それに応じて認証スキームのセキュリティ・レベルを設定できます。また、アクセス・サーバーにより管理されているObAuthentSchemeLevel変数の現在の値を、スキームの資格証明リストでチェックできます。プラグインでは、アプリケーションからのログインに対して設定した要件に応じたセキュリティ・レベルにこの変数の値を設定することで、セキュリティ・レベルを変更できます。つまり、セキュリティ・レベルを設定するには、ObAuthentSchemeLevel変数の値を変更します。この値を変更しない場合、アクセス・サーバーでは、認証スキームに設定済のセキュリティ・レベルをユーザー・インタフェースで使用します。
次のコードをプラグインで使用すると、資格証明リスト・ファイルを開き、ObAuthentSchemeLevel変数値をチェックし、この値をアプリケーション用のセキュリティ・レベルに設定できます。
schemeLevel = pFnBlock->GetCredFn(pInfo->Creds,
"ObAuthentSchemeLevel");
if (schemeLevel ! = NULL) {
schemeLevelAsInt = atoi(schemeLevel);
schemeLevelAsInt +=10
iota(schemeLevelAsInt, buff, 10);
pFnBlock->SetCredFn(pInfo->Creds,
"ObAuthentSchemeLevel", buff);
表5-1に、事前定義チャレンジ・メソッドと、これらのメソッドをサポートするプラグインを示します。複数のプラグインを使用するチャレンジ・メソッドには、プラグインの実行順序が示されています。
これらのプラグインは、認証スキームの1つ以上のステップで、表5-1に示された順序で使用できます。Oracleに付属のプラグインのかわりに、カスタム・プラグインと組み合せて使用できます。または、認証スキームに必要なプラグインをすべて独自のカスタム・プラグインで実装することもできます。
表5-1 アクセス・システムに事前定義されているチャレンジ・メソッドおよびプラグイン
| チャレンジ・メソッド | プラグインおよび実行順序 |
|---|---|
|
なし |
|
|
Basic |
|
|
クライアント証明書（X509証明書） |
|
|
アクセス・システムには、次のプラグインが用意されています。
credential_mapping: このプラグインは、ユーザーIDをディレクトリ内の有効な識別名（DN）にマップします。
ユーザーIDのマップ先の属性を構成できます。最も一般的なマップ先属性はuidです。obMappingFilterパラメータを変更して、uid以外のプロファイル属性にユーザーIDをマップすることもできます。
資格証明マッピング・プラグインは、すべての認証スキームに必須です。この目的には、LDAPディレクトリ・サーバー用にアクセス・システムに用意されているcredential_mappingプラグインを使用するか、独自のプラグインを使用できます。詳細は、「資格証明マッピング・プラグイン」を参照してください。
validate_password: このプラグインは、ユーザーのパスワードをLDAPデータ・ソースと照合するために使用されます。これは、「フォーム」および「Basic」チャレンジ・メソッドで使用できます。詳細は、「パスワード検証プラグイン」を参照してください。
selection_filter: このプラグインは、認証の資格証明をさらにいくつかの基準で検証します。これは、ユーザーが提示した資格証明を使用し、バックエンドのデータ・ソースは使用しません。このプラグインは、すべてのチャレンジ・メソッドで使用できます。
cert_decode: このプラグインは、証明書を検証し、データ・ソースは使用しません。これは、「クライアント証明書（Cert）」チャレンジ・メソッドで使用できます。詳細は、「証明書デコード・プラグイン」を参照してください。
NT/Win2000: このプラグインは、Microsoft Windows 2000システム用の「フォーム」および「Basic」チャレンジ・メソッドで使用できます。詳細は、「WindowsおよびSecurID用のプラグイン」を参照してください。
SecurID: SecurID認証スキームには2つのプラグイン（authn_securidとcredential_mapping）が必要です。各プラグインは、ディレクトリ・サーバーで情報を探す方法を定義します。これは、SecurID用の「フォーム」チャレンジ・メソッドで使用できます。詳細は、『Oracle Access Manager統合ガイド』を参照してください。
この項で説明されているアクセス・システム付属のプラグインごとに、プラグイン、パラメータおよび使用方法に関する情報が記載されている表があります。
次の説明は、これらの表に当てはまります。
すべてのプラグインのパラメータは大/小文字を区別します。パラメータは、表に記載されているとおりに入力する必要があります。
表で必須と記載されていないパラメータは、オプションです。
|
注意: チャレンジ・メソッドとして「なし」を選択した場合も、すべての認証スキームでcredential_mappingプラグインを使用することをお薦めします。ただし、これは必須ではありません。必須のパラメータについては、「資格証明マッピング・プラグイン」を参照してください。 |
カスタムの認証スキームでは、credential_mappingプラグインに実装されている機能を用意する必要があります。また、ユーザーの資格証明をLDAPディレクトリ・サーバー内の情報にマップする必要もあります。
アクセス・システム付属のcredential_mappingプラグインを使用しない場合は、作成するカスタム・プラグインで同じタスクを実行する必要があるためです。表5-2に、資格証明マッピング・プラグインで使用するパラメータを示します。obMappingBaseおよびobMappingFilterのパラメータ値を使用して、抽出されたユーザーの資格証明をディレクトリ内の識別名（DN）にマップします。この表の後に詳細情報があります。
表5-2 資格証明マッピングのパラメータ
独自のプラグインを用意する場合、資格証明マッピングに不可欠のためサポートする必要があるパラメータが2つあります。どちらも必須のパラメータです。
obMappingBase: ユーザー資格証明の検索開始点となるディレクトリ内の検索ベース
たとえば、デフォルトの匿名認証スキームがプラグインで使用する検索ベースは次のとおりです。
obMappingBase="o=company,c=us"
たとえば、デフォルトのBasic Over LDAP認証スキームがプラグインで使用する検索基準は次のとおりです。
obMappingFilter="(&(objectclass=inetorgperson)(uid=%userid%))"
ここで、%userid%は、ユーザーの資格証明（たとえば、フォーム・ベース認証の場合はログイン・フォームのフィールド）から抽出されます。
Oracle Access Managerの「クライアント証明書」認証スキーム内にあるcredential_mappingプラグインは、Webブラウザにインストールされているユーザー証明書と一致している必要があります。たとえば、ユーザー証明書にcnおよびmailフィールドがある場合、次の例が「クライアント証明書」認証スキームの有効な資格証明マッピングのパラメータになります。
CN
obMappingBase="dc=us,dc=oracle,dc=com",obMappingFilter="(&(objectclass=inetorgpers on)(cn=%certSubject.CN%))"
obMappingBase="dc=us,dc=oracle,dc=com",obMappingFilter="(&(objectclass=inetorgpers on)(mail=%certSubject.E%))"
資格証明マッピング・プラグインに使用されるobMappingFilterパラメータにobuseraccountcontrolパラメータを追加できます。この追加により、次のように2つのカテゴリのユーザーをフィルタ処理できます。
ディレクトリ・サーバーに追加されているがアイデンティティ・システムではアクティブ化されていないユーザー。
アイデンティティ・システムでは非アクティブであるがディレクトリ・サーバーには残っているユーザー。
obuseraccountcontrolの条件の例を次に示します。前述の2つのカテゴリのユーザーをフィルタ処理しています。
(|(!(obuseraccountcontrol=*)) (obuseraccountcontrol=ACTIVATED))
obuseraccountcontrolがACTIVATEDまたは値なしに該当することで、非アクティブなユーザーがフィルタ処理されます。obuseraccountcontrolパラメータは、obMappingFilterパラメータと一緒に使用する必要があります。obMappingFilterなしでは指定できません。
validate_passwordプラグインは、ユーザーのパスワードを、認証スキームの指定ディレクトリ・サーバーと照合します。validate_passwordには、アクセス・サーバーにより、成功したcredential_mappingプラグインの実行で照合先とされたものと同じディレクトリ・サーバーが使用されます。
validate_passwordプラグインの設定例は次のとおりです。
validate_password obCredentialPassword="password", obAnonUser="cn=anonymous, o=Company, c=US"
表5-3で、パスワード検証プラグインを説明します。
| 名前 | validate_password |
|---|---|
|
目的 |
ユーザーが提供したパスワードをディレクトリ内のユーザーのパスワードと照合すること。 |
|
結果 |
ユーザーが入力したパスワードがそのユーザーのディレクトリ・エントリ内のパスワードに一致した場合、認証が続行されます。一致しない場合、プラグインは失敗します。 |
表5-4で、パスワード検証プラグインのパラメータを説明します。
表5-4 パスワード検証プラグイン
証明書デコード・プラグインは、証明書のコンポーネントであるサブジェクトと発行者の識別名（DN）を抽出します。プラグインにより、各コンポーネントごとに、接頭辞がcertSubjectまたはcertIssuerの資格証明が挿入されます。たとえば、証明書のサブジェクト名がgivenName=somenameの場合、プラグインによって資格証明certSubject.givenName=somenameが資格証明リストに追加されます。
表5-5で、証明書デコード・プラグインについて説明します。
表5-5 証明書デコード・プラグイン
| 名前 | cert_decode |
|---|---|
|
目的 |
証明書をデコードし、証明書の要素であるサブジェクトと発行者のDNを抽出すること。 このプラグインは、「X509証明書」チャレンジ・メソッドで使用できます。 |
|
結果 |
デコードが成功すると、証明書の要素であるサブジェクトと発行者のDNが資格証明のリストに追加されます。 これ以外の場合は、認証が失敗します。 |
|
パラメータ |
なし |
証明書がブラウザに格納されている場合、証明書の詳細を表示できます。詳細は、「証明書の詳細を表示する手順」を参照してください。
次の表に、アクセス・サーバーでサポートされている属性のOIDと、その属性の取得に使用される接尾辞を示します。
表5-6 アクセス・サーバーでサポートされているOID
| OID | コンポーネントの参照名 |
|---|---|
|
2.4.5.3 |
CN |
|
2.5.4.4 |
SN |
|
2.5.4.5 |
シリアル番号 |
|
2.5.4.6 |
C |
|
2.5.4.7 |
L |
|
2.5.4.8 |
ST |
|
2.5.4.9 |
番地 |
|
2.5.4.10 |
O |
|
2.5.4.11 |
OU |
|
2.5.4.12 |
役職 |
|
2.5.4.13 |
説明 |
|
2.5.4.14 |
検索ガイド |
|
2.5.4.15 |
ビジネス・カテゴリ |
|
2.5.4.16 |
住所 |
|
2.5.4.17 |
郵便番号 |
|
2.5.4.18 |
私書箱 |
|
2.5.4.19 |
オフィス名 |
|
2.5.4.20 |
電話番号 |
|
2.5.4.21 |
テレックス番号 |
|
2.5.4.22 |
テレックス端末の識別子 |
|
2.5.4.23 |
FAX番号 |
|
2.5.4.24 |
x121アドレス |
|
2.5.4.25 |
国際ISDN番号 |
|
2.5.4.26 |
本籍地 |
|
2.5.4.27 |
宛名 |
|
2.5.4.28 |
優先する配信方法 |
|
2.5.4.29 |
プレゼンテーション・アドレス |
|
2.5.4.30 |
サポートされているアプリケーション・コンテキスト |
|
2.5.4.31 |
メンバー |
|
2.5.4.32 |
所有者 |
|
2.5.4.33 |
ロールを担うユーザー |
|
2.5.4.34 |
参照 |
|
2.5.4.35 |
ユーザー・パスワード |
|
2.5.4.36 |
ユーザー証明書 |
|
2.5.4.37 |
CA証明書 |
|
2.5.4.38 |
認証局失効リスト |
|
2.5.4.39 |
証明書失効リスト |
|
2.5.4.40 |
相互証明書ペア |
|
2.5.4.41 |
名前 |
|
2.5.4.42 |
名 |
|
2.5.4.43 |
イニシャル |
|
2.5.4.44 |
生成修飾子 |
|
2.5.4.45 |
一意識別子 |
|
2.5.4.46 |
DN修飾子 |
|
2.5.4.47 |
拡張検索コード |
|
2.5.4.48 |
プロトコル情報 |
|
2.5.4.49 |
識別名 |
|
2.5.4.50 |
一意のメンバー |
|
2.5.4.51 |
建物の識別子 |
|
2.5.4.52 |
サポートされているアルゴリズム |
|
2.5.4.53 |
デルタ失効リスト |
|
2.5.4.58 |
証明書属性 |
|
2.5.4.65 |
偽名 |
|
1.2.840.113549.1.9.1 |
E |
|
0.9.2342.19200300.100.1.1 |
UID |
ほとんどの名前の間はスペースで区切ることに注意してください。これらの値を認証プラグインから取得するコードの抜粋を次に示します。
sn = pFnBlock->GetCredFn(pInfo->Creds, "cerSubject.Serial Number");
IEブラウザを開きます。
「ツール」メニューで、「インターネット オプション」をクリックします。
「コンテンツ」タブをクリックします。
「証明書」ボタンをクリックします。
自分の証明書をダブルクリックします。
「詳細設定」タブをクリックします。
該当する行をクリックします。
デフォルトでは、ディレクトリ・サーバーがユーザー・パスワードを検証します。ディレクトリ・サーバーによってパスワードの初回検証が行われた後は、アクセス・サーバーを使用してパスワードを検証するとパフォーマンスを向上できます。
このためには、次の操作が必要です。
validate_passwordプラグインを認証スキームに組み入れます。
プラグインのobCredValidationByASパラメータをtrueに設定します。
obCredValidationByASパラメータをtrueに設定すると、ユーザーのパスワードがディレクトリ・サーバーによって検証された後で、アクセス・サーバーによってそのパスワードのMD5ハッシュがキャッシュされます。
ユーザーが同じポリシー・ドメイン内のリソースへのアクセスを次回試みると、ユーザーのパスワードはキャッシュされたパスワードと比較されます。この2つが一致すると、入力したパスワードは検証済となり、ユーザーはリクエストしたリソースへのアクセス権を付与されます。
別のパラメータobPwdHashTTLには、アクセス・サーバーでパスワードを検証する時間間隔を設定します。デフォルト値は1800秒（30分）です。この値は変更できます。指定した時間間隔が経過すると、パスワード検証関数の制御はディレクトリ・サーバーに戻ります。
次に、アクセス・サーバーがパスワードを検証する時間間隔を100秒間にするようにこれらのパラメータを設定する例を示します。
validate_password obCredentialPassword="password",, obCredValidationByAS="true", obAnonUser="cn=anonymous, o=Company, c=US", obPwdHashTTL="100"
アクセス・システムには、ユーザー情報がWindowsまたはSecureIDセキュリティ製品に格納されているユーザーの認証に使用できるプラグインがあります。これらのプラグインは、アクセス・システムのインストール時に自動的にインストールされます。この項では、Windowsのプラグインについて説明します。
SecureIDプラグインの詳細は、『Oracle Access Manager開発者ガイド』を参照してください。
表5-7で、Windowsドメインに対する認証に使用されるWindowsプラグインについて説明します。
認証スキームのステップには、1つ以上のプラグインを組み入れます。ステップにプラグインを追加するには、その前に、認証スキームのいずれかのステップで使用されるプラグインをすべて認証スキームに追加する必要があります。
プラグインの定義の詳細は、「認証のプラグイン」を参照してください。
認証スキームにプラグインを初めて追加する際には、それらのプラグインがすべて含まれたデフォルトのステップがアクセス・システムにより作成されます。バージョン6.5より古いリリースのアクセス・システムの認証スキームを使用している場合は、アクセス・サーバーにより、そのスキームのプラグインがすべて含まれたデフォルトのステップがスキームに作成されます。
この項の残りの内容は次のとおりです。
認証スキームのプラグインは、いつでもリストできます。たとえば、プラグインを追加する前に、プラグインをリストしてスキームにすでに追加されているプラグインをリストできます。プラグインのリストには、認証スキームにすでに追加されているプラグインの名前とパラメータが表示されます。このリストには、アクセス・システムに付属のプラグイン、およびスキームにすでに追加されているカスタム・プラグインが含まれます。
|
注意: 1つのスキームには複数のcredential_mappingプラグインを組み入れることができます。 |
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証スキームのリスト」ページが表示されます。
「認証スキームのリスト」ページで、プラグインのリストを表示するスキームをクリックします。
「プラグイン」タブを選択します。
次の画面に示すように、「認証スキームのプラグイン」ページが表示されます。
プラグインを認証スキームに追加するときは、プラグインの名前とパラメータを指定します。プラグインの各インスタンスが異なるパラメータを持っている場合は、同じプラグインを認証スキームに複数回追加できます。一意のパラメータを持つプラグインの各インスタンスが、別個のプラグインとしてリストに表示されます。
プラグインを新規の認証スキームと既存の認証スキームのどちらに追加するにしても、プラグインを認証スキームに追加するには、次のタスクを使用します。
プラグインを使用する認証スキームをルール内で使用可能にするには、そのスキームを有効にする必要があります。無効なスキームをアクティブなドメインまたはポリシー内で使用しても、そのリソースは保護されません。
|
注意: 認証スキームに資格証明マッピング・プラグインを追加する場合は、credential_mappingプラグインがvalidate_passwordプラグインよりも前に配置されるようにします。認証スキームでは、パスワードを検証する前に、ログインIDの属性を検証するプラグインを処理する必要があります。 |
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
認証スキームのリンクをクリックします。
次のスクリーン・ショットに示すように、「認証スキームの詳細」ページが表示されます。
「変更」をクリックして「認証スキームを変更中」ページを表示します。
「プラグイン」タブを選択してこの認証スキームのプラグインを表示します。
「変更」をクリックします。
次のスクリーン・ショットに示すように、「認証スキームのプラグイン」ページが変更され、「追加」ボタン、「削除」ボタンおよび「キャッシュの更新」チェック・ボックスが表示されます。
「追加」をクリックします。
ページが変更され、追加するプラグインを選択および定義するためのオプション・リストとテキスト・ボックスが表示されます。アクセス・システムに付属のプラグインを選択するか、カスタム・プラグインの名前を「プラグイン名」ボックスに入力します。
資格証明マッピング・プラグインは、すべての認証スキームに必須です。ユーザーのパスワードを検証するには、最初にユーザーのログインIDを識別する必要があるため、資格証明マッピング・プラグインは、パスワード検証プラグインの前に実行する必要があります。アクセス・システムに付属のプラグインまたは同じ動作を実装するカスタム・プラグインを選択できます。
左側にある「プラグイン名」テキスト・ボックスからプラグインを選択するか、カスタム・プラグインの名前をテキスト・ボックスに入力します。このプラグインの詳細は、「資格証明マッピング・プラグイン」を参照してください。
各パラメータには、複数の値を指定できます。
複数のプラグインを追加するには、プラグインを1つ追加した後に、「追加」ボタンをクリックします。追加するプラグインごとにこの手順を繰り返します。
「保存」をクリックします。
プラグインは、認証スキームから削除できますが、その前に、そのプラグインを含んでいるスキームのステップ内から削除する必要があります。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
削除するプラグインが含まれる認証スキームの名前を選択します。
「新規認証スキームの定義」ページが表示されます。
「変更」をクリックします。
「プラグイン」タブを選択してこの認証スキームのプラグインを表示します。
「変更」をクリックします。
「認証スキームのプラグイン」ページが表示されます。
プラグインの名前の前にあるボックスをチェックして、削除するプラグインを選択します。複数のプラグインを削除するには、各プラグインを選択します。
リストの最下部にある「削除」ボタンをクリックし、選択したプラグインを認証スキームから削除します。
「保存」をクリックします。
ユーザーが認証ルールで保護されているリソースへのアクセスをリクエストすると、ルールの認証スキームによって認証の実行方法が決定されます。連鎖認証スキームの場合、このプロセスには、ユーザー資格証明の取得と、この資格証明のユーザー・プロファイルへのマッピングが含まれます。連鎖認証スキームを、これらの目的やその他の目的を行うように設計できます。たとえば、連鎖認証スキームでは、ユーザー・プロファイルの検索を1つのディレクトリに制限するのではなく、資格証明のマップ先とするユーザー・プロファイルの検索先とするディレクトリを、その情報が見つかるまで順次変えていくことができます。また、認証プロセスと間接的に関連する追加プロセスを含めることもできます。
手順の概要: 単純な連鎖認証スキーム
この項の残りの内容は次のとおりです。
ポリシー・ドメインの連鎖認証の設定に使用する手順の概要を次に示します。このプロセスでは、ポリシー・ドメインが存在し、使用するプラグインがすでに定義済であることを前提としています。
最後のステップ（認証ルールの作成）を除き、次のすべてのステップではアクセス・システム・コンソールを使用します。ポリシー・ドメインの認証ルールを作成するには、ポリシー・マネージャを使用します。
タスク概要: 連鎖認証スキームの定義および使用
「認証スキームの定義および管理」の説明に従って、連鎖認証スキームを定義します。
1つ以上のステップを含む認証スキームを作成するには、最初にスキームを定義する必要があります。この定義プロセスには、使用するチャレンジ・メソッドの指定が含まれます。
「プラグインの追加および管理」の説明に従って、連鎖認証スキームに、そのステップで使用するすべてのプラグインを追加します。
たとえば、次のようにします。
追加するプラグインをデフォルトのアクセス・システム付属プラグインの中から選択するか、既存のカスタム・プラグインを指定します。
プラグインをスキームに追加する際、各プラグインのパラメータを指定します。プラグインの複数のインスタンスをスキーマに追加できます。各インスタンスには、独自のパラメータのセットが含まれています。
スキームに追加するプラグインごとに、このプロセスを繰り返します。
|
注意: 認証スキームにプラグインを追加すると、ポリシー・マネージャによりデフォルトのステップが作成され、そのステップにプラグインが追加されます。 |
「ステップの構成および管理」の説明に従って、認証スキームのステップを追加します。
ステップを作成する前に、認証スキーム全体およびスキーム内の他のステップとの関係における、そのステップの目的を検討します。
スキームの各ステップの設計とスキームのフローの設計は、相互に依存するプロセスです。ステップを使用すると、各プラグインを複数のグループに分離できます。次に、プラグインのこれらのグループ、つまり、これらのグループのステップを様々な方法で接続し、いろいろな認証フローを作成できます。
ステップを認証スキームに追加する方法を次に示します。
ステップにわかりやすい名前を付けます。適切な名前を付けると、スキームのステップを並び替える場合に役立ちます。
プラグインをステップに追加します。
プラグインを実行予定順に並べます。
各プラグインの結果が次のステップの結果にどのように影響を与えるかを考慮に入れてください。
アクセス・システム
アクセス・システムに付属のいずれかのプラグインが失敗すると、そのステップは失敗します。
カスタム・プラグイン
詳細は、「プラグインのリターン・コード」を参照してください。
使用環境に応じて、認証プロセスの実行に必要な数のステップを追加します。
「認証フローの構成」の説明に従って、連鎖認証スキームの認証フローを作成します。
スキームの認証フローを設計します。スキームの認証フローを構成する前に、各ステップで実行するアクションを検討します。
スキームの認証フローを作成する方法を次に示します。
どのステップを最初に実行するかを決定します。それを開始ステップとしてマークします。
このステップからのリンクを構成します。
ステップのプラグインによりステップが失敗した場合に次に実行するステップを設定します。
ステップのプラグインによりステップが成功した場合に次に実行するステップを設定します。
「認証フローの構成」の説明に従って、連鎖認証スキームのフローを検証します。
フローの構成方法、つまり、フローを作成するステップ間の接続をテストし、サイクルがないことを確認します。
「認証フローの構成」の説明に従って、連鎖認証スキームのフローを必要に応じて修正します。
認証スキームの構成を確認した後で、「認証スキームの有効化および無効化」の説明に従って、認証スキームを有効にします。
「認証ルールの管理」の説明に従って、ポリシー・ドメインの連鎖認証スキームを含んだ認証ルールを作成します。
認証が認証ルールに基づいて失敗または成功した場合に取る各アクションを、認証ルールに指定します。詳細は、「認証アクションの管理」を参照してください。
ステップには、そのステップ内での配置順に実行されるプラグインのグループが含まれます。連鎖認証スキームのステップ同士を接続するには、現在のステップの結果に応じて次に実行するステップを指定します。現在のステップが成功するか失敗するかに応じて、異なるステップを実行できます。また、認証スキーム内で1つのステップを繰り返し使用してもかまいません。あるステップの後で認証プロセスを停止できます。
認証スキームには、実行順序が動的に決定される1つ以上のステップが含まれます。認証スキームのステップの実行は、開始ステップとして選択されているステップから始まります。開始ステップおよび後続の各ステップに対して次に実行されるステップは、前のステップの結果により決定されます。
認証スキームの各ステップには、1つ以上のプラグインを組み入れます。ステップ内のプラグインは、配置した順序で実行されます。
次をいつでも変更できます。
認証スキームのステップ間の接続
ステップのプラグイン間の順序
ステップ内のアクセス・システム付属プラグインのいずれかが失敗すると、アクセス・サーバーはそのステップを失敗したものとして処理し、そのステップの実行をその時点で停止します。
カスタム・プラグインの実行結果に基づいてそのプラグインを含むステップにアクセス・サーバーがどのように応答するかについては、「プラグインのリターン・コード」を参照してください。
図5-1に、サンプルの認証スキームのプロトタイプを示します。
表5-8に、ステップの構成要素をまとめます。
表5-8 ステップの構成要素
| 構成要素 | 概要 |
|---|---|
|
ステップ名 |
ステップは独立したエンティティです。各ステップには一意の名前を付ける必要があります。 |
|
プラグインは、認証スキームに機能を実装するものです。ステップには1つ以上のプラグインを組み入れることができますが、最低1つのプラグインは必要です。 プラグインに指定するパラメータは、プラグインをステップに追加するときではなく、スキームに追加するときに指定します。 |
|
|
ステップの数 |
認証スキームには任意の数のステップを組み入れることができますが、最低1つのステップは必要です。 |
|
ステップ間の接続 |
複数のステップを接続して、認証連鎖のフローを1つ以上形成できます。各ステップは独立しているため任意の順序で結合できます。 ステップ間の接続は、認証連鎖全体で可能な認証フロー（または実行フロー）を定義することで確立されます。詳細は、「認証フローの構成」を参照してください。 |
|
ステップの実行 |
ステップは、認証連鎖のフローに配置されている順序で実行されます。 ステップのプラグインは、ステップのプラグイン・リストに配置されている順序で実行されます。リストにおけるプラグインの順序は変更できます。 1つのステップのプラグインが実行された後は、認証フローにおいて次となっているステップのプラグインが実行されます。 |
多くの認証スキームは単純であり、単一のステップしか必要としません。このような場合、そのステップには、そのスキームの目的を果すために必要なすべてのプラグインを組み入れる必要があります。そのステップが認証スキームにおける唯一のステップであるため、認証スキームのフローは、そのステップ内のプラグインを実行することと等しくなります。
ポリシー・マネージャの認証機能を使用すると、ユーザー資格証明の取得、ディレクトリ・サーバー内のエントリへのその資格証明のマップ、ユーザーの認証などを行うために必要となるすべての機能を提供する単一ステップを作成できます。
単一ステップの認証スキームは簡単に作成および管理できるので、多くの場合、すべてのプラグインを単一ステップに組み入れることをお薦めします。たとえば、ステップ内のプラグインを連続して実行し、失敗した場合にも、どのプラグインが原因でステップが失敗したかは問題でない状況では、単一ステップの認証スキームが便利です。
複数ステップへの各プラグインの分離は、各プラグインを同時に実行する必要がある場合に必要になります。また、複数のプラグインを1つのステップに結合すると、そのステップを1つのスキーム内で複数回使用することが可能になります。このようなステップは、たとえば、あるステップが失敗した場合にそのステップの次に実行するステップとして構成することや、あるステップが成功した場合にそのステップの次に実行するステップとして構成することが可能です。
また、2つのプラグインが論理的にはペアになっていても、別個のステップへの分離が必要になる場合があります。このアプローチは、たとえば、2つのプラグインのどちらが原因で認証プロセスが失敗したかを把握する必要がある場合に選択できます。
密接に関連するプラグインを別個のステップに分離すると有効な場合は多数あります。その一例は、パスワード管理機能を使用する場合です。パスワード管理を使用してユーザー・アクセスを制御している組織があるとします。この組織では、パスワード・ポリシーに指定されている試行回数まで正しいパスワードを入力する機会を、ユーザーに提供しています。認証が失敗した場合、管理者はその原因を把握する必要があります。管理者は、次の2つのイベントを識別できる必要があります。
チェックしたディレクトリにユーザーのエントリがないために認証が失敗した場合
ユーザーが許可されている回数（3回）まで不正なパスワードを毎回入力したために認証が失敗した場合
たとえば、ある組織では、そのディレクトリ下の2つの異なる部分を使用して、人事管理部門とマーケティング部門のユーザー・プロファイル情報を格納しているとします。この組織では、そのディレクトリ下の2つのブランチでユーザー・プロファイル情報を検索して、ユーザーを認証することを計画しています。人事管理部門の情報を格納している検索ベースで検索を開始し、ユーザー・プロファイル情報がそこで見つからなかった場合は、マーケティング部門の検索ベースで検索を続行するという計画です。
検索ベースA
人事管理部門の全メンバーのエントリを格納しています。
例:
cn=Maurice Breton
cn=Alice Smith
検索ベースB
マーケティング部門の全メンバーのエントリを格納しています。
例:
cn=Sonal Kalra
cn=Robert Jang
この組織では、次の連鎖認証ステップを定義します。
ステップ1: 資格証明マッピング
成功: ステップ2を実行
失敗: ステップ3を実行
ステップ2: パスワード検証
成功: ステップ4を実行
失敗: 停止
パスワード検証プラグインでは、ステップ2が失敗するまでに、ユーザーが有効なパスワードの入力を3回まで試行できるようにします。この回数は、パスワード・ポリシー内の設定に基づきます。
ステップ3: カスタム・プラグインによる検索ベースBのチェック
成功: ステップ2を実行
失敗: 停止
ステップ4: カスタム・プラグインによる追加処理
成功: 停止して結果を戻す
失敗: 停止して結果を戻す
Sonal Kalraが、この認証スキームで保護されているリソースへのアクセスをリクエストします。次に、自分のユーザー名を入力します。この後のプロセスは次のとおりです。
手順の概要: ユーザーはアクセスをリクエストし、ユーザーIDを入力します。
アクセス・サーバーによって検索ベースAでSonal Kalraのエントリが検索されます。
エントリがありません。
ステップ1の評価: 失敗。失敗したので、ステップ3に進みます。
アクセス・サーバーによって検索ベースBでSonal Kalraのエントリが検索されます。
cn=Sonal Kalraのエントリが見つかります。
ステップ3の評価: 成功。成功したので、ステップ2に進みます。
Sonal Kalraは、パスワードの入力を求められます。
最初は不正なパスワードを入力します。ステップ2のパスワード検証により、失敗が戻されるまでに、パスワードの入力を3回求められます。
2回目の入力要求で、適切なパスワードを入力します。
ステップ2の評価: 成功したので、ステップ4に進みます。
追加処理が行われ、正常終了します（ステップ4: 成功: 停止して結果を戻す）。
Sonal Kalraが3回とも不正なパスワードを入力すると、ステップ2のパスワード検証により失敗の結果が戻され、認証プロセスは停止します。委任アクセス管理者は、認証プロセスが失敗した原因が、Sonal Kalraのユーザー・エントリが見つからなかったからではなく、不正なパスワードが3回入力されたからであることを把握できます。
デフォルトのステップの概要
認証スキームにプラグインを初めて追加する際には、それらのプラグインがすべて含まれたデフォルトのステップがポリシー・マネージャにより定義されます。デフォルトのステップを使用する場合でも、それを変更してもかまいません。あるいは、1つ以上のステップをスキームに追加した場合には、その後でデフォルトのステップを削除することが可能です。認証スキームには少なくとも1つのステップを組み入れる必要があります。
認証スキームを定義してこれにプラグインを追加した後は、そのスキームのステップを構成できます。認証スキームのステップはいつでも変更できますが、事前に、スキームがアクティブないずれのポリシー・ドメインでも使用されていないことを確認する必要があります。ステップへのプラグインの追加、ステップからのプラグインの削除、またはステップの削除が可能です。
この項の残りの内容は次のとおりです。
認証スキームに現在構成されているステップのリストを表示できます。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
「認証管理: すべての認証スキームをリスト」ページで、表示対象のステップが含まれる認証スキームの名前をクリックします。
「認証スキームの詳細」ページが表示されます。デフォルトでは、「一般」ページが表示されます。
「ステップ」タブを選択します。
次のスクリーン・ショットに示すように、「認証スキームのステップ」ページが表示されます。このページには、スキームに構成されているすべてのステップの名前が表示されます。各ステップの名前はリンクであり、クリックするとそのステップの詳細を表示できます。
認証スキームの作成中であり、そのスキームにステップをまだ1つも追加していないかまたは1つしか追加していない場合は、「デフォルトのステップ」というステップのみがこのページに表示されます。詳細は、「デフォルトのステップの概要」を参照してください。
認証スキームのステップの現在の構成の詳細は、そのステップの作成後にいつでも表示できます。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
構成詳細の表示対象とするステップが含まれる認証スキームの名前をクリックします。
「認証スキームの詳細」ページが表示されます。デフォルトでは、「一般」ページが表示されます。
「ステップ」タブを選択します。
「認証スキームのステップ」ページが表示されます。このページには、スキームに構成されているすべてのステップの名前が表示されます。
構成を表示するステップの名前をクリックします。
次のスクリーン・ショットに示すように、「認証スキームのステップ」ページが再表示され、今回は選択したステップの詳細が表示されます。
ステップをスキームに追加するには、ステップに名前を付け、機能を実装するプラグインをそのステップに追加します。複数のプラグインを含むステップの場合、ステップ内へのプラグインの配置順序によってプラグイン間の実行順序が決定されます。最初のプラグイン、つまりリストの最上位にあるプラグインが最初に実行されます。
ステップにプラグインを追加すると、そのプラグインは、アクティブ・プラグインのリストの最下位に配置されます。ステップにおけるプラグインの順序は変更できます。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
「認証管理: すべての認証スキームをリスト」ページで、認証スキームの名前をクリックします。
「認証スキームの詳細」ページが表示されます。デフォルトでは、「一般」ページが表示されます。
「ステップ」タブを選択します。
「認証スキームのステップ」ページが表示されます。
認証スキームの作成中であり、そのスキームにステップをまだ1つも追加していない場合は、「デフォルトのステップ」というステップのみがこのページに表示されます。詳細は、「デフォルトのステップの概要」を参照してください。
「追加」をクリックします。
次のスクリーン・ショットに示すように、「認証ステップの変更」ページが表示されます。このページは、タイトルに「変更」とありますが、既存ステップの内容の変更だけでなく、ステップの追加にも使用されます。
「ステップ名」テキスト・ボックスにステップの一意の名前を入力します。
選択可能なプラグインのリストから、ステップに追加するプラグインを選択し、「追加」をクリックします。
プラグインの名前が「アクティブ・プラグイン」スクロール・ボックスに表示されます。
ステップに追加するプラグインごとに、ステップ7を繰り返します。
ステップにおけるプラグインの順序を変更するには、アクティブ・プラグインのリストでプラグインを選択し、「上へ」ボタンまたは「下へ」ボタンをクリックして、プラグインをリスト内で上または下に移動します。
「保存」をクリックします。
既存の認証ステップは変更できます。たとえば、ステップのプラグインを別のプラグインに変更してアップグレードすることや、新しいプラグインをステップに追加してステップの機能を拡張または変更することが可能です。不用になったプラグインを削除することもできます。
既存のステップにおけるプラグインの追加、削除または順序変更の手順
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
変更するステップが含まれる認証スキームの名前をクリックします。
そのスキームに対する「認証スキームの詳細」ページが表示されます。
「ステップ」タブを選択します。
「認証スキームのステップ」ページが表示されます。
変更するステップの名前をクリックします。
「認証スキームのステップ」ページにそのステップのプラグインおよびパラメータが表示されます。
「変更」をクリックします。
「認証ステップの変更」ページが表示されます。
プラグインを「アクティブ・プラグイン」リストに追加する場合は、プラグインを「使用可能なプラグイン」リストから選択して「追加」をクリックします。
プラグインを「アクティブ・プラグイン」リストから削除する場合は、プラグインをそのリストから選択して「削除」をクリックします。
「アクティブ・プラグイン」リストにおけるプラグインの順序を変更する場合は、移動するプラグインを選択して「上へ」ボタンまたは「下へ」ボタンをクリックし、プラグインをリスト内で上または下に移動します。
変更を確認した後で、「保存」をクリックしてステップを保存します。
1つ以上のステップをスキームから削除できます。ただし、認証スキームには少なくとも1つのステップを残す必要があります。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
削除するステップが含まれる認証スキームの名前をクリックします。
そのスキームに対する「認証スキームの詳細」ページが表示されます。
「ステップ」タブを選択します。
「認証スキームのステップ」ページが表示されます。
削除するステップを選択します。
複数のステップを削除する場合は、削除する各ステップに対応するチェック・ボックスを選択します。
「削除」をクリックします。
認証フローとは、認証スキームのすべてのステップを実行していく際の実行経路です。単一ステップのスキームでは、認証フローは、そのステップ内のプラグインの実行から構成されます。
認証フローは、次のいずれの種類の認証スキームにもあります。
単一ステップの認証スキーム
単一ステップしかない認証スキームの認証フローは、そのステップのすべてのプラグインを、ステップ内での配置順に実行していくフローとなります。単一ステップのスキームの詳細は、「単一ステップの認証スキームの概要」を参照してください。
連鎖認証スキーム
連鎖認証スキームでは、それに含まれる認証フローごとに、そのフローに含まれるステップ別に、プラグインが順次実行されていきます。連鎖認証スキームには、1つ以上のフローを含めることができます。認証スキームのフロー内の各ステップの結果に応じて、あらゆるパターンの認証フローを作成できるように、ステップ間の実行順序を変更することができます。
認証スキームの各ステップに対し、現在のステップの結果に基づいて次に実行するステップを構成します。現在のステップが失敗すると、そのステップの失敗という結果に対して構成済である次のステップが実行されます。現在のステップが成功すると、そのステップの成功という結果に対して構成済である次のステップが実行されます。認証フローの各ステップのプラグインは、ステップ内でのそれらプラグインの配置順に実行されます。
次の方法で認証スキームのステップを構成することで、考えられるかぎりの様々なフローが生成されます。
あるステップを連鎖認証スキームの開始ステップとしてマークします。
特定の連鎖認証スキームで発生する可能性のあるすべてのフローは、この同じステップから開始されます。すべての認証スキームに対して開始ステップとして指定できるのは、1つのステップのみです。
現在のステップが失敗または成功した場合に次に実行するステップを指定します。
このメカニズムにより、連鎖に含まれる複数のフローを構成できます。各フローは、現在のステップの結果によって決定されていきます。
停止終了記号を使用します。
停止終了記号は、連鎖の任意のステップの後に配置できます。ステップが失敗または成功した場合に実行を停止するように指定できます。それぞれの場合に対し、ステップの失敗条件または成功条件を停止終了記号に設定します。ステップの結果の両方の条件を停止終了記号に設定すると、ステップの後に実行を確実に停止できます。
発生する可能性のあるフローに対応する複数の条件で終了できるよう、連鎖認証スキームのフローの実行を設定できます。停止終了記号により、フローが終了し、認証連鎖の後続ステップは実行されなくなります。
この項の残りの内容は次のとおりです。
ある会社の管理者が、認証に使用されるプラグインの実行順序の管理を容易にするために、プラグインをステップに編成しようとしているとします。また、プラグインの実行結果によって次に実行するプラグインを決定しようともしています。今回プラグインをステップに分離することが必要となったのは、プラグインを順序どおりには実行しないからです。この会社では、表5-9に記載されている4つのプラグインを認証プロセスに使用しています。
| プラグイン | 説明 |
|---|---|
|
プラグイン1: credential_mapping |
アクセス・システムに付属の資格証明マッピング・プラグイン |
|
プラグイン2: validate_password |
アクセス・システムに付属のパスワード検証プラグイン |
|
プラグイン3: custom_pluginA |
カスタム・プラグインA |
|
プラグイン4: custom_pluginB |
カスタム・プラグインB |
この管理者は、各認証プラグインをステップとしてまとめ、このステップの結果を使用して、次の認証フローを定義することに決定しました。
プラグイン1が成功した場合（資格証明がユーザー・エントリにマップされた場合）
プラグイン2を実行（ユーザーのパスワードを検証）
プラグイン1と2が成功した場合（ユーザーの資格証明がマップされ、ユーザーのパスワードが有効な場合）
プラグイン4（カスタム・プラグインB）を実行
プラグイン1または2が失敗した場合（ユーザーの資格証明がエントリにマップできないか、またはユーザーのパスワードが無効な場合）
プラグイン3（カスタム・プラグインA）を実行
プラグイン3（カスタム・プラグインB）が成功した場合
プラグイン4（カスタム・プラグインB）を実行
この管理者は、表5-10に記載されている3つのステップを作成します。
表5-10 認証フローのステップの例
| ステップ | 使用するプラグイン | ステップの結果 |
|---|---|---|
|
ステップ1 |
プラグイン1およびプラグイン2 |
プラグイン1とプラグイン2の両方が成功した場合、成功。 どちらかのプラグインが失敗した場合、失敗。 |
|
ステップ2 |
プラグイン3 |
プラグイン3が成功した場合、成功。 プラグイン3が失敗した場合、失敗。 |
|
ステップ3 |
プラグイン4 |
プラグイン4が成功した場合、成功。 プラグイン4が失敗した場合、失敗。 |
表5-9のプラグインを表5-10のステップと組み合せ、目的の認証フローを作成します。表5-11に、認証スキームのステップと、そのステップが成功または失敗した場合に次に実行するステップを示します。
図5-2は、認証フローのこの表をダイアグラムで示したものです。
認証スキームの認証フローを構成した後は、「認証フロー」タブを選択することで構成をいつでも確認できます。「認証スキームのフロー」ページに、現在の構成が表示されます。ステップを認証スキームに追加し終わると、ポリシー・マネージャによりデフォルトで、停止終了記号が各ステップの「成功時の次のステップ」および「失敗時の次のステップ」結果条件に割り当てられます。「認証スキームのフロー」ページに、このデフォルトの構成が、変更されるまで表示されます。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
認証フローを表示する認証スキームの名前を選択します。
その認証スキームに対する「認証スキームの詳細」ページが表示されます。
「認証フロー」タブを選択します。
「認証スキームのフロー」ページが表示されます。
ステップを認証スキームに追加した後は、すべてのステップを実行していく際に取る可能性のある実行フローを構成できます。「認証スキームのフロー」ページを使用して、各ステップに対して「成功時の次のステップ」および「失敗時の次のステップ」結果条件を構成します。
認証スキームのフローは、このページでいつでも変更できます。連鎖内のステップ間の接続を変更することで、サイクルを修正したりフローをリダイレクトできます。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。
左側のナビゲーション・ペインにある「認証管理」リンクをクリックします。
「認証管理: すべての認証スキームをリスト」ページが表示されます。
認証フローを構成する認証スキームの名前を選択します。
その認証スキームに対する「認証スキームの詳細」ページが表示されます。
「認証フロー」タブを選択します。
「認証スキームのフロー」ページが表示されます。既存のステップが複数ある場合は、このページには連鎖のステップ間の接続が表示されます。スキームのステップが1つのみの場合は、そのステップが表示されます。
「変更」をクリックします。
「認証スキームのフロー」ページに変更可能なエントリが表示されます。このページには、スキームの各ステップの名前が表示されます。このページにはステップごとにリストがあり、このリストから、現在のステップが成功または失敗した場合に次に実行するステップを選択します。
開始ステップとして使用するステップを選択するため、「開始ステップ」列でステップのラジオ・ボタンを選択します。
開始ステップとして構成できるのは、1つのステップのみです。
「ステップ名」列の各ステップに対し、次の手順を実行します。
「成功時の次のステップ」列の下にあるリストで、現在のステップが成功した場合に実行する次のステップを選択します。
「失敗時の次のステップ」の下にあるリストで、現在のステップが失敗した場合に実行する次のステップを選択します。
あるステップの完了後に実行を終了する場合は、停止終了記号を選択します。停止は、ステップの成功または失敗のいずれに対しても使用できます。
両方の選択リストには、連鎖認証スキームに構成したすべてのステップの名前が表示されます。
構成を確認した後で、「フローの検証」をクリックして、サイクルが含まれていないかどうかを確認します。
詳細は、「認証フロー内のサイクルの検査および修正」を参照してください。
フローにサイクルが含まれていないことを確認した後で、「保存」をクリックします。
認証連鎖のフローは複雑になることがあるため、連鎖にサイクルが含まれる可能性があります。
スキームのステップ間の接続方法を定義した後で「フローの検証」ボタンをクリックすると、保存する前に構成内にサイクルがないかどうかをチェックできます。
「フローの検証」ボタンは、次のスクリーン・ショットに示す「認証フロー」サブタブをクリックすると表示されます。この後、「変更」をクリックします。
認証フローの構成にサイクルが含まれている場合、問題のあるフローがポリシー・マネージャによって「連鎖認証スキームのすべてのフロー」ページに表示されます。そのような構成は、サイクルを修正しないかぎり保存できません。認証フローの構成を検証せずに保存しようとすると、ポリシー・マネージャによって構成が自動的にチェックされ、どのフローにもサイクルが含まれていないかどうかが確認されます。
ポリシー・マネージャでは認証フローを検証してサイクルがないかチェックしますが、複雑な認証スキームのフローは、構成する前に慎重に設計することをお薦めします。サイクルが含まれていることが「連鎖認証スキームのすべてのフロー」ページで報告されたフローを修正するには、「認証スキームのフロー」ページを使用します。
「連鎖認証スキームのすべてのフロー」ページには、構成したすべてのフローが次のように表示されます。
サイクルのないフローは黒で表示されます。
サイクルが含まれているフローは赤で表示されます。
アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックし、左側のナビゲーション・ペインにある「認証管理」をクリックします。
複数ステップの認証スキームのリンクをクリックします。
「認証フロー」サブタブをクリックします。
「変更」をクリックします。
「フローの検証」をクリックします。
ステップのフローにエラーがある場合は、報告されたフローとフロー内の問題のあるステップが、「連鎖認証スキームのすべてのフロー」ページに表示されます（サイクルが含まれているフローの例は、次のスクリーン・ショットを参照）。
検証プロセスでサイクルが含まれているフローが複数報告された場合は、そのすべてをメモして修正します。
問題のあるフローが報告されている「連鎖認証スキームのすべてのフロー」ページで、「戻る」をクリックします。
「認証スキームのフロー」ページが表示されます。
サイクルが含まれているフロー内の問題を修正します。
「認証連鎖のフローの構成および変更」では、認証フローの作成に使用する手順について説明しています。この手順を実行して、問題のあるステップ間の接続を変更します。
「フローの検証」をクリックします。
サイクルが含まれるフローが検証結果に依然として表示される場合は、フローの修正を続行します。
サイクルの原因であるすべての問題が解決されたら、「保存」をクリックします。
各ポリシー・ドメインには1つのデフォルト認証ルールを含めることが必須ですが、ドメイン内の各ポリシーにはポリシーに固有の認証ルールを含めることができます。ポリシーに認証ルールが含まれていない場合は、ポリシー・ドメイン全体に対して設定されているデフォルト認証ルールによる保護がポリシーに継承されます。図5-3は、認証ルールが含まれている、ポリシー・ドメインのデフォルト・ルールのセットを概念図で示したものです。この例では、ポリシー・ドメインにはポリシーがまだ作成されていません。
認証ルールには認証スキームが含まれ、このスキームにより、ユーザーIDの検証に必要な認証の種類や、ユーザー情報がないか検索するディレクトリ・サーバーおよびその他のものを指定します。詳細は、「認証スキームの概要」を参照してください。
ユーザーは、認証ルールで保護されているリソースへのアクセスをリクエストするたびに、ルールのスキームに指定されたチャレンジ・メソッドにより認証を受ける必要があります。
委任アクセス管理者は、管理権限のあるポリシー・ドメインおよびポリシーに対して認証ルールを作成できます。
この項の残りの内容は次のとおりです。
各ポリシー・ドメインに対し、デフォルト認証ルールを1つ定義する必要があります。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
ポリシー・ドメインのリストが表示されます。
表示するポリシー・ドメインのリンクをクリックします。
選択したポリシー・ドメインの「一般」ページが表示されます。
選択したポリシー・ドメインについて、「デフォルト・ルール」ページを選択します。
ポリシー・ドメインに認証ルールがすでに構成されている場合は、「認証ルール」ページにルールの定義が表示されます。
ポリシー・ドメインにはデフォルト認証ルールを1つのみ設定できます。既存のデフォルト認証ルールがある場合は、新しいデフォルト認証ルールを追加する前にそれを削除する必要があります。詳細は、「ポリシー・ドメインの認証ルールの削除」を参照してください。
「認証ルール」ページの「追加」ボタンをクリックします。
「認証ルール」の「一般」ページが表示されます。
デフォルト認証ルールに対する「名前」を入力します。
デフォルト認証ルールに対する「説明」を入力します。
特定の認証スキームを選択します。
選択は、マスター・アクセス管理者が作成した有効な認証スキームが表示されているリストから行います。新しいスキームを追加するには、「認証スキームの定義および管理」を参照してください。無効な認証スキームはリストには表示されません。
「保存」をクリックします。
自分で作成したポリシー・ドメインなど、管理権限のあるポリシー・ドメインについては、その認証ルールを変更できます。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
ポリシー・ドメインのリストが表示されます。
表示するポリシー・ドメインのリンクをクリックします。
選択したポリシー・ドメインの「一般」ページが表示されます。
「デフォルト・ルール」をクリックします。
「認証ルール」タブの「一般」ページが表示されます。このページでは、ルールの現在の構成が表示されます。
「変更」をクリックします。
表示される「一般」ページの各フィールドが変更可能になります。
必要に応じて「名前」、「説明」または「認証ルール」を変更します。
変更内容を保存する場合は、「保存」をクリックします。または、保存しないでページを終了する場合は、「取消」をクリックします。
ポリシー・ドメインに設定できる認証ルールは1つのみであるため、新しい認証ルールを追加する前に既存のルールを削除する必要があります。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
ポリシー・ドメインのリストが表示されます。
表示するポリシー・ドメインのリンクをクリックします。
選択したポリシー・ドメインの「一般」ページが表示されます。
「デフォルト・ルール」をクリックします。
「認証ルール」タブの「一般」ページに、現在構成されているルールが表示されます。
「削除」をクリックします。
削除を確定する場合は、プロンプトに対して「はい」と応答します。
任意のポリシー・ドメインに対し、ドメイン内のリソースのグループに固有のポリシーを作成できます。ポリシー・ドメインのすべてのリソースは、ポリシーにデフォルト以外の認証ルールを指定して保護されるようになるまで、デフォルト認証ルールによって保護されます。ルールをポリシーに関連付けて定義するという点以外は、ポリシーの認証ルールの定義方法は、ポリシー・ドメインの認証ルールの場合と同様です。
ポリシーの認証ルールがすでに存在するときに、それを新しいルールと置換する場合は、新しいルールを作成する前に既存のルールを削除する必要があります。詳細は、「ポリシーの認証ルールの削除」を参照してください。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
ポリシー・ドメインのリンクをクリックします。
選択したポリシー・ドメインの「一般」ページが表示されます。
「ポリシー」タブをクリックします。
「ポリシー」ページに、存在するすべての既存ポリシーが表示されます。
認証ルールを追加するポリシーのリンクをクリックします。
ポリシーの構成を示す「一般」ページが表示されます。
ポリシーの「認証ルール」サブタブをクリックします。
「追加」をクリックします。
認証ルールを定義する「一般」ページが表示されます。
デフォルト認証ルールに対する「名前」を入力します。
デフォルト認証ルールに対する「説明」を入力します。
特定の認証スキームを選択します。
選択は、マスター・アクセス管理者が作成した認証スキームが表示されているリストから行います。新しいスキームの追加が必要な場合は、「認証スキームの定義および管理」を参照してください。
「保存」をクリックします。
管理権限を付与されているポリシー・ドメイン内のポリシーや、自分で作成したポリシー・ドメイン内のポリシーについては、その認証ルールを変更できます。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
認証ルールを変更するポリシー・ドメインを選択します。
選択したポリシー・ドメインの「一般」ページが表示されます。
「ポリシー」タブを選択し、すべての既存ポリシーがリストされたページを表示します。
このポリシー名リストから、認証ルールを変更するポリシーを選択します。
「ポリシー」の「一般」ページにポリシーの構成が表示されます。
「認証ルール」タブを選択します。
次のスクリーン・ショットに示すように、「認証ルール」の「一般」ページに認証ルールの定義が表示されます。
「変更」をクリックします。
「認証ルール」の「一般」ページにフォームが表示され、テキスト・ボックスとリストによる情報の編集が可能になります。
ポリシーの認証ルールの定義（名前、説明またはそれに含まれる認証スキーム）を必要に応じて変更します。
「保存」をクリックします。
管理権限を付与されたポリシー・ドメイン内のポリシーや、自分で作成したポリシー・ドメイン内のポリシーについては、その認証ルールを削除できます。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
選択したポリシー・ドメインの「一般」ページが表示されます。
選択したポリシー・ドメインについて、「ポリシー」タブを選択します。
「ポリシー」ページにすべての既存ポリシーが表示されます。
認証ルールを削除するポリシーを選択します。
ポリシーの構成を示す「一般」ページが表示されます。
「認証ルール」を選択します。
認証ルールの定義を示す「一般」ページが表示されます。
「削除」をクリックします。
確認プロンプトに「はい」と応答します。
オプションで、ルールの結果や認証の成功または失敗に基づいてアクションを実行するように認証ルールを構成できます。
アクションにより、リソースをリクエストしているユーザーのユーザー・プロファイル情報を他のアプリケーションに渡すことや、ユーザーのブラウザを別のサイトにリダイレクトすることが可能です。
アクションは次のように使用します。
許可という結果をルールで判定して戻す場合に、そのルールのアクションを実行します。
拒否という結果をルールで判定して戻す場合に、そのルールのアクションを実行します。
この項の残りの内容は次のとおりです。
アクションにより次の操作が可能です。
URLをアクセス・サーバーからアクセス・ゲートまたはWebGateにリダイレクトできます。
同一または別のポリシー・ドメイン内の下流アプリケーションへのユーザー情報の引渡し
HTTPヘッダー変数またはCookieを使用すると、アクションを使用して次の種類の情報を渡すことができます。
ユーザー・プロファイル情報
ユーザーのDN
静的なテキスト文字列
ヘッダー変数を使用して情報を下流のアプリケーションに渡す方法の詳細は、「HTTPヘッダー変数およびCookieの使用方法の概要」を参照してください。
HTTPヘッダー変数およびCookieのガイドラインは次のとおりです。
HTTPヘッダーまたはCookieではASCII以外の文字は使用できません。
その結果、認証ルールのアクションを定義するとき、ヘッダー変数の「名前」フィールドおよび「戻り属性」フィールドではASCII以外の文字はサポートされません。
HTTPヘッダー変数とCookieを使用して情報を下流アプリケーションに渡すときは、HTTPヘッダーの4Kというサイズ制限に注意してください。
このサイズ制限では、すべてのCookie、サーバー変数および環境変数が対象としてカウントされます。つまり、HTTPヘッダーのすべてのコンテンツがカウント対象として含まれます。コンテンツが4Kの制限を超えないかぎり、HTTPヘッダーに追加できる個々の要素の数に制約はありません。使用可能なHTTPヘッダーの領域を評価する際には、アプリケーションで使用するデータのバイト・サイズのことも勘案してください。たとえば、アイデンティティ・システムとその他のアプリケーションを合せると1KをHTTPヘッダーで使用する場合は、データには3Kを使用できます。
アクションはいろいろな目的に使用できます。次の表に、アクションの使用方法の例を示します。
表5-12 アクションの使用方法の例
| タスク | 例 |
|---|---|
|
認証アクションを使用して、ユーザーの名前を下流のアプリケーションに送信できる。 アプリケーションでは、この名前を使用して、パーソナライズされたメッセージをユーザーのログイン時に表示できます。 |
|
|
ヘッダー変数は次の目的で使用できる。 シングル・サインオンが機能するためには、ターゲット・アプリケーションでヘッダー変数が使用可能である必要があります。 |
|
|
リダイレクションを使用してユーザーを別のサイトに転送できる。たとえば、カスタム・フォームによる認証の後にユーザーをポータル・ページにリダイレクトできます。 |
|
重要: リダイレクションとヘッダー変数の使用は相互排他的です。 |
HTTPヘッダー変数は、静的な値を引き渡したり属性を識別するための手段として使用できます。認証アクションは、ユーザーのセッション中に1回、つまり、ユーザーのログイン時に実行されます。認証アクションとして渡されたヘッダー変数は、ユーザーのセッション全体にわたっては永続しません。ヘッダー変数は4KBに制限されています。このサイズへのカウント対象には、Cookie、サーバーおよび環境変数が含まれます。
認証の成功および認証の失敗のヘッダー変数は、アクセス・システムによって認識または保護されているWebサーバーへのみリダイレクトできます。ヘッダー変数はOracle Access Managerの外部へはリダイレクトされません。
「名前」フィールドと「戻り属性」フィールドにはそれぞれ、たとえば、HTTP_HELLOとcnを入力できます。この場合、アクセス・システムでは、値（cn属性に対するユーザーの共通名）をHTTP_HELLOというHTTPヘッダー内に格納してWebサーバーに送信します。このHTTPヘッダー変数をアプリケーションで確認し、アプリケーション・コードを使用して値を表示することで、インタフェースをパーソナライズしてユーザーの名前を追加できます。
cn属性に電話番号など複数のエントリが含まれる場合、アクセス・システムではそれらをコロン区切り形式の単一文字列として戻します。エンドユーザーは個々の値を自分で解析する必要があります。
obmygroupsパラメータは、ユーザーが所属するグループの名前をヘッダー変数に移入します。ユーザーが所属するグループにフィルタを適用するには、構文obmygroups:ldap_urlを使用します。フィルタに複数のエントリを含める場合は、コロン（:）で区切ります。たとえば、「戻り属性」フィールドに次のように入力すると、ユーザーが所属するグループで、group_typeがroleに設定されているDNに含まれるすべてのグループが戻されます。
obmygroups:ldap:///o=company,c=us??sub?(group_type=role)
|
注意: obmygroupsの使用によるパフォーマンスへの影響およびチューニングのヒントについては、『Oracle Access Managerデプロイメント・ガイド』を参照してください。ユーザーに関連付けられたグループを戻すには、IdentityXMLコールuserGroupsProfileを使用した方が、リソースの消費量が少ない場合があります。詳細は、『Oracle Access Manager開発者ガイド』のIdentityXMLパラメータの構成に関する章を参照してください。 |
ヘッダー変数の値を変更しても、その新しい値は、アクセス・サーバーのキャッシュをリフレッシュするまでは使用できるようになりません。
ヘッダー変数に影響を与えるキャッシュ・タイムアウト・パラメータは次の2つです。
ユーザー・キャッシュのタイムアウト: ヘッダー変数内の属性がディレクトリから取得されると、その属性はユーザー・キャッシュに格納されます。この属性の値が変更された場合、そのユーザーに対するユーザー・キャッシュのフラッシュがリクエストされないかぎり、アクセス・サーバーはユーザー・キャッシュのタイムアウトが発生するまでこの変更を認識しません。タイムアウトが発生した時点で、アクセス・サーバーはディレクトリからデータを再取得します。
ポリシー・キャッシュ・タイムアウト: ポリシー・データに関しては、ユーザーがアクションの戻り属性を変更し、この変更がアクセス・サーバーに伝達されない場合（たとえば、キャッシュ・フラッシュが失敗した場合）、アクセス・サーバーでは、ポリシー・キャッシュのタイムアウトが発生するまでこのアクションを認識しません。
Webサーバーによってヘッダー変数の処理方法は異なります。これは、アプリケーションで必要となる、ヘッダー変数の実装方法にも影響します。
次に例をあげます。
Netscape/iPlanet Webサーバーでは、アクセス・システムの変数の前に文字列HTTPが付加されます。
HTTP_CNという変数を定義すると、Netscape/iPlanetではHTTP_HTTP_CNという変数が生成されます。
作成するアプリケーションでヘッダー変数を読み取る必要がある場合、そのアプリケーションでは、HTTP_CNではなくHTTP_HTTP_CNという変数を検索する必要があります。
Microsoft IISでは、ヘッダー変数の定義にはアンダースコアではなくダッシュを使用する必要があります。このため、HTTP_CNではなくHTTP-CNと入力する必要があります。
受信側アプリケーションでは、この変数を、アンダースコアが含まれているものとして読み替える必要があります。つまり、アプリケーションでは、HTTP-CNではなくHTTP_CNを検索します。
Lotus Domino Webサーバーでは、アクセス・システムのヘッダー変数を渡すことはできません。
各種サーバーでのヘッダー変数の使用方法の詳細は、使用しているWebサーバーのドキュメントを参照してください。
アクションを使用して、ユーザーをターゲット・ページから別のページにリダイレクトすることができます。フォーム・ベース認証を使用する場合に、認証が成功したら、最初にリクエストされたURLとは別のページにユーザーを転送できます。これはリダイレクションの一般的な使用方法です。
たとえば、ユーザーがwww.dirac.com/spin/index.htmをリクエストする場合に、このユーザーに情報を要求するためのカスタム・フォームを作成できます。ユーザーがカスタム・フォームに入力した情報に基づいて認証されたら、このユーザーを独自のメイン・ポータル・ページにリダイレクトできます。ユーザーを最初にリクエストされたリソースに転送するかわりに、ユーザーのブラウザをリダイレクトできるのです。このためには、アクションの構成時にポータル・ページのURLをリダイレクト・フィールドに入力します。
認証の失敗時に、標準の「HTTP 404 ページが見つかりません」というページにではなく、参考になるWebページに、ユーザーをリダイレクトすることができます。
プラグインを実装してユーザーに2レベルの認証情報を要求するかわりに、2つの連続したフォーム・ベース認証画面を使用することができます。
2つのHTMLフォームを設計し、各フォームにはユーザーが資格証明を入力するテキスト・フィールドを設定します。各ログイン・フォームに対して資格証明マッピングを定義します。ユーザーには、HTMLフォームをベースにした2つの画面が連続して表示されます。ユーザーがフォームの送信ボタンをクリックすると、フォームのデータは、Webサーバーにポストされる前にWebGateによって捕捉および処理されます。WebGateでは、フォームの資格証明に一致する属性を持ったプロファイルをディレクトリから検索します。
たとえば、Arete Airlines社が搭乗時間に比例して加算される個人フライト特典を従業員に提供するとします。この航空会社のIT部門は、フォーム・ベース認証システムを実装し、2つの連続したHTMLフォーム・ベースの画面がユーザーに表示されるようにしました。各フォームではユーザー認証用に異なる種類の情報がリクエストされ、各フォームには独自のセキュリティ・レベルが設定されます。
第1画面: ユーザーに雇用地域と組織番号を要求します。
多数の従業員がこの情報を知っているため、このフォーム・ベース認証方式には1などの低いセキュリティ・レベルを設定できます。
第2画面: ユーザーの個人情報番号（PIN）を要求します。
この情報は個人的なものであり、ユーザーを一意に識別するため、このフォーム・ベース認証方式には3などの高いセキュリティ・レベルを設定できます。
ユーザーは、従業員フライト特典用の社内人事管理部サイトのリンクをクリックします。
アプリケーションにより最初のフォーム・ベースのHTMLページがユーザーに表示され、部門情報をユーザーに要求します。
第1画面の入力に対して認証が成功すると、ユーザーには2番目のフォーム・ベースのHTMLページが表示されます。
ユーザーのPINが認証されると、ユーザーにはリソースへのアクセス権が付与されます。
フォーム・ベース認証の詳細は、「フォーム・ベース認証」を参照してください。
アクションを認証の結果に応じて実行するようにカスタマイズする場合は、独自のアクションが作成可能になります。
カスタム・アクションを実装するには、認証の結果に応じてコールされるプラグインを作成します。
任意の数のアクションを実行する外部コードを設計できます。次に、アクションの例をあげます。
必須パラメータによるリレーショナル・データベースへのアクセス
リソースに対して認証されたユーザーのユーザー名の引渡し
ユーザーのアクセス権を定義するオプション・パラメータの追加
認証アクションを作成するには、「認証ルール」ページの「アクション」ページを使用します。アクションはオプションです。アクションの指定対象となる条件は、認証失敗、認証成功、または認証の失敗/成功を問わず、の3つの場合です。
タスク概要: ポリシー・ドメインの認証アクションの設定（次の手順を含む）
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックし、表の「名前」列で目的のポリシー・ドメインの名前をクリックします。
選択したポリシー・ドメインの「一般」ページが表示されます。
「デフォルト・ルール」タブをクリックします。
「一般」パネルが選択された状態で、「認証ルール」サブタブが表示されます。また、このページには「アクション」パネルもあります。
「アクション」パネルをクリックします。
アクションがまだ作成されていない場合は、「追加」をクリックします（アクションが作成されている場合は「変更」をクリックします）。
次のスクリーン・ショットに示すように、「認証ルール」の「アクション」ページが表示されます。
ユーザーの認証の成功に対応して実行するアクションを、「認証成功」テキスト・ボックスに指定します。
詳細は、次の手順を参照してください。
ユーザーの認証が失敗した場合に実行するアクションを、「認証失敗」テキスト・ボックスに指定します。
詳細は、次の手順を参照してください。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
入力を保存して前のページに戻る場合は、「保存」をクリックします。または、保存しないで前のページに戻る場合は、「取消」をクリックします。
ポリシー・ドメインの認証アクションを作成するには、次の手順を参照してください。
ポリシー・ドメインの認証アクションを作成する手順
選択したポリシー・ドメインの「デフォルト・ルール」タブで、「アクション」サブタブをクリックし、「変更」をクリックします。
「認証成功」および「認証失敗」のどちらの場合でも、ヘッダー変数は、アクセス・システムによって認識または保護されているWebサーバーにのみリダイレクトできます。ヘッダー変数はOracle Access Managerの外部へはリダイレクトされません。
「認証成功」および「認証失敗」の「リダイレクションURL」フィールドに、リクエスト受信後のエンドユーザー・ブラウザの転送先URLの絶対パスを入力します。次に例を示します。
認証の成功に対しては、次のURLを使用してエンドユーザーをポータルの索引ページにリダイレクトできます。
http://mycompany.com/authnsuccess.htm
認証の失敗に対しては、次のURLを使用してエンドユーザーのリクエストをエラー・ページまたは自動登録スクリプトにリダイレクトできます。
http://mycompany.com/authnfail.htm
成功および失敗の「戻り」の「タイプ」フィールドで、アクセス・システムで値をアクセス・ゲートに送信するために使用するメソッドを指定します。
指定するメソッドは、アクセス・ゲートで認識されるメソッドである必要があります。アクセス・ゲートでは次のタイプのメソッドを使用できます。
headervar
cookie
Access Manager APIで記述されたクライアントを使用する場合は、任意の英数文字列を戻り型として渡して、クライアントで解釈することができます。
HTTPヘッダー変数の詳細は、「HTTPヘッダー変数およびCookieの使用方法の概要」および「アクションおよびヘッダー変数」を参照してください。
|
注意: 「タイプ」フィールドを空白のままにし、「+」をクリックして別のフィールドを追加すると（または「保存」をクリックすると）、アクセス・システムではヘッダー変数がデフォルトとして使用されます。 |
「名前」フィールドで、戻り値または戻り属性を定義する変数名（たとえばUIDを戻す場合はREMOTE-USERなど）を入力します。
アプリケーションは、これらのフィールドに入力される変数を受け入れるように事前に構成されている必要があります。ヘッダー変数の「名前」フィールドでは、ASCII以外の文字は使用できません。
「戻り値」フィールドで、対応する「名前」変数に対してユーザー認証時に割り当てられている必要がある値を入力します。
「戻り属性」フィールドで、リクエスト元のユーザーのプロファイルからレスポンスに追加されるLDAP属性を入力します。
必要に応じて、「+」または「-」アイコンをクリックしてフィールドを追加または削除します。
アクションを定義した後は、「ポリシー・ドメインの認証アクションを作成する手順」に戻り、ポリシー・ドメインのアクションの構成を実行します。
各ポリシーには、ユーザー認証の成功または失敗に対応して実行する、そのポリシーの認証ルールのアクションを定義できます。アクションはオプションです。アクションの指定対象となる条件は、認証失敗、認証成功、または認証の失敗/成功を問わず、の3つの場合です。
タスク概要: ポリシーの認証ルールのアクションの定義（次の手順を含む）
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
「ポリシー・ドメイン」ページで、認証アクションを設定するポリシー・ドメインの名前を選択します。
選択したポリシー・ドメインの「一般」ページが表示されます。
選択したポリシー・ドメインについて、「ポリシー」タブを選択します。
「ポリシー」タブにすべての既存ポリシーが表示されます。
認証ルール・アクションを定義するポリシーを選択します。
「一般」パネルが選択された状態で、そのポリシーのページが表示されます。このページには、「認証ルール」、「認可条件式」、「監査ルール」など、その他のパネルもあります。
「認証ルール」パネルを選択します。
「一般」パネルが選択された状態で、「認証ルール」ページが表示されます。また、このページには「アクション」パネルもあります。
ルールを定義する場合は、「連鎖認証を使用した認証ルールの作成の概要」を参照してください。
「アクション」パネルをクリックします。
「追加」をクリックします。
認証ルールのアクションを定義するエントリ・フォームが表示されます。
ユーザーの認証が成功したかどうかに応じて実行するアクションを、「認証成功」および「認証失敗」テキスト・ボックスに指定します。
詳細は、「ポリシーのアクションを定義する手順」を参照してください。
アクセス・サーバーのキャッシュをいつ更新するかを設定します。
この新しい接頭辞の情報を使用してアクセス・サーバーのすべてのキャッシュを即時に更新する場合は、「キャッシュの更新」を選択します。
「キャッシュの更新」を選択しない場合は、アクセス・サーバーのキャッシュは、キャッシュがタイムアウトになって新しい情報をディレクトリ・サーバーから読み取ったときに更新されます。
「保存」をクリックし、次の手順に従ってポリシーのアクションを定義します。
ポリシーのアクションを定義する手順
選択したポリシー・ドメインの「ポリシー」タブで「認証ルール」をクリックし、必要に応じて「アクション」をクリックします。
「アクション」ページの「変更」ボタンをクリックします。
「リダイレクションURL」フィールドで、エンドユーザー・ブラウザをリクエストの受信後に転送する転送先のURLの絶対パスを入力します。たとえば、次のようにします。
認証の成功に対しては、このフィールドを使用してエンドユーザーをポータルの索引ページにリダイレクトします。
http://mycompany.com/authnsuccess.htm
認証の失敗に対しては、このフィールドを使用してエンドユーザーのリクエストをエラー・ページまたは自動登録スクリプトにリダイレクトします。
http://mycompany.com/authnfail.htm
「戻り」の「タイプ」フィールドで、アクセス・システムで値をアクセス・ゲートに送信するために使用するメソッドを指定します。
指定するメソッドは、アクセス・ゲートで認識されるメソッドである必要があります。アクセス・ゲートでは次のタイプのメソッドを使用できます。
headervar
cookie
アクセス・サーバーAPIで記述されたクライアントを使用する場合は、任意の英数文字列を戻り型として渡して、クライアントで解釈することができます。
リクエストされたリソースを保護する認証ルールに認証アクションが定義されている場合は、その認証アクションがユーザー認証の成功後にアクセス・システムにより実行され、その後で、リクエストされたリソースがユーザーに提供されます。認証アクションでは、保護されているアプリケーションに属性を渡して、ユーザーの操作性をカスタマイズしたり、リダイレクションを実行することなどができます。認証アクションが実行されるのみでなく、ObSSOCookieというCookieがユーザーに設定されます。ObSSOCookieにより、ユーザーは再認証を受けなくてもリソースに繰り返しアクセスできます。詳細は、「シングル・サインオンの構成」を参照してください。
状況によっては、ObSSOCookieは、認証アクションがトリガーされる前に設定される場合もあります。たとえば、ログイン用の複数のオプションがあるフォームにユーザーをリダイレクトするフォーム・ベース認証スキームで保護されているリソースを、ユーザーがリクエストしたとします。ユーザーは、フォーム上でログイン方法を選択すると、再度リダイレクトされ、今度は証明書ベースの認証スキームを含むフォームにリダイレクトされます。このシナリオでは、ユーザーが認証され、リクエストしたリソースにリダイレクトされるときには、ObSSOCookieはすでに設定されており、このため、ターゲット・リソース用に定義されたすべての認証アクションは省略されます。
ObSSOCookieが設定済の場合は、ターゲット・リソース用の認証成功アクションをトリガーするObTriggerAuthentication（OTA）というキーが、アクセス・システムにより提供されます。このトリガーを利用するには、OTAという名前のパラメータを認証スキームに構成し、このOTAスキームを使用する各ドメインに、認可成功に対応するアクションを定義します。
ターゲット・リソース用に定義されている認証アクションをトリガーするには、通常、ヘッダー変数などの情報を渡します。ObSSOCookieの存在は、一般に、認証アクションはすでに実行されていて、省略する必要があることを示します。認証スキーム内のOTA:trueパラメータは、認証アクションのトリガーとして機能します。認証スキームにOTA:trueパラメータが含まれる場合、このスキームによりOTA=trueの値がObSSOCookieに設定されます。ユーザーがリクエストしたリソースに再度リダイレクトされると、ObSSOCookieのOTA=trueの値により、認証アクションが自動的に実行されます。
OTA認証スキームを構成するには、リソースを保護するポリシー・ドメインにNoExecuteOTAという名前のCookieも定義する必要があります。NoExecuteOTA Cookieにより、特定のポリシー・ドメインのみがOTA:trueトリガーを利用できるようになります。シングル・ドメインまたはマルチドメインでのシングル・サインオンを実装する場合は、ObSSOCookieにOTA:trueパラメータが含まれていても、NoExecuteOTA Cookieにより、指定のポリシー・ドメインでのみ認証アクションがトリガーされるようになります。この結果、ObSSOCookieが存在する場合にはトリガーすることが禁止されている認証アクションを含むターゲットに対してOTAパラメータが作動することが防止されます。
ポリシー・ドメインでNoExecuteOTA CookieとOTAがtrueに設定されていると、そのポリシー・ドメインで保護されているリソースに対しては認証アクションが実行されません。
NoExecuteOTA Cookieがfalseに、OTAキーがtrueに設定されていると、OBSSOCookieがリセットされ、そのようなリソースに対して認証アクションが実行されます。
デフォルトでは、NoExecuteOTAはfalseに設定されます。
次の手順は、このスキームおよびこのスキームに関連付けられたアクションを構成する方法を示しています。
OTA認証スキームを作成する手順
アクセス・システム・コンソールで、「アクセス・システム構成」をクリックします。
左側のナビゲーション・ペインにある「認証管理」をクリックします。
OTA:trueパラメータを追加する認証スキームのリンクをクリックします。
「一般」タブが選択された状態で、「認証スキームの詳細」ページが表示されます。
「変更」をクリックします。
「チャレンジ・パラメータ」フィールドで、OTA:trueを追加します。
必要に応じて、プラス（+）記号をクリックし、このパラメータを入力する新規フィールドを追加します。
「保存」をクリックします。
アクセス・システムのランディング・ページで、「ポリシー・マネージャ」リンクを選択します。
アクセス・システム・コンソールで作業している場合は、ページの最上部にある「ポリシー・マネージャ」のリンクをクリックします。
左側のナビゲーション・ペインにある「ポリシー・ドメイン」をクリックします。
選択したポリシー・ドメインの「一般」ページが表示されます。
NoExecuteOTA Cookieを追加するポリシー・ドメインのリンクをクリックします。
このポリシー・ドメインについて、「認可ルール」タブをクリックします。
この認可ルールに名前を指定して、「保存」をクリックします。
「アクション」タブをクリックします。
「追加」をクリックします。
「戻り」フィールドで次のように追加します。
「タイプ」はcookieです。
「名前」はNoExecuteOTAです。
「戻り値」はtrueです。
監査ルールにより、イベント・ベースのデータが監査ログ・ファイルに書き込まれます。マスター・アクセス管理者は、マスター監査ルールをアクセス・システム・コンソールで作成する必要があります。委任アクセス管理者は、マスター監査ルールから自分のポリシー・ドメインおよびポリシー用に監査ルールを導出できますが、新しいマスター監査ルールは作成できません。
アクセス・サーバーには監査ログが1つあります。サーバーに対して監査ログ・ファイルのサイズとローテーション間隔を構成できます。イベントによっては、監査ログに重複した監査エントリが含まれる場合があります。
|
注意: 『Oracle Access Manager IDおよび共通管理ガイド』で説明されているように、監査詳細はデータベースに出力できます。 |
イベントの結果によって、異なる情報が監査ログに書き込まれます。ユーザー認証のログ・エントリは、ユーザーIDが認証されたかどうかによって異なります。
ディレクトリにユーザーのエントリがない場合、またはユーザーの資格証明が無効な場合には、監査失敗が発生する可能性があります。たとえば、ユーザーのエントリがディレクトリにあっても、ユーザーが不正なパスワードを入力した場合（認証失敗）は、ディレクトリ内のDNに基づいてcn属性の値がロギングされます。ただし、ユーザーのエントリを正しいエントリとして確認できないため、givennameなどの属性はディレクトリから取得されません。
ポリシー・ドメインとポリシーの監査ルールを定義できます。定義する監査ルールは、マスター監査ルールから導出する必要があります。マスター監査ルールは、マスター・アクセス管理者が作成する必要があります。委任アクセス管理者はマスター監査ルールからアクセス・ルールを導出できますが、作成はできません。
監査ルールはポリシー・ドメインおよびポリシーに対して作成するものであるため、この章では説明しません。監査ルールの作成、定義方法の詳細は、ポリシー・ドメインに関する章の次の各項を参照してください。
