| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
リソースまたはリソースのグループへのアクセスは、認証スキームという単一の認証プロセスで制御できます。認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。
各認証スキームには、定義済の認証モジュール(「個別の認証用プラグインのデプロイおよび管理」で説明した標準またはカスタムのモジュール)も含める必要があります。
管理コンソールまたはリモート登録ツールを使用してパートナを登録する場合、作成されるアプリケーション・ドメインには、デフォルト・スキームとして設定される認証スキームを使用するポリシーがシードされます。ポリシー作成中に使用されるデフォルトとして、既存の認証スキームを選択できます。
新しい認証スキームの作成、テンプレートとして使用する既存の定義のコピー、定義の変更または定義の削除も実行できます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、KerberosSchemeというスキームをコピーすると、そのコピーの名前は「KerberosSchemeのコピー」になります。
この項の内容は次のとおりです。
すべての認証スキームには、異なる値を使用した同じ要素が含まれます。
図22-26は、例としてデフォルトのLDAPSchemeページを示しています。
表22-20は、認証スキームのそれぞれの要素および値の情報を示しています。「デフォルトとして設定」ボタンを使用して、これをデフォルト・スキームにします。
表22-20 認証スキームの定義
| 要素 | 説明 |
|---|---|
名前 |
ナビゲーション・ツリーに表示されるこのスキームの一意の名前。 関連項目: 「事前構成済の認証スキーム」 |
説明 |
このスキームの使用を示す200文字までのオプションの説明。 |
認証レベル |
認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。 信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。 ノート: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表25-1を参照してください。 ノート: 指定されたレベルのリソースにユーザーが認証された後、リソースが元のリソースと同等またはそれ次の信頼レベルである場合に同じアプリケーション・ドメインまたは異なるアプリケーション・ドメインの他のリソースでユーザーが自動的に認証されます。 関連項目: 「マルチレベル認証およびステップアップ認証について」。 |
デフォルト |
「デフォルトとして設定」ボタンがクリックされた場合に選択される編集不可のボックス。 |
チャレンジ・メソッド |
リストの選択可能な項目からチャレンジ・メソッドを1つ選択する必要があります。
関連項目: 「資格証明チャレンジ・メソッド」 |
チャレンジ・リダイレクトURL |
このURLは、資格証明コレクタ(ECCまたはDCC)を参照するエンド・ポイントを宣言します。次に例を示します。 ECC: DCC: 関連項目: |
認証モジュール |
ユーザーに資格証明を要求するために使用する事前構成済認証モジュールを指定します。ここで指定されたモジュールまたはプラグインによって、使用する正確なユーザー・アイデンティティ・ストアが指定されます。
|
チャレンジURL |
このURLは、指定されているチャレンジ・メソッド(FORMなど)に関連付けられます。 フォーム・ベースの即時利用可能な認証スキーム(LDAPSchemeおよびLDAPNoPasswordValidationScheme)の場合、チャレンジURLは「/pages/login.jsp」です。最後のURLを作成するには、コンテキスト・タイプおよびコンテキスト値を使用します。 X509ベースのチャレンジURLは、次の形式で指定します。 ノート: デフォルトのチャレンジURLは、OAMサーバーの組込み資格証明コレクタ(ECC)に基づいています。外部資格証明コレクタが有効化されたWebゲートと、Webゲートとともにインストールされる関連DCCページを使用している場合は、「DCC対応の11g Webゲートと認証ポリシーの構成」を参照してください。 |
チャレンジ・パラメータ |
サポートされているチャレンジ・パラメータの詳細は、「認証スキームのチャレンジ・パラメータ」を参照してください。 |
フォーム、X509またはDAPチャレンジ・メソッドを使用したスキーム |
この後の要素は、チャレンジ・メソッドとしてフォーム、X509またはDAPを使用するスキームにのみ含まれます。他のスキームは、変更する必要がないデフォルトを使用します。 |
コンテキスト・タイプ |
次の使用可能な値に基づいて、埋込み資格証明コレクタの最後のURLを作成するために使用します(ECC専用です。DCCには使用しません)。
|
コンテキスト値 |
資格証明コレクタの最後のURLを作成するために使用されます。デフォルト値は/oamです。 |
カスタム・ログイン・ページについて
フォーム、X509またはDAPチャレンジ・メソッドを使用したスキームのみ、表22-20の最後に示されている追加要素が含まれます。すべてのカスタム・ログイン・ページで次の要件を満たす必要があります。
カスタム・ログイン・ページには、2つのフォーム・フィールド(ユーザー名およびパスワード)が必要です。Access Managerではカスタム・フォームをサポートしています(『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照)。
CustomWarおよび外部コンテキスト・タイプでは、次の2つのタスクを実行するカスタム・ログイン・ページ内のロジックが必要になります。
Access Managerサーバーから受け取ったページにリクエストIDを送信します。たとえば、String reqId = request.getParameter("request_id"); <input type="hidden" name="request_id" value="<%=reqId%>">などです。
OAMサーバーにエンド・ポイント「/oam/server/auth_cred_submit」を戻します。たとえば、<form action="/oam/server/auth_cred_submit">または「http://oamserverhost:port/oam/server/auth_cred_submit」などです。
詳細は、以下のトピックを参照してください。
関連項目:
ログインのページおよびメッセージのカスタマイズの詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
BasicFASchemeやKerberosSchemeなどの事前構成済の認証スキームは、Access Managerで使用できます。
表22-21 事前構成済認証スキーム
| スキーム名 | 仕様 | 説明 |
|---|---|---|
AnonymousScheme |
|
特定のAccess Manager URLを保護されていない状態のままにするので、ユーザーは何も要求されずにこのURLにアクセスできます。ユーザーが要求されないので、資格証明を入力する必要はありません。 ノート: 認証レベル0は、公開ページに使用されます。カスタム認証スキームにレベル0を使用しないことをお薦めします。 付記: リソースがAnonymousSchemeによって保護されている場合、セッション検索では表示されません。 |
BasicFAScheme Oracle Fusion Applicationsのみ |
Fusion Applications用 |
この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。 |
BasicScheme |
|
ほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 ノート: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。 |
BasicSessionlessScheme |
|
主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 チャレンジ・パラメータ: CookieLessMode=true ノート: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。 |
FAAuthScheme Oracle Fusion Applicationsのみ |
|
この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。 |
FederationMTScheme Oracle Fusion Applicationsのみ |
|
この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。
関連項目: 「認証スキームのチャレンジ・パラメータ」。 |
FederationScheme Identity Federation 11.1.2のみ |
|
|
KerberosScheme |
|
Active DirectoryのWindows固有の認証チャレンジ・メソッドおよび有効なWNA資格証明に基づいて、ほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 |
LDAPNoPasswordValidationScheme |
ノート: LDAPNoPasswordAuthModuleは、DAP(アサータ)メカニズムに似ています。 この表の後半の「OAM10gScheme」も参照してください。 |
フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 WebLogicコンテナのリソースを使用している場合にSSOのアイデンティティ・アサータとともに使用されます。『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。 |
LDAPScheme |
|
フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 |
OAAMAdvanced |
|
外部コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの完全な統合が必要な場合、この認証スキームが使用されます。Webgateは、パートナのフロント・エンド処理を行う必要があります。 |
OAAMBasic |
|
デフォルト・コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの基本統合が必要な場合、このスキームを使用する必要があります。ここでは、OTPなどの拡張機能はサポートされません。エージェントとしてmod_ossoを使用する場合、統合機能のようになります。 |
OAM10gScheme |
この表の前半の「LDAPNoPasswordValidationScheme」も参照してください。 Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスの「enableCoexistMode」および「disableCoexistMode」 |
Oracle Access Manager 10gとの統合および共存を容易にします。共存モードでは、Oracle Access Manager 10gがオーセンティケータ、Access Manager 11gがアサータになります。 このスキームには、「OAM10G」で説明されているように、特にOAM10gがOSSOと共存する場合は、チャレンジ・メカニズムとしてOAM10Gが必要です。 |
OAMAdminConsoleScheme |
|
Oracle Access Managementコンソールの認証スキーム。 |
OICScheme |
|
Access Managerは、このスキームを使用して認証をMobile and Socialサービスに委任し、ユーザーを認証のためにMobile and Socialログイン・ページにリダイレクトします。 |
OIFScheme Oracle Identity Federation 11.1.1のみ Identity Federation 11.1.2の場合はFederationSchemeを使用します。 |
|
このスキームは、認証をOIFに委任し、その後、Oracle Identity FederationがOAMサーバーによってアサートされているトークンを送信します。 委任認証プロトコル(DAP)チャレンジ・メソッドを使用して、認証をサード・パーティ(この場合はOIF)に委任します。 チャレンジ・パラメータ: TAPPartnerId=OIFDAPPartner 関連項目: 「認証スキームのチャレンジ・パラメータ」。 |
OIMScheme |
|
デフォルト・コンテキスト・タイプでOracle Identity Manager関連リソースを保護します。 ノート: OAMおよびOIMを統合する場合、OAMは、次のいずれかが検出された場合にユーザーの認証レベルをダウングレードします。
このため、ユーザーがリダイレクトされるアイデンティティ管理(OIM)ページの必要な操作を実行した後にのみ、ユーザーはページにアクセスできます。 レベル1の場合、必要な操作の公開ページおよびOIMページにのみアクセスできます。 ノート: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。 |
OSSO 10gからAccess Manager 11gに移行されている環境のデフォルトの認証スキームとして設定します。 |
||
PasswordPolicyValidationScheme |
|
パスワード・ポリシー評価を有効にします。 |
TAPResponseOnlyScheme |
|
|
TAPScheme |
|
IAM Suiteアプリケーション・ドメイン、「Protected Higher Level Policy」でIDM製品リソースにTAPSchemeを使用するには、「認証スキーム」の変更に加えて、次の構成を行う必要があります。
チャレンジ・パラメータ: TAPPartnerId=TAPPartnerName |
X509Scheme |
|
この認証スキームは、証明書ベースのユーザー識別方法です。この方法を使用するには、ユーザーのブラウザに証明書をインストールし、WebサーバーをSSL対応にする必要があります。 ノート: このスキームは、SSLに依存して、ユーザーのX.509証明書をOAMサーバーに送ります。 |
認証には、リソースへのアクセスのリクエスト、HTTPを介した資格証明の収集および資格証明の検証結果に基づくHTTPレスポンスの応答の実行時にユーザーが指定する必要がある資格証明の決定が含まれます。
Access Managerは、認証スキームに使用する次の資格証明チャレンジ・メソッドを提供します。
FORM
この認証チャレンジは、ユーザー資格証明のために1つ以上のテキスト入力フィールドを含むHTMLフォームを使用します。通常のフォームベース・チャレンジで、ユーザーはフォームの2つのテキスト・ボックスにユーザー名とパスワードを入力します。最も一般的な資格証明の選択はユーザー名とパスワードですが、ユーザー名、パスワード、ドメインなどの任意のユーザー属性を使用できます。
「送信」ボタンを使用して、フォームのコンテンツを転送します。ユーザーが「送信」ボタンをクリックすると、フォーム・データがWebサーバーに転送されます。フォームで収集されたユーザー資格証明の検証時に、ユーザーが認証されます。
ノート:
このチャレンジ・メソッドは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに基づいています。
次のような理由でフォームベースの認証チャレンジを使用できます。
一貫性のあるユーザー操作性: フォームベースのログインおよび標準化されたログインを使用すると、ログインおよびログアウト機能のユーザー操作性がブラウザ間で一貫して実現します。
カスタム・フォーム: 認証プロセスで組織のルック・アンド・フィールを適用できます。
たとえば、Basic認証で使用される標準のユーザー名およびパスワード・ウィンドウのかわりに、カスタム・フォームに企業ロゴおよびようこそメッセージを含めることができます。
追加情報: ログイン時に追加情報を収集できます。
追加機能: 紛失したパスワードを管理するページのリンクなど、ログイン手順とともに追加機能を提供できます。
BASIC
この組込みのWebサーバー・チャレンジ・メカニズムは、ユーザーにログインIDおよびパスワードの入力を要求します。提供された資格証明は、LDAPディレクトリ・サーバーのユーザー定義と比較されます。したがって、Basicチャレンジは、LDAP認証モジュールおよびそのモジュールに関連付けられたユーザー・アイデンティティ・ストアに依存します。
ノート:
URLがAccess ManagerによってBasic認証を使用して保護されており、OIDがアイデンティティ・ストアとして構成されている場合は、OIDで定義されたユーザーはログインできません。これを解決するには、次に示す行を、config.xmlファイルの中の終了</security-configuration>タグの前に追加します。
<enforce-valid-basic-auth-credentials>false </enforce-valid-basic-auth-credentials>
X509
X509証明書チャレンジ・メソッドを使用する場合、認証を実行するには、エージェントを通じてOAMサーバーに送信するSSLを介したX.509デジタル証明書をユーザーのブラウザで指定する必要があります。
ノート:
X509は、X509Schemeのチャレンジ・メソッドです。ユーザーの組織は、証明書の取得方法を決定できます。
認証するX.509クライアント証明書の妥当性を確認するには、OAMプロキシおよびOAMサーバーで使用されるキーストアの信頼されたCAに対してX.509クライアント証明書を確認する必要があります。
Access Managerに関連付けられているユーザー・アイデンティティ・ストアに対して、X.509証明書の次の属性を検証できます。
SubjectDN
SubjectUniqueID
CN
ユーザー・エントリを取得するには、X509認証モジュールで検証されるX.509証明書の属性名および検索が起動するLDAP属性を取得します。予期される結果は、基準と一致する1つのユーザー・エントリです。検索でユーザー・エントリが戻らない場合または複数のエントリが戻る場合、認証に失敗します。認証スキーム・パラメータはoam-policy.xmlにあります。
ノート:
X509認証の場合、管理者はリバース・プロキシとしてOracle HTTP Server(またはwl-proxyプラグインを使用するサーバー)を構成する必要があります。Oracle HTTP Serverを双方向SSLモードで構成して、認証するX.509証明書を取得する必要があります。CRL検証にもOracle HTTP Serverを構成できます。
オンライン証明書ステータス・プロトコル(OCSP)機能も提供されます。X.509証明書ベースの認証に渡される証明書は、OCSPリクエストを使用して検証します。管理者は、1つ以上のOCSPサーバーと通信するシステムを構成して、証明書ステータスを取得できます。
OCSP応答者URLのX509認証モジュール構成は、OCSP検証を実行するかどうかを示します。指定されている場合、値は、OCSPを使用してX.509クライアント証明書を検証するURLを示します。値がない場合、OCSP検証はありません。
WNA
Active DirectoryのWindows固有の認証およびKerberos認証モジュールを使用します。
ノート:
KerbSchemeは、WNAチャレンジ・メソッドおよびKerberos認証モジュールに基づいています。
関連項目:
Windowsネイティブ認証との統合の詳細は、「Windowsネイティブ認証のためのAccess Managerの構成」を参照してください。
NONE
なしチャレンジ・メソッドでは、ユーザーが要求されないので資格証明を入力する必要がありません。これは、AnonymousScheme認証スキームで使用されます。この認証スキームを使用すると、ユーザーは、保護しないAccess Manager固有のURLにアクセスできます。
DAP
委任認証プロトコル(DAP)チャレンジ・メソッドは、認証モジュールがDAP、コンテキスト・タイプが外部であるOIFScheme (Oracle Identity Federation 11.1.1統合)で必要です(表22-20)。DAPチャレンジ・メカニズムでは、外部オプションを使用する標準チャレンジのフォーム・メカニズムと異なり、Access Managerが受け取ったトークンのアサーションを実行します。
DAPModuleはアサーション・モジュールですが、このアプリケーション専用であり、Oracle Access Managementコンソールの認証モジュールのリストには表示されません。この統合により、OSSO 10gはAccess Manager 11gに置き換えられますが、Identity Federation側からの変更はありません。
DAPチャレンジ・メカニズムは、認証をサード・パーティ(この場合はIdentity Federation)に委任します。challenge_urlは、Identity FederationサーバーのURLを指しています。リソースがこのスキームで保護されている場合、OAMサーバーは資格証明コレクションのためにIdentity FederationサーバーURLにリダイレクトします。この場合、OAMサーバーは、資格証明の収集または検証を実行しません。Identity Federationは、資格証明を収集し、アイデンティティ・ストアに対してユーザーを認証して、ユーザー名で構成されるアサーション・トークンをOAMサーバーに返します。Access Managerは、このトークンを受信して復号化し、Oracle Access Managementのデフォルト・アイデンティティ・ストアでユーザーが有効なユーザーかどうかを確認します。ユーザーが有効な場合、Access Managerはリソースへのアクセスを付与します。
DAPTokenは、Access ManagerとIdentity Federationによって共有されるキーで暗号化および復号化されます。DAPTokenは、Access Manager側で構築されます。
Identity Federation管理EMコンソールでは、Access ManagerとIdentity Federationの間の通信を保護するために使用される暗号化キーを含むキーストアを生成できます。Access ManagerのWLSTコマンド(registerOIFDAPPartner)は、Identity Federationストアによって生成されるキーストアの場所を受け取り、キーを取得して、Identity Federation側に格納します。
OAM10G
DOC: Create version 2 of this topic before making 12C specific changes here.このメカニズムは、OSSO 10gと共存するOracle Access Manager 10g向けに作成されています。OAM10Gメソッドは常に認証/認可のプロバイダとして動作しており、OSSO 10g統合クラシック・アプリケーション(Portal、Discoなど)も含んでいるドメインをOracle Access Manager 10gが保護している場合、OAM10gSchemeとLDAPNoPasswordAuthModuleを使用して信頼関係を円滑化するために必要です。
OSSO10GはWebgateを通じてOAM10Gチャレンジ・メソッドで保護されます。OAM10Gは、常に認証/認可プロバイダとして動作します。
統合の促進: OSSO 10g統合クラシック・アプリケーションをAccess Managerにアップグレードできます。その場合、Access Managerは、アサーション・プロバイダとしてのみ動作します。Access Managerは、これらのアプリケーションがアクセスできるように、mod_ossoが消費できるトークンを作成します。mod_ossoアプリケーションは、新しい「OAM10gScheme」で保護されます。OAMサーバーのフロント・エンド処理を行い、10gアクセス・サーバーに対して構成されているWebgateが存在します。
設定: リソースへのアクセスが行われると、Webgateはリクエストを捕捉し、認証のために10gアクセス・サーバーに送信します。Oracle Access Manager 10gは、資格証明を収集し、アイデンティティ・ストアに対して検証し、ヘッダー変数(OAM_REMOTE_USER)としてユーザー名を設定します。リクエストはOAMサーバーに移動し、OAMサーバーはOAM10gSchemeを使用してヘッダー変数のユーザー名を検索します。Access Managerは、ヘッダー変数を取得し、プライマリ・アイデンティティ・ストアに対してユーザーの存在をアサートします。存在する場合、必要なCookie (OAM_ID)が生成され、リソースにリダイレクトされます。
関連項目:
表22-21のOAM10gScheme
Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンスのenableCoexistModeおよびdisableCoexistMode
チャレンジ・パラメータは、Webgateおよび資格証明コレクタ・モジュールによって使用および解釈される短いテキスト文字列で、その値で示された方法で動作します。
チャレンジ・パラメータは、次の構文で指定します。
<parmatername>=<value>
これは、Webgateのリリース(10gと11g)に固有の構文ではありません。認証スキームは、Webgateのリリースから独立しています。
表22-22は、チャレンジ・パラメータを持つ事前構成済のスキームを示しています。
表22-22 事前構成済スキームのチャレンジ・パラメータ
| 事前構成済スキーム | チャレンジ・パラメータ |
|---|---|
BasicSessionlessScheme |
CookieLessMode=true 主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 |
FederationMTScheme |
主に、複数要因認証をサポートするFusion Applicationsに使用されます。
「RSA SecurID認証とAccess Managerとの統合」および『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、RSAマルチステップ認証で使用されます。 |
FederationScheme Identity Federation 11.1.2のみ。Oracle Identify Federation 11.1.1の場合はOIFSchemeを使用します。 |
主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。
主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 |
OAAMBasic |
oaamPostAuth=true oaamPreAuth=true OAAM関連のリソースを保護します。これらのパラメータは、OAAMとの基本統合が必要な場合に使用します。 |
OIFScheme Oracle Identify Federation 11.1.1のみ。Identity Federation 11.1.2の場合はFederationSchemeを使用します。 |
TAPPartnerId=OIFDAPPartner このスキームは、認証をOracle Identity Federation 11.1.1に委任し、その後、FederationがOAMサーバーによってアサートされているトークンを送信します。 |
TapScheme |
TAPPartnerId=TAPPartnerName |
認証スキームは、リクエストをアクセス・サーバーに送信する前に、コンテキスト固有の情報を収集できます。コンテキスト固有の情報は、情報の外部コールの形を取ることができます。表22-23に、認証スキームで使用できるユーザー定義チャレンジ・パラメータを示します。
表22-23 認証スキームのユーザー定義チャレンジ・パラメータ
| チャレンジ・パラメータ | 定義 |
|---|---|
initial_command=NONE |
収集対象の資格証明を指示する場合に必要です。 たとえば、フォームベースの認証の場合、通常、このフレームワークではログイン・ページから送信される「username」と「password」を収集することになります。ただし、ログイン・ページの別のフィールド(たとえば、「form_username」と「form_password」)からの資格証明が必要になることがあります。このチャレンジ・パラメータを設定すると、初期制御をログイン・ページからプラグインに移すことができます。このプラグインで、ログイン・ページから収集するパラメータを判断してから、ログイン・ページに適切に転送またはリダイレクトします。 デフォルト: 空白(未設定) |
action= |
actionパラメータは、ハード・コードされたECCデフォルトの ノート: ECCは、 |
creds= DCCのみ |
外部資格証明コレクタ(DCC)でのみサポートされます。 次の11gの例では、usernameとpasswordは、ログイン・フォームの該当するフィールドの名前です。 creds=username password ノート: このチャレンジ・パラメータのフォーマットは10gリリースより変更されています。 Webサーバーのソース(サーバー・パラメータ)は、他のソースより優先されます。これにより、ユーザーが設定するリクエスト・データがWebサーバーのデータをオーバーライドすることが防止されます。たとえば、ユーザーから送信されたremote_user Cookieは、Webサーバーによって設定されたremote_user変数をオーバーライドしません。 一般に、フォームベースのチャレンジ・メソッドを使用する認証スキームで保護されているログイン・フォームをユーザーが送信すると、DCCは、この METHOD=POST処理を使用するフォームの場合、リクエストの本体にフォームからの資格証明データを付けてブラウザがPOSTリクエストをWebサーバーに送信します。フォームでMETHOD=GETが使用されている場合は、credsパラメータに指定されたものと同じ名前を持つ問合せ文字列パラメータを付けてブラウザがGETリクエストを送信します。可能な場合はPOSTプロセスを使用することをお薦めします。 ノート: |
extracreds= DCCのみ |
DCCでのみサポートされます。オプションのパラメータを指定します。オプションのパラメータが存在するときには、DCCを使用するマルチステップ認証の各反復時に、認証プラグインは、そのパラメータを収集できるようになります。
extracreds=[{any | cookie | header | server | query | post}:] <name> |
OverrideRetryLimit=0 |
ログインのRetryLimitをオーバーライドする試行回数です。 値は正整数である必要があります。 0を指定すると、この機能は無効になります。 |
ChallengeRedirectMethod |
埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対する認証POSTデータ保持パラメータ。 値: GET|POST|DYNAMIC ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作はDynamicです。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
MaxPreservedPostDataBytes |
認証POSTデータの保持に対してこの認証スキーム・チャレンジ・パラメータ(またはユーザー定義Webgateパラメータ)を構成します。 デフォルト: 8192バイト ノート: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作は8192バイトです。 このパラメータは、Webgateが保持できるPOSTデータの最大長を定義します。インバウンド・ロー・ユーザーPOSTデータ(または処理後に暗号化されるPOSTデータ)がこの制限を超えた場合、POSTデータは削除され、既存の認証フローが続行されます。イベントは通常どおり記録されます。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
MaxPostDataBytes= DCCのみ |
この認証スキーム・チャレンジ・パラメータを構成して、ユーザーの資格証明として送信され、OAMサーバーに転送されるPOSTデータの最大バイト数を制限します。 このチャレンジ・パラメータは、DCCによるPOSTデータ保持に対してのみ構成します。そして、フォーム上の資格証明としてポストして、OAMサーバーに送信できるPOSTデータの最大バイト数を制限します。DCCは、Content-Lengthヘッダーの値と、設定されている制限値とを比較します。 デフォルト: 8192バイト このチャレンジ・パラメータは、正の整数値を必要とします。 関連項目: |
ssoCookie= |
OAMAuthnCookie Cookieを制御します(「暗号化Cookieのチャレンジ・パラメータの構成」を参照)。 デフォルト: ssoCookie=httponly ssoCookie=Secure どちらかの設定を無効にします。 ssoCookie=disablehttponly ssoCookie=disableSecure ノート: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。
関連項目: |
miscCookies= |
その他の各種のAccess Manager内部Cookiesを制御します。デフォルトでは、httponlyは、その他の(各種の)すべてのCookiesに対して有効化されています。 デフォルト: miscCookies=httponly miscCookies=Secure どちらかの設定を無効にします。 miscCookies=disablehttponly miscCookies=disableSecure ノート: これらのパラメータは、それぞれの資格証明コレクタ構成に応じて構成方法が異なります。
関連項目: |
DCCCtxCookieMaxLength= DCCのみ |
DCC Cookieの最大長を定義します。 デフォルト: 4096 関連項目: 詳細は、この表のTempStateModeを参照してください。 |
TempStateMode= |
次に示すパラメータの値(cookieまたはform)での指定に応じて、DCCがOAMサーバーの状態を格納する方法を制御します。
ノート:
ECCの場合: serverRequestCacheTypeでは、OAMサーバーがサーバーの状態をメモリー内(BASIC)に格納するか、メモリー外(FORMまたはCOOKIE)に格納するかを指示します。serverRequestCacheType = COOKIEまたはFORMは、ECCを使用する場合にのみ効果に違いがあります。OAMサーバーは、サーバーの状態をリクエスト・トークンに格納します。ECCは、パラメータでの指定(たとえば、serverRequestCacheType=COOKIE)に応じて、Cookieまたは非表示のフォーム・フィールドにこれを保持します。 DCCの場合: serverRequestCacheType=COOKIEまたはFORMに違いはありません。TempStateModeは、DCCがOAMサーバーの状態を格納する方法(cookieまたはform)を、パラメータ値の指定(たとえば、TempStateMode=cookie)に応じて制御します。DCCでは、フォームベース認証スキームによるPOSTデータのリストアには、チャレンジ・パラメータTempStateMode=formが必要です。 関連項目: |
allowedAccessGateList= |
このスキームにより認証の強制が許可されるWebゲートを定義する、スペースで区切られたWebゲートIDのリストで構成された認証スキームのチャレンジ・パラメータ。次に例を示します。 allowedAccessGateList=WebgateID1 WebgateID2 |
TunneledUrls |
|
この項では次のトピックを記載しています:
各認証スキームに強度レベルが必要になります。数字が大きいほど、認証メカニズムのセキュリティが高く、数字が小さいほど、スキームの強度は低くなります。
次に例を示します。
LDAPScheme authLevel=1
KerbScheme authLevel=3
ノート:
マルチレベル認証は、X.509証明書の認証に影響を与えず、X.509証明書の認証を否定または変更しません。
SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。特定のレベルのユーザーの認証に成功した後、ユーザーは、1つ以上のアプリケーション・ドメインで保護された1つ以上のリソースにアクセスできます。ただし、アプリケーション・ドメインで使用される認証スキームは、同じレベル(または下位のレベル)にする必要があります。ユーザーが現在のSSOトークンのレベルを超える認証レベルで保護されたリソースにアクセスする場合、再認証されます。ステップアップ認証の場合、高いレベルで示されるチャレンジに失敗しても、ユーザーは現在のレベルのアクセスを維持します。これは「追加認証」です。
ノート:
レベル3のリソースへのアクセスを認証されているユーザーは、3以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます(これはステップアップ認証と呼ばれます)。
Access Managerポリシーでは、同じアプリケーションの複数のリソースを複数の認証レベルで保護できます。
その場合、アプリケーションはそのレベルを適用し、再認証するために動的ディレクティブをmod_ossoに送信する必要があります。動的ディレクティブを受信すると、mod_ossoは、適切なレベルで再認証するためにAccess Managerにリダイレクトします。
どちらのエージェント・タイプでも、ユーザーをOAMサーバーにリダイレクトして再認証します。リソースのポリシーに構成された認証スキームのレベルに応じて、チャレンジが示されます。
登録されたエージェントは、次に示すように認証レベルを検出します。
OAMエージェントは、OAMサーバーから不十分なレベルのエラー・メッセージを受け取ります(「OAMエージェントによる不十分な認証レベルの検出」を参照してください)。
mod_ossoは、動的ディレクティブから認証レベルを検出します(「10g OSSOエージェントを使用したマルチレベル認証の処理」を参照してください)。
ノート:
mod_ossoは、Access Managerに認証を委任します。mod_ossoで保護されたリソースは、Access Manager認証レベルで保護することをお薦めします。mod_ossoプラグインは、同じアプリケーション上の別々の信頼レベルの2つのリソースをサポートしません。
関連項目:
例については、「Access ManagerとOracle Adaptive Access Managerの統合」を参照してください。すでに認証されているユーザーが、Access Managerを使用して低い認証レベルの別のリソースにアクセスします。ユーザーはすでに認証されているので、Oracle Adaptive Access Managerではユーザー名およびパスワードを入力するページが表示されません。ただし、Oracle Adaptive Access Managerで実行されるフローは、ユーザーがOracle Adaptive Access Managerにすでにログインしているかどうかによって異なります。
ユーザーが高いレベルの認証スキームで保護されるリソースをリクエストすると、次のプロセスが発生します。
関連項目:
プロセスの概要: OAMエージェントによる不十分なセッション・レベルの検出
サーバー側で認証レベルの確認は行われません。次の例は、10g OAMエージェントについての説明です。
ノート:
11g OAMエージェントは、エージェントごとに個別のOAMAuthnCookiesに関連付けられます。
OAMエージェントはリクエストをOAMプロキシに送信し、保護されたリソースのスキーム詳細を取得します。
OAMエージェントは、セッション情報のリクエストをOAMプロキシに送信します。
OAMプロキシは、認証されたレベルのObSSOCookieを含むObSSOCookieの詳細を戻します。
OAMエージェントは、ObSSOCookieのレベルを認証スキームのレベルと比較します。
不十分な場合、エージェントは認証プロセスを再起動します。
十分な場合、アクセス権が付与されます。
認証プロセス時に認証スキームのセキュリティ・レベルを変更するカスタム・プラグインを作成できます。
特定の条件に基づいて認証プロセス時に認証スキームのセキュリティ・レベルを上げることが必要となる場合があります。認証スキームのセキュリティ・レベルを、ユーザーのログイン元のアプリケーションによって変更する場合などです。たとえば、Active Directoryおよびリバース・プロキシはユーザーのログイン元として使用可能なソースです。認証プロセス時に、Active Directoryからログインするユーザーにはある認証セキュリティ・レベルが使用されるように、リバース・プロキシからログインするユーザーには別のセキュリティ・レベルが使用されるように動的に設定できます。
カスタム認証プラグインを使用すると、認証レベルをプラグイン・レスポンスとして設定できます。構成可能な認証レベルがプラグイン・ステップ・パラメータとしてプラグイン・レスポンスに設定される新しいカスタム認証プラグインを作成します。たとえば、PLUGIN_AUTHN_LEVELをプラグイン・レスポンスで構成します。これにより、使用している認証メカニズムに基づいて動的に認証レベルを設定できます。
カスタム・プラグインによってもたらされるセキュリティへの影響を回避するには、オプションの認証スキーム・チャレンジ・パラメータMAX_AUTHN_LEVELを使用します。MAX_AUTHN_LEVELの値は、リソースを保護するカスタム認証プラグインで設定できる最大認証レベルです。カスタム認証スキームでは、このパラメータはデフォルトで無効になっています。認証プロセス時にプラグインによって認証レベルの値が動的に変更されるようにするには、PLUGIN_AUTHN_LEVELよりも高い値でこの必須パラメータを設定する必要があります。
カスタム認証プラグインを作成し、MAX_AUTHN_LEVELより低い値でKEY_AUTHN_LEVELを構成します。新しい認証プラグインを使用するカスタム認証モジュールを作成し、カスタム認証スキームに関連付けます。リソースを保護する認証ポリシーにそのスキームを指定します。ユーザー・セッションが作成されると、管理者が設定した最大認証値をオーバーライドするプラグインに関する警告メッセージがOAMサーバーによって記録されます。MAX_AUTHN_LEVELが構成されていない場合やプラグインによってMAX_AUTHN_LEVELよりも大きい値が設定される場合は、認証レベルが認証スキームに設定されて認証が成功します。
認証レベルをプラグイン・レスポンスとして設定するサンプル・コードを次に示します。
String stepName = context.getStringAttribute(PluginConstants.KEY_STEP_NAME); String pluginLevel = PlugInUtil.getFlowParam(stepName, " PLUGIN_AUTH_LEVEL ", context); PluginResponse rsp = new PluginResponse(); rsp.setName(PluginConstants.KEY_AUTHN_LEVEL); rsp.setType(PluginAttributeContextType.LITERAL); rsp.setValue(pluginLevel); context.addResponse(rsp);
OAMエージェントとは対照的に、ホスト(または仮想ホスト)のmod_ossoで保護されたすべてのリソースが同じレベルで保護されます。mod_ossoでは、ユーザーがレベル2でmod_ossoホスト(または仮想ホスト)ですでに認証され、レベル3で別のmod_ossoで保護されたホスト(または仮想ホスト)にアクセスする場合にマルチレベル認証が適用されます。
プロセスの概要: OSSOエージェントのマルチレベル認証フロー
ユーザーは、レベル2のhost1のmod_ossoで保護されたリソースにアクセスします。
OSSOエージェントはリクエストをOAMプロキシに送信し、保護されたリソースの認証スキーム詳細を取得します。
SSOサーバーのOAM_ID Cookieおよびhost1のホスト・ベースCookie「HOST_port」が設定され、認証レベル情報が格納されます。
認証後、ユーザーは、高いレベルの認証で保護されるhost2のリソースにアクセスします。
host2の最初のアクセスなので、認証するためにユーザーがOAMサーバーにリダイレクトされます。
OAMサーバー(OSSOプロキシ)は、host2のリソースのアクセスに不十分なレベルのOAM_ID Cookieを受け取ります。
レベルが不十分な場合、OAMサーバー(OSSOプロキシ)は再認証を要求します。
レベルが十分な場合、アクセス権が付与されます。
有効な管理者の資格証明を持つユーザーは、アプリケーション・ドメインで使用される新しい認証スキームを追加できます。
前提条件
認証モジュールは、定義済であり使用できる状態であることが必要です(「個別の認証用プラグインのデプロイおよび管理」を参照)。
関連項目:
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「アプリケーション・セキュリティ」コンソールで、「Access Manager」セクションの「認証スキーム」をクリックします。
「認証スキームの作成」をクリックします。
新しい「認証スキーム」ページ(表22-20)で、デプロイメントに応じて次の情報を入力します。
「適用」をクリックして、新しいスキームを送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じます。
オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。
スキームのリストに新しいスキームが表示されていることを確認します(必要な場合はリフレッシュします)。
「特定のリソースに対する認証ポリシーの定義」に進みます。
有効な管理者の資格証明を持つユーザーは、既存の認証スキームを表示または変更できます。
ノート:
認証ポリシーに関連付けられている認証スキームを削除しようとすると、関連付けの詳細が表示され、確認を求められます。ポリシーが関連付けられていない場合、スキームは削除されます。
前の項の説明に従って、ターゲット・スキームを検索します。
検索結果のリストで、ターゲット・スキームを選択し、「編集」をクリックします。
編集:
「認証スキーム」ページで、環境に合わせて値を変更します(表22-20)。
「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じます。
デフォルトとして設定: 新しいアプリケーション・ドメインでポリシーを作成する際にこのスキームが自動的に使用されるようにするには、「デフォルトとして設定」ボタンをクリックして「確認」ウィンドウを閉じます。
削除:
この認証スキームを使用しているアプリケーション・ドメインがあるかどうかを確認し、あれば別のスキームを割り当てます。
「認証スキーム」ページを確認してこれが削除するスキームであることを確認し、ページを閉じます。
ナビゲーション・ツリーでスキームの名前をクリックし、ツール・バーの「削除」ボタンをクリックします。
削除を確認します(または確認ウィンドウを閉じます)。
