Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11gリリース2 (11.1.2.2) for All Platforms B69533-09 |
|
前 |
次 |
この章では、管理者が共有ポリシー・コンポーネントを管理する方法について説明します。この章の内容は、次のとおりです。
この章で説明するアクティビティを実行する前に、第18章「Access Managerでのシングル・サインオンの理解」に記載されている情報を確認することをお薦めします。さらに、Oracle Access Managementコンソールおよび少なくとも1つのOAMサーバーがWebLogic Serverドメイン内にインストールされて稼働していることと、Access Managerが稼働しており、登録済エージェントが2つ以上あることが必要です。
この項では、共有ポリシー・コンポーネントを構成するために実行する必要のあるタスクについて説明します。このコンポーネントは、リソースを保護し、シングル・サインオンを可能にするAccess Manager認証ポリシーで使用する必要があります。
この章の説明に従って、必要なリソース・タイプが定義されていることを確認します。
次の説明に従って、エージェントに由来する名前が付けられたホスト識別子の定義がエージェント登録時に作成された(またはユーザーが手動で作成した)ことを確認します。
Access Managerによる資格証明コレクションについて理解します。
複数ステップの認証を可能にする認証プラグインについて理解してから使用します。
認証ポリシーに追加できる認証スキームを作成して管理します(次の項目を参照)。
デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタに独自のグローバル・パスワード・ポリシーを設定します(特に明記しないかぎり、このタスクはECCとDCCの両方に適用されます。わずかな違いについては、説明内に示しています)。
第20章に進み、認証ポリシーを設定します。
この項には次のトピックが含まれます:
リソースをアプリケーション・ドメインに追加する場合、管理者は定義されているリソース・タイプのリストから選択する必要があります。Oracle提供のリソース・タイプには、次が含まれます。
HTTP
wl_authen
TokenServiceRP
管理者はこの他のリソース・タイプを構成でき、Oracle提供とカスタムのどちらのリソース・タイプに対しても操作を定義できます。特定のリソースについて、宣言されている操作の一部またはすべて(後でリソース・タイプに対して定義された新しい操作もすべて含めて)を使用するように定義できます。管理者は、リソースが作成されているカスタム・リソース・タイプまたは操作を削除することはできません。Oracle提供のリソース・タイプおよび操作は、ポリシー・ストア内で読取り専用としてマークされており、削除できません。
注意: リソース・タイプの操作リストは、そのタイプのリソースが存在する場合は、変更できません。 |
表19-1に、リソース・タイプと操作の比較を示します。
表19-1 Access Managerのリソース・タイプの10gとの比較
Access Manager 11g | Oracle Access Manager 10g |
---|---|
HTTP: HTTPプロトコルおよびHTTPSプロトコルで使用されるデフォルトのリソース・タイプ。 HTTPタイプ・リソースをアプリケーション・ドメインに追加する場合、管理者は既存のホスト識別子のリストから選択して、リソースURLを追加する必要があります。 このリソース・タイプは読取り専用です。HTTPリソース・タイプに関連付けられているデフォルト操作を管理者が定義する必要はありません。かわりに、作成されてリソースに適用されるポリシーがすべての操作に適用されます。 操作: Oracle提供のリソース・タイプは読取り専用です。事前定義されている操作が関連付けられています。作成されてHTTPタイプのリソースに適用されるポリシーが、すべての操作に適用されます。
関連項目: 「「リソース・タイプ」ページについて」 |
HTTP: HTTPリソース・タイプは読取り専用です。 操作: Oracle提供のリソース・タイプは読取り専用です。事前定義されている操作が関連付けられています。作成されてリソースに適用されるポリシーが、すべての操作に適用されます。
|
wl_authen: WebLogic認証スキームを表すリソースも読取り専用です(デフォルト操作は変更も削除もできません。) この非HTTPリソース・タイプは、Access Managerが存在しないドメインにWebLogicコンテナでデプロイされているリソースとともに使用できます。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。 wl_authenタイプのリソースには、カスタム・アクセス・クライアントが必要です。 |
N/A |
TokenServiceRP: トークン・サービスのリライイング・パーティを表すリソース。このリソース・タイプの操作は発行です。 |
N/A |
カスタム・リソース・タイプ: 関連付けられたホスト識別子はありません。 カスタムEJBリソース・タイプは、SSO統合に使用するためにオンデマンドに作成できます。 |
EJB: ユーザー認証のためにWebLogicおよびWebSphereにSSOを統合する場合に使用するカスタム・リソース・タイプ。認証中は、ユーザーのグループがフェッチされ、サブジェクト・プリンシパルにロールとして移入されました。その後の認可は、ユーザー・ロールに基づいて、アプリケーション・サーバー内部で実行されました。 リソース操作によって認可がコールされることはありませんでした。 |
非HTTPリソース・タイプに関連付けられたホスト識別子はありません。 非HTTPリソースをアプリケーション・ドメインに追加する場合、管理者はタイプ名をポインタとして「リソースURL」フィールドに入力する必要があります。名前とホスト識別子は一致しません。これは、相対的なHTTP URLではありません。 |
Oracle Access Managementコンソールでは、リソース・タイプは、「ポリシー構成」タブで他のコンポーネントとともに編成されます。ナビゲーション・ツリーには、Oracle提供のリソース・タイプであるHTTP、wl_authenおよびTokenServiceRPが表示されます。
注意: 事前定義済のリソース・タイプは削除できません。鍵のアイコン付きで示される事前定義済の操作は、削除できません。必要に応じて、追加の操作を作成、編集または削除できます。 |
HTTP
というリソース・タイプ(図19-1参照)は、Access Managerで保護され、インターネット・プロトコル(HTTPまたはHTTPS)を使用してアクセスされるWebアプリケーションに使用されます。
図19-2は、 wl_authen
リソース・タイプを示しています。これは、次のいずれかのAccess Manager IDアサーション・プロバイダ構成を使用するFusion Middlewareアプリケーションに使用します。このプロバイダ構成については、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
アイデンティティ・アサータ
Oracle Web Services Managerを使用するアイデンティティ・アサータ
オーセンティケータ機能
図19-3に示すように、TokenServiceRP
リソース・タイプは、トークン・サービス・リライイング・パーティを表します。このリソース・タイプの操作は発行です。詳細は、「TokenServiceRPタイプのリソースの管理」を参照してください。
表19-2に、各リソース・タイプ定義の要素を示します。
表19-2 リソース・タイプの定義
要素 | 説明 |
---|---|
名前 |
必須。最大30文字の英数字の一意の名前。 注: HTTP以外のリソース・タイプ名とホスト識別子は一致しません。 |
説明 |
オプション。このフィールドを使用して、このリソース・タイプの目的を最大200文字の英数字で説明します。 たとえば、WebLogic認証スキームを表すリソースなどです。 |
操作 |
オプション。特定のリソースを制御するポリシーは、そのリソースに定義されている、指定されたすべての操作に適用されます。このリソース・タイプに文字列として操作を追加(または削除)して、アプリケーション・ドメイン内でこのタイプのリソースを定義すると、操作が使用可能になります。リソース・タイプに追加できる操作の数に制限はありません。
リモート登録: 自動ポリシー作成時に、指定された操作がサポートされます。自動ポリシー作成時に何も操作が指定されていない場合は、そのタイプに対して定義されたすべての操作がサポートされます。 移行: Access Manager 11.1.2へのアップグレード(10gまたは11.1.1.3または11.1.1.5のいずれかから)の実行中、リソース定義およびHTTPデフォルト操作は自動的に処理されます。ただし、10gで提供されていたEJBカスタム・リソース・タイプは現在Oracleから提供されていないので、それに変わるカスタム・リソース・タイプを作成する必要があります。次を参照してください。 |
次に、リソース・タイプの作成、変更および削除方法を説明します。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して定義されているリソース・タイプを検索できます。
リソース・タイプを検索するには、次の手順を実行します。
Oracle Access Managementコンソールで、「リソース・タイプ」をクリックします。
検索タイプ・リストから「リソース・タイプ」を選択し、検索するリソース・タイプの名前を(ワイルド・カード(*)の使用は任意)入力して、「検索」をクリックします。例:
h*
または、目的のアプリケーション・ドメインに移動して、「リソース」ノードを開いてドメインのコントロールを表示し、リストからリソース・タイプを選択してから「検索」をクリックします。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集または表示: ツール・バーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
列の並替え: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して事前定義のリソース・タイプを作成できます。たとえば、わずか1つまたは2つ(またはそれ以上)の操作に適用されるカスタム・リソース・タイプを定義できます。定義されているカスタム・リソース・タイプは、リソースを認証ポリシーまたは認可ポリシーに追加する際に、デフォルト・リソース・タイプとともにリストに表示されます。
カスタム・リソース・タイプを作成するには:
Oracle Access Managementコンソールで、「リソース・タイプ」をクリックします。
「追加」(+)ボタンをクリックします。
次の情報を入力します。
名前: このリソース・タイプを識別する一意の名前。
説明: オプション。
操作: 「操作」表で「+」をクリックし、表示されるフィールドに操作名を入力します。必要に応じて手順を繰り返して、このリソース・タイプのすべての操作を定義します。
表の再構成: 「表示」メニュー項目を選択して、結果表の表示を変更します。
「適用」をクリックして、このカスタム・リソース定義を送信します。
「ポリシー・リソース定義の追加および管理」の説明に従って、このリソース定義をアプリケーション・ドメインに追加します。
この項では、ホスト識別子とその使用方法およびホスト識別子の作成、変更または削除方法を説明します。ここでのトピックには次が含まれます:
Access Managerポリシーは、コンピュータ・ホストのリソースを保護します。Access Managerでは、コンピュータ・ホストは、ホスト識別子を使用して個別に指定されます。
表19-3は、従業員がアクセスできるWebサーバーの異なるホスト名を示しています。これらの名前すべてを使用して単一のホスト識別子を作成すると、ユーザーのアクセス方法に関係なくアプリケーションを適切に保護する1つのポリシー・セットを定義できます。
表19-3 ホスト識別子の例
ホスト識別子のサンプル | 説明 |
---|---|
hrportal.intranet.company.com |
従業員が覚えやすい名前。これはロード・バランシングされたプロキシで、このリクエストによってHRアプリケーションをホストするいくつかのサーバーのいずれかを実際に利用できます。 |
hr-sf-02.intranet.company.com |
直接アクセスできるアプリケーションをホストする単一のマシン。 |
hrportal.company.com |
以前の従業員の福利厚生や401k情報などの確認に主に使用するため、同じアプリケーションで企業ファイアウォールの外部にもアクセスできます。また、これはロード・バランシングされたリバース・プロキシです。 |
定義されたホスト識別子に基づいて、管理者は特定のリソースをアプリケーション・ドメインに追加し、ポリシーを適用してそれらのリソースを保護できます。
登録されたエージェントは、ポリシーで使用されるホスト識別子に定義されたアドレス指定方法と一致するすべてのリクエストを保護します。リストのアドレスに送信されたリクエストが公式のホスト名にマップされるので、Access Managerはリソースを保護するポリシーを適用できます。
Oracle Access Managementコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。アプリケーションおよびリソースがマップされたホスト識別子のないホストに存在する場合、管理者はホスト識別子を手動で追加できます。また、Oracle Access Management管理者は、新しいホスト名バリエーションに追加するために既存のホスト識別子を変更できます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加するには、新しいホスト名バリエーションが必要です。
詳細な情報は、次を参照してください:
設計時に、特定のアプリケーション・ドメインに属するリソースを定義する場合、ホスト識別子を使用できます。リソースのホスト識別子(HTTP)またはタイプ(HTTP以外)を使用して、リソースをスコープします。この組合せにより、それらはAccess Manager全体で一意に識別されます。
注意: 各リソースは、すべてのアプリケーション・ドメインで一意である必要があります。各リソースおよびホスト識別子の組合せは、すべてのアプリケーション・ドメインで一意である必要があります。 |
実行時の使用方法
実行時に、OAMエージェントからのアクセス問合せのWebサーバー・ホスト情報がホスト識別子にマップされ、ユーザーがアクセスしているリソースに関連付けられます。OAMエージェントは、次のどちらかの方法でWebサーバー・ホスト情報を取得します。
仮想Webホスト・サポートに優先ホスト・パラメータが構成されている場合(「仮想Webホストについて」を参照してください)、指定されたリクエストのWebサーバー・ホスト情報がWebサーバーから取得されます。
優先ホスト・パラメータで直接Webサーバー・ホスト情報を指定する場合、Webサーバー固有のホスト情報と関係なく常に使用されます。
これにより、Webサーバーの現在のデプロイメントと一致するホスト名ではなくホスト識別子の論理ホスト名でリソースを指定できます。
たとえば、aseng-wiki
にアクセスするユーザーは、次を入力します。
http://example-wiki.uk.example.com/wikiexample
ここで、wikiexampleはリソースURL、example-wiki.uk.example.comはホストです。このホストおよびポート(ポートは80)を照合して、ホスト識別子を示します。
優先ホスト
通常、OAMエージェントの優先ホスト文字列を設定して、Webサーバー・ホスト情報を取得します。エージェントが複数の仮想ホストをアクティブに保護する場合、この文字列をserver_name
に設定して、実際のリクエスト・ホスト名がWebサーバーのリクエスト・オブジェクトから正しく選択されていることを確認します。詳細は、「仮想Webホストについて」を参照してください。
ホストの認証および認証スキームのチャレンジ・リダイレクト
ユーザーが保護されたリソースURLにアクセスしようとすると、認証スキームの「チャレンジ・リダイレクト」フィールドに指定されたサーバーにリダイレクトします。認証チャレンジを別のホストで処理する場合、そのホストの名前を定義して、「ホスト識別子」リストで使用可能にする必要があります。たとえば、ユーザーが認証用のSSL対応サーバーにリダイレクトすると、ホスト識別子としてそのサーバーを定義する必要があります。
注意: 認証スキームの「チャレンジ・リダイレクト」フィールドにホスト名を入力する場合、ホスト識別子として定義する必要があります。 |
各ホスト識別子を定義して、1つ以上のWebサーバー・ホストを表すことができます。ホスト識別子のいくつかの重要なガイドラインは、次のとおりです。
各ホスト名を一意にする必要があります。
各ホスト名:ポート・ペアを一意にする必要があります。
各ホスト名:ポート・ペアは、1つのホスト識別子にのみ属する必要があります。
各ホスト名:ポート・ペアは、エンド・ユーザーのエントリと完全に一致する必要があります。
ホスト識別子名とHTTP以外のリソース・タイプ名は一致しません。
各リソースおよびホスト識別子の組合せをすべてのアプリケーション・ドメインで一意にする必要があります。
詳細は、「ホスト識別子のバリエーション」を参照してください。
すべての使用可能なホスト名バリエーションを定義してWebサーバー・ホストのアイデンティティを簡易化するには、ホスト識別子を使用します。ホスト識別子は、すべてのURLアドレス指定方法のリストで構成されます。ホスト識別子は、Access Managerで保護するWebサイトまたは仮想Webサイトごとに構成する必要があります。
Access Managerに対してWebサーバー・ホストを指定する場合、コンピュータ名やIPアドレスを指定するなど、様々な方法があります。次に、同じホストのアドレス指定方法の例を示します。
example.com
example.com:80
www.example.com
www.example.com:80
216.200.159.58
216.200.159.58:80
複数のWebサイトとドメイン名を含むWebサーバー上にWebgateをインストールできます。Webgateは、サーバー上のすべてのWebサイトを保護できる場所にインストールする必要があります。
注意: この情報は、11gおよび10g Webgateで共通です。 |
多くのWebサーバーに対する仮想Webホスティング機能を使用すると、複数のドメイン名およびIPアドレスをサポートでき、各サーバーが単一の仮想サーバー上にある一意の各サブディレクトリに解決されます。たとえば、それぞれ独自のドメイン名と一意のサイト・コンテンツを持つabc.comとdef.comを、同じ仮想サーバー上でホストできます。名前ベースまたはIPベースの仮想ホスティングが可能です。
仮想ホストは、複数のNICカード(IPベース)または複数の名前(同じIPを解決するabc.comやdef.comなど)に基づいて使用される複数のサイトが同じホストに存在する状況を示します。
次に示すように、OAMサーバーのリバース・プロキシとして動作するOHSサーバーに構成される2つの仮想ホストが存在するケースを検討します。
1つの仮想ホストが双方向SSLモードで構成されています。
1つの仮想ホストが非SSLモードで構成されています。
異なる認証スキームで保護される2つのリソースとアプリケーション・ドメインがあると仮定します。
/resource1は、チャレンジURL(資格証明コレクションURLを定義するため)のhttps://sslvhost:port/を使用するX509Schemeで保護されます。
ユーザーが/resource1にアクセスすると、認証用のSSLポートのOHSサーバーにリダイレクトされ、X.509証明書を求められます。
/resource2は、チャレンジ・リダイレクトのhttp://host:port/を使用する2番目の仮想ホストのLDAPSchemeで保護されます。
ユーザーが/resource2にアクセスすると、非SSLモード(または必要に応じて一方向SSLモード)の2番目の仮想ホストにリダイレクトされます。LDAP認証のログイン・フォームが表示されます。
注意: 10g mod_ossoを使用したX.509およびフォーム認証がデプロイメントでサポートされます。ただし、1つのSSOサーバーにのみ、mod_ossoを構成できます。この場合、エージェントは、非SSL仮想ホスト上のAccess Managerにリダイレクトします。資格証明コレクタは、リソースの認証スキームのチャレンジURLパラメータを確認し、X509認証のHTTPS仮想ホストにリダイレクトします。 |
10g Webgateをリバース・プロキシとともに、Access Managerに対して使用できます。この項では、この戦略の長所と短所について説明します。
長所:
リクエストがすべてプロキシを経由するかぎり、すべてのWebコンテンツを単一の論理コンポーネントから保護できます。
これは、Access Managerによってサポートされないプラットフォームにも当てはまります。様々なプラットフォーム上(Windows XPやLinuxなど)で、異なるタイプのWebサーバー(iPlanetやApacheなど)が使用されていても、これらのサーバー上のすべてのコンテンツを保護できます。リバース・プロキシはサポートされていないWebサーバーに対する回避策となり、サポートされていないWebサーバーやWebgateをサポートしないプラットフォーム(MacOSなど)用に独自のアクセス・クライアントを記述する必要がなくなります。
リバース・プロキシを使用することで、アーキテクチャが柔軟になります。
リバース・プロキシを使用すると、イントラネットで使用可能なアプリケーションをデプロイしてエクストラネットに公開できるようになります。また、エクストラネットで使用可能なアプリケーションをイントラネットに公開することもできます。これらのことは、すでにデプロイされているアプリケーションを変更することなく行うことができます。
リバース・プロキシに1つのWebgateをインストールするのみで、各Webサーバー上にインストールする必要がなくなります。
これによって、管理ポイントが単一になり、システムの管理が容易になります。他のWebサーバーにフットプリントを確保しなくても、リバース・プロキシを経由することで、すべてのWebサーバーのセキュリティを管理できます。
短所: プロキシ使用の主な短所は、設定時に必要な作業が増えることです。リバース・プロキシの背後にあるWebサーバーにWebgateをデプロイする場合は、次の構成要件を満たす必要があります。
認証にリバース・プロキシを使用するすべてのWebサーバーが、リバース・プロキシからのリクエストのみを受け付けるようにします。
また、このWebサーバーにデプロイされたWebgateを、Webgateのフロントエンドであるリバース・プロキシ・サーバーからのリクエストに対してIP検証を施行しないように構成する必要もあります。これは、IP検証リストに、リバース・プロキシ・サーバー(1つまたは複数)の既知のIPアドレスを構成することによって行います。WebgateのIP検証を無効にする方法でも同じ結果が得られますが、セキュリティ上のリスクがあるためにお薦めできません。通常は、サーバーにACL文を追加することによって、Webサーバーがリバース・プロキシからのリクエストのみを受け付けるように構成します。これにより、ユーザーがリバース・プロキシをバイパスして制限付きコンテンツに直接アクセスしないようにします。
Policy Managerに構成された仮想ホストを更新し、アクセス・システムがリバース・プロキシに送信されたリクエストを捕捉できるようにします。
バックエンド・システムを直接ポイントするURLをユーザーが入力してプロキシを迂回することを防止します。
この問題の発生を防止するには、Webサーバーのアクセス制御リストまたはファイアウォール・フィルタを使用します。
すべてのユーザー・リクエストがプロキシによって処理されるため、負荷を処理するのに十分な数のプロキシ・サーバーをデプロイする必要があります。
既存のすべてのURLをリバース・プロキシ・サーバーのホスト名およびポート番号にリダイレクトします。
このため、リンク切れなどを防ぐため、絶対パスによるHTMLリンクを防止するためのコンテンツの検査および書換えを実行するようにリバース・プロキシを構成することが必要になる場合がよくあります。これはほとんどのリバース・プロキシで可能であり、またアクセス・システムとは無関係に構成できます。
フロントエンド・アプリーケーションに対して公開するURLリンクには相対URL (../../sub-path/resource)のみを使用し、絶対URL (http://example.com:[port]/path/resource)は使用しないことをお薦めします。
絶対URLは、リバース・プロキシの背後にデプロイされると、エンドユーザーのブラウザ上ではリンク切れになる可能性があります。
10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。
Apacheベースのサーバー以外のほとんどのWebサーバーでは、「優先ホスト」の値をHOST_HTTP_HEADERに設定する必要があります。これにより、ユーザーのブラウザからリクエストが送信されると、Webgateにより、「優先ホスト」の値がリクエストのホスト値に設定されます。たとえば、次に示すように、ユーザーがURLに文字列example2を入力したとします。
http://example2
Webサーバーで、いずれかのWebサイトのホスト名がexample2
であれば、その一致する仮想サイトでリクエストが処理されます。
展開された10g Webgate登録ページの「優先ホスト」フィールドで、次のように入力します。
HOST_HTTP_HEADER
IIS仮想ホスティング: IISコンソールから、各仮想Webサイトを構成して次のフィールドを含める必要があります。
ホスト・ヘッダー名
IPアドレス
ポート
10g Webgateの登録ページで、「仮想ホスト」チェック・ボックスが選択されていることを確認します。
ApacheベースのWebサーバー(Apache、Apache 2、IBM HTTP Server、Oracle HTTP Serverなど)では、「優先ホスト」の値をSERVER_NAMEに設定する必要があります。
注意: SERVER_NAME値は、Apacheベースのサーバー以外のホストでサポートされません。この値をApacheベース以外のサーバーに設定すると、ユーザーはそのWebサーバーのWebgateで保護されるリソースにアクセスできません。かわりに、ユーザーはWebgate構成が正しくないことを示すエラーを受け取ります。
|
シングル・サインオンでApacheベースのリバース・プロキシを使用する場合、Webサーバーの構成ファイル(httpd.configなど)でApacheサーバーで実行するWebサイトを指定します。この設定は、グローバルにしてすべてのWebサイトで有効にすることも、ローカルにしてそのWebサイトのみで有効にすることもできます。指定したサイトに関連付ける参照をAccess Managerがhttpd.configファイルからロードする際、仮想ホスト、特定のディレクトリまたはファイルに限定することができます。
Webgateを特定のターゲットに関連付けるには、次のディレクティブをhttp.confファイルに移動します。
AuthType Oblix require valid-user
これらのディレクティブを、ApacheがリクエストのたびにWebgateを使用するように指示するブロックの中に置きます。また、これらのディレクティブを、Webgateがコールされるタイミングを制限するブロックに移動することもできます。次に、LocationMatch
ディレクティブを、VirtualHost
ディレクティブの後に置く例を示します。
DocumentRoot /usr/local/apache/htdocs/myserver ServerName myserver.example.net AuthType Oblix require valid-user
LocationMatch
ブロックをVirtualHost
ディレクティブに移動した後は、Webゲートはその仮想ホストに対してのみ動作します。LocationMatch
ブロックは、必要な数の仮想ホストに対して追加できます。次に、1つの仮想サーバーの保護方法の例を示します。
ServerAdmin webmaster@example.net DocumentRoot "Z:/Apps/Apache/htdocs/MYsrv" ServerName apps.example.com ProxyRequests On SSLEngine on SSLCACertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/intermediateca.cer SSLCertificateFile Z:/Apps/sslcert_exampleapps_ptcweb32/sslcert_myapps_ptcweb32.cer SSLCertificateKeyFile Z:/Apps/sslcert_exampleapps_ptcweb32/sslcert_myapps_ptcweb32.key ErrorLog logs/proxysite1_log CustomLog logs/proxysite1_log common ProxyPass /https://apps.example.com/ ProxyPassReverse /https://apps.example.com/ ProxyPass /bkcentral https://apps.example.com/bkcentral ProxyPassReverse /bkcentral https://apps.example.com/bkcentral ProxyPass /NR https://apps.example.com/NR ProxyPassReverse /NR https://apps.example.com/NR AuthType Oblix require valid-user #*** BEGIN Oracle Access Manager Webgate Specific **** LoadModule obWebgateModule Z:/apps/Oracle/WebComponent/access/oblix/apps/webgate/bin/webgate.dll WebgateInstalldir Z:/apps/Oracle/WebComponent/access WebgateMode PEER SetHandler obwebgateerr SSLMutex sem SSLRandomSeed startup builtin SSLSessionCache none SSLLog logs/SSL.log SSLLogLevel info # You can later change "info" to "warn" if everything is OK
Oracle Access Managementコンソールまたはリモート登録ツールでエージェント(およびアプリケーション)が登録されると、ホスト識別子が自動的に作成されます。エージェントに登録されるアプリケーション・ドメインでは、ホスト識別子が自動的に使用されます。
管理者はコンソールを使用して、ホスト識別子を作成および管理できます。Oracle Access Managementコンソール内で、ホスト識別子は、「ポリシー構成」タブのナビゲーション・ツリーの「共有コンポーネント」に編成されます。管理者は、新しいホスト識別子定義の手動の作成、定義の変更、定義の削除またはテンプレートとして使用する既存の定義のコピーを実行できます。コピーの名前は、元の定義名に基づきます。たとえば、host3という定義をコピーする場合、コピー名はcopy of host3になります。
図19-4は、コンソールの通常のホスト識別子構成ページを示しています。ここでは、ホストの正規の名前およびユーザーが同じホストを表現できる他のすべての名前を入力します。
注意: 各ホスト識別子を一意にする必要があります。同じホスト名およびポートは他のホスト識別子定義で使用できません。 |
表19-4は、ホスト識別子の定義を示しています。
表19-4 ホスト識別子の定義
プロパティ | 説明 |
---|---|
名前 |
この定義の一意の名前。大文字および小文字の英字のみ使用します。句読点および特殊文字は使用できません。 |
説明 |
この構成の使用を示す200文字までのオプションの説明。 |
ホスト名のバリエーション |
|
有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を手動で作成できます。マップされているホスト識別子がないホストにアプリケーションおよびリソースを手動で追加した場合に必要になります。エージェントの登録時に「ポリシーの自動作成」を選択すると、この作業は自動的に実行されます。
注意: テンプレートとして使用する既存の定義をコピーする場合、コピーのすべての一意の識別子を変更する必要があります。 |
Oracle Access Managementコンソールで、「ホスト識別子」をクリックします。
「ホスト識別子の検索」ページの右上隅の「ホスト識別子の作成」ボタンをクリックします。
または、「ホスト識別子」ノードを開いて「検索結果」表の上にある「作成」(+)ボタンをクリックします。
新しい「ホスト識別子」ページで、次の内容を入力します。
名前
説明
ホスト名組合せ: 「操作」リストのホスト名とポートのバリエーションを追加(または削除)します。
追加: 「作成」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。
削除: ホスト名をクリックし、「削除」ボタンをクリックして削除します。
必要に応じて手順3cを繰り返して、ユーザーがアクセスできるこのホストのすべてのバリエーションを識別します。
「適用」をクリックして新しい定義を送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じて、新しい定義がナビゲーション・ツリーにリストされていることを確認します。
有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定のホスト識別子を検索できます。
注意: ホスト識別子がリソースに関連付けられている場合、削除しようとすると、アラートが表示され、確認を求められます。関連付けられていない場合、ホスト識別子は正常に削除されます。 |
Oracle Access Managementコンソールで、「ホスト識別子」をクリックします。
「ホスト識別子の検索」ページで、「名前」フィールドに名前(またはワイルド・カード(*)を含む部分的な名前)を入力するか、または「名前」フィールドを空白のままにしてすべてのホスト識別子を表示します。例:
my_h*
「検索」ボタンをクリックして検索を開始し、表に結果が表示されたら、次の操作を実行します。
表示または編集: 「検索結果」表で名前をダブルクリックして構成ページを表示し、通常どおり追加または編集します。
削除: ツール・バーの「削除」ボタンをクリックして、結果表で選択されたアイテムを削除し、「確認」ウィンドウで削除を確認します。
連結解除: ツールバーの「連結解除」ボタンをクリックして、「検索結果」表をページ全体に拡張します(または「表示」メニューで「連結解除」をクリックします)。
列の並替え: 「表示」メニューで「列の並替え」を選択して、表示される矢印を使用して列を並べ替えます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の定義を変更できます。これには、個々のホスト識別子の定義の追加、変更または削除が含まれます。たとえば、異なるホスト名で別のプロキシWebサーバーを追加する場合、既存のホスト識別子定義を変更して新しいホスト名バリエーションを追加する必要がある場合があります。
前提条件: ホスト識別子を参照するインベントリ・アプリケーション・ドメイン
注意: 設定の参照後、ページを閉じるか、必要に応じて設定を変更できます。 |
ホスト識別子を表示または変更するには、次の手順を実行します。
「ホスト識別子定義の検索」の説明に従って、必要なホスト識別子を検索して表示します。
「ホスト識別子」ページで、必要に応じて情報を変更します(表19-4)。
名前
説明
ホスト名組合せ: 表示される表で次の操作を実行します。
ホスト名バリエーションの追加(+): 「追加」(+)ボタンをクリックし、ホスト識別子名にマップする変数を識別するための新しいホスト名とポートの組合せを入力します。
ホスト名バリエーションの削除(X): ホスト名をクリックし、「削除」ボタンをクリックして削除します。
必要に応じて手順3cを繰り返して、バリエーションを追加または削除します。
「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じて、終了する場合はページを閉じます。
有効な管理者の資格証明を持つユーザーは、次の手順を使用してホスト識別子の全体の定義を削除できます。リソースで使用されているホスト識別子を削除しようとすると、検証エラーが発生します。
注意: ホスト識別子がリソースに関連付けられている場合、アラートが表示されます。関連付けられていない場合、ホスト識別子は削除されます。 |
前提条件
アプリケーション・ドメインの各リソースは、特定のホスト識別子に関連付けられます。ホスト識別子を削除する場合、そのホスト識別子を使用するアプリケーション・ドメインのリソース定義を先に変更する必要があります。
このホスト識別子を使用するアプリケーション・ドメインの関連するリソース定義を検索して変更します。「リソース定義の検索」を参照してください。
「ホスト識別子定義の検索」の説明に従って、必要なホスト識別子を検索します。
表示: 結果表で名前をダブルクリックして構成ページを表示し、削除可能であることを確認します。
削除: ツール・バーの「削除」ボタンをクリックして、結果表で選択されたアイテムを削除し、「確認」ウィンドウで削除を確認します。
Access Managerの認証では、リクエスタ(ユーザー)を一元化されたコンポーネントにリダイレクトする操作が伴われます。このコンポーネント(資格証明コレクタと呼びます)が、認証を実行します。
この項では次のトピックを記載しています:
認証は、ユーザーを証明するプロセスです。Access Managerを使用してユーザーのアイデンティティを認証することは、事前定義された一連のプロセスを実行してユーザーのデジタル・アイデンティティを確認することを示します。
Access Managerを使用すると、認証スキームという単一の認証プロセスでリソースまたはリソースのグループを保護できます。認証スキームは、事前定義済の認証モジュールまたはプラグインに依存します。
この項では、マルチレベル認証およびAccess Managerでサポートされている他の認証方式について説明します。
マルチレベル認証
Access Managerを使用すると、管理者は複数の認証スキームに複数の認証レベルを割り当てて、どのアプリケーションをどのスキームで保護するかを選択できます。各認証スキームに強度レベルが必要になります。この数値が低いほど、スキームが厳密ではなくなります。高いレベルの数値は、よりセキュアな認証メカニズムを示します。
SSO機能により、ユーザーは2つ以上の保護されたリソースまたはアプリケーションにシングル・サインオンでアクセスできます。レベル2のリソースへのアクセスを認証されているユーザーは、2以下のレベルで保護されたリソースにアクセスできます。ただし、ユーザーがレベル2のリソースのアクセスを認証され、レベル3で保護されたリソースにアクセスする場合、ユーザーの再認証が求められます(これはステップアップ認証と呼ばれます)。
詳細は、「マルチレベル認証およびステップアップ認証について」を参照してください。
マルチステップ認証
マルチステップ認証には、複数の認証プラグインで構成されるカスタム認証モジュールが必要になります。このモジュールは、ログイン処理時に、バックエンドの認証スキームに情報を複数回伝送します。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。
「単純フォーム認証とマルチファクタ(マルチステップ)認証の比較」を参照してください。
Windowsネイティブ認証
統合Windowsネイティブ認証は、OSSOおよびWebgateの両方によって保護されているアプリケーションでサポートされています。この形式の認証は、Kerberos認証モジュールに依存しています。詳細は、第50章「Windowsネイティブ認証のためのAccess Managerの構成」を参照してください。
他の認証タイプ
次のような、Oracle Fusion Middlewareアプリケーションに必要な認証機能がサポートされています。
一般的にユーザー名およびパスワードを使用して証明書を使用しない弱い認証
サード・パーティのセルフサービス・ユーザー・プロビジョニングの自動ログイン
ユーザー・コンテキスト情報のHTTPヘッダー・サポート。たとえば、ホスト識別子を使用してリソースのホスト・コンテキストを作成します。これは、異なるコンピュータで同じURLパスを使用するリソースを追加する場合に役立ちます。
2つのWebGateの異なる認証スキームを使用する場合、ユーザーは再認証なしで高い認証スキームから低い認証スキームに移行できますが、低い認証スキームから高い認証スキームには移行できません。
注意: シングル・サインオンの実行中、ユーザーが認証テストに成功しても、2番目または3番目のリソースにアクセスする際に認可テストに失敗する場合があります。ドメインの各リソースに一意の認可ポリシーが存在する場合があります。 |
Access Managerを使用した認証スキームの構成および使用の詳細は、「認証スキームの管理」を参照してください。
Access Manager 11.1.2は、デフォルトで埋込み資格証明コレクタ(ECC)をサポートします。さらに、最新のWebゲートを外部資格証明コレクタ(DCC。認証Webゲートと呼ぶこともあります)として使用するように構成することもできます。
DCCは、デフォルトの埋込み資格証明コレクタ(ECC)よりも安全性が高いと考えられます。集中DCCは、ログイン・ページを提示してユーザーの資格証明(ユーザーIDやパスワードなど)を収集し、バック・チャネルのOracle Accessプロトコル(OAP)を使用してこれらをOAMサーバーに送信します。DCCを使用すると、追加の資格証明が要求されることがあります。
OAMサーバーがDCCを使用するように構成されている場合、ECCとそのHTTPエンドポイントは無効になります。唯一のHTTP通信は、OAMサーバーがデプロイされているドメイン内のWebLogic AdminServerでホストしているOracle Access Managementコンソールに対する通信です。AdminServerへの接続は、ネットワーク・レベルで制御できます。たとえば、内部ネットワークの外部からの管理リクエストを禁止できます。
ECCとDCCの共存を許可すると、ECCまたはDCCで使用するように構成した認証スキームとポリシーを使用できるようになります。これにより、Oracle Access Managementコンソールを含むECCに依存するリソースにフォールバック・メカニズムを使用できるようになります。
ECCを無効にする(オフにする)と、Oracle Access Managementコンソールを含むECCメカニズムに依存するリソースへのアクセスを、完全に禁止することになります。
埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)には、本質的な違いはありませんが、これらの比較を表19-5に示します。
表19-5 DCCとECCの比較
DCC | ECC | |
---|---|---|
デプロイメント |
外部資格証明コレクタは、サーバーの論理部分に存在し続けて、OAMサーバーのフロント・チャネル通信のエンドポイントとして機能します。ただし、DCCは次のようにも構成できます。
|
埋込み資格証明コレクタは、OAMサーバーとともにデプロイされ、このサーバーに統合され、プロトコル・バインディング・レイヤーの一部になります。 ECCは、RSA SecurIDパスコードの検証、次回のトークンの取得、新規PINの作成ワークフローをサポートします。 |
DMZデプロイメント |
可能。 DMZでDCCを使用するデプロイメントの場合、エンド・ユーザーのネットワーク接続が公衆回線網内で終了し、OAMサーバーには相互認証された接続でOracle Accessプロトコル(Oracle独自のアプリケーション・ネットワーク・プロトコル)を使用して接続するという利点があります。これにより、OAMサーバーは完全に分離され、非認証ネットワーク接続が確立することはありません。 非認証ユーザーは、不正なリクエストをOAMサーバーに送信できません。 |
不可。 |
通信チャネル |
DCCは、ユーザーからのHTTP/HTTPSリクエストを利用して、SSLに対応できるOracle Accessプロトコル(バック・チャネル)を通じてOAMサーバーと通信します。 |
ECCは、HTTP/HTTPSを通じてユーザーとOAMサーバーの両方と通信します。 |
DCCログイン、エラーおよびパスワードのページ |
DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。Webgateホストの$
注: 関連項目: 表19-31「資格証明コレクタのパスワード・ページ」。 この実装のログイン・ページの詳細は、第49章「RSA SecurID認証とAccess Managerとの統合」を参照してください。 ページおよびメッセージのカスタマイズの詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。 |
ユーザーが資格証明を入力するページです。OAMサーバーにデフォルトで付属し、追加の設定や変更は必要ありません。
|
DCCベースのログインおよびログアウトを行うPerlスクリプト |
DCCベースのログインおよびログアウトを行うPerlスクリプト Perl実行ファイルのパス名は、Webgateホストの Unix: which perl /usr/bin/perl ただし、perlスクリプト自体では次の場所が参照されています。 /usr/local/bin/perl Windows: Oracle提供のPerlスクリプトで指定されているデフォルトのPerlインタプリタは使用できません。これらのスクリプトのPerlインタプリタのパスを、ご使用のシステムの実際のPerlへのパスに更新する必要があります。 |
N/A |
パスワード・ポリシーの強制 |
可能。 |
はい 関連項目: 「グローバル・パスワード・ポリシーの管理」 |
認証スキームのコレクション・メソッド |
DCCはフォーム・ベースの認証のみサポートします。 |
ECCはすべてのチャレンジ・メソッドをサポートしています。 ECCは、認証スキームのチャレンジ・メソッドに基づいてユーザーの資格証明を収集し、その資格証明を検証するためにOAMサーバーに送り返します。 |
カスタム認証プラグインとチャレンジ・メソッド |
可。ECCと同じです。 |
すべてのチャレンジ・メソッドとマルチステップ認証(パスワード・ポリシーと、その他のカスタム認証プラグイン)がサポートされます。 |
シングル・ステップ(単純フォーム)認証 |
可。ECCと同じです。 |
可能。次の場合、DCCとECCの両方がこれを処理ます。
|
マルチステップ認証 |
可能。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、繰返しおよび変数)の認証プロセスを処理します。 この場合、次のようになります。
|
可能。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、繰返しおよび変数)の認証プロセスを処理します。 |
認証処理 |
ECCと比較すると、DCCがOAMサーバーの認証機能を制限することはありません。 DCC:
|
認証時:
|
ECCのオーバーライド |
DCCをデプロイしてECCを無効にする場合、管理者は次のタスクを実行して、関連するDCC URLとフォームを指定する必要があります。
|
N/A |
ログアウト構成 |
||
Cookie/トークン |
|
|
管理イベント以外に、認証の成功および失敗イベントが監査されます。監査には、認証スキーム、モジュールおよびポリシーの作成、変更、表示および削除が含まれます。認証するユーザーに関して収集される情報は、次のとおりです。
IPアドレス
ユーザー・ログインID
アクセスの時間
ロギング(または監査)中、ユーザー情報およびユーザー機密属性は記録されません。誤用を避けるためにセキュアなデータ(ユーザー・パスワードなど)が削除されます。
Access Managerでは、各認証スキームに認証モジュールが必要です。
注意: ネイティブ認証モジュールには、指定された認証ニーズを満たすように複数のプラグインを編成するための柔軟性がありません。したがって、ネイティブ認証モジュールは今後のリリースで非推奨の対象となります。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースの認証モジュールを使用することを強くお薦めします。 |
この項では次の情報を提供します:
表19-6に、Access Managerネイティブ認証モジュールを示します。
表19-6 ネイティブ認証モジュール
モジュール名 | 説明 |
---|---|
LDAP |
リソースをリクエストしたユーザーの資格証明(ユーザー名およびパスワード)を、LDAPディレクトリ・サーバーに格納されているユーザー定義と比較します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。 関連項目: ネイティブのLDAP認証モジュール. |
LDAPNoPasswordAuthModule |
リソースをリクエストしたユーザーの資格証明(ユーザー名およびパスワード)を、LDAPディレクトリ・サーバーに格納されているユーザー定義と比較します。LDAPモジュールは、Basicおよびフォーム・チャレンジ・メソッドに必要です。 関連項目: ネイティブのLDAP認証モジュール. |
Kerberos |
キー・タブ・ファイル名、krb5.configurationファイル名およびプリンシパルを指定します。 第50章の説明に従い、Windowsネイティブ認証用にAccess Managerを構成するときには、このプラグインを使用します。 関連項目: 「ネイティブのKerberos認証モジュール」 |
X509 |
LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示す追加プロパティを使用するLDAPPluginに似ています。 関連項目: ネイティブのX509認証モジュール。 |
カスタム認証モジュール |
このタイプのモジュールは、バンドルされているプラグイン(またはAccess Manager認証拡張機能Java APIを使用して開発されたプラグイン)に依存しています。このタイプのモジュールは、通常、複数のプラグインを使用します。これらのプラグインは、各プラグインが固有の認証機能を実行することが保証されるように編成できます。各プラグインに定義されている成功アクションまたは失敗アクションに応じて、別の認証プラグインがコールされます。 関連項目: 「マルチステップ認証のプラグイン・ベースのモジュールについて」および『Oracle Fusion Middleware Oracle Access Management開発者ガイド』(カスタム・モジュールを使用するスキーム、カスタム認証モジュールおよびプラグインの開発とデプロイの詳細)。 |
関連項目:
|
事前構成済Kerberos認証モジュールを図19-5に示します。詳細は、図の後に説明します。
表19-7は、ネイティブのKerberos認証モジュールの定義を示しています。既存の事前構成済Kerberos認証モジュールを使用するか、独自のモジュールを作成できます。
表19-7 ネイティブのKerberos認証モジュールの定義
要素 | 説明 |
---|---|
名前 |
大文字および小文字の英字、数値および空白を使用できるこのモジュールの一意のID。 |
キー・タブ・ファイル |
キー配布センター(KDC)の認証に必要となる、ホストのキーの暗号化されたローカルのディスク上のコピーへのパス。たとえば、/etc/krb5.keytabなどです。 KDCは、リクエストしているユーザーを認証し、ユーザーにリクエストされたサービスのアクセスが認可されていることを確認します。認証されたユーザーがすべての所定の条件を満たしている場合、KDCはサーバー・キーに基づくアクセスを許可するチケットを発行します。クライアントはチケットを受け取り、適切なサーバーに送信します。サーバーは、送信されたチケットを確認し、送信したユーザーにアクセス権を付与できます。 キー・タブ・ファイルは、rootによってのみ読取り可能であること、およびマシンのローカル・ディスク上に存在することが必要です。バックアップ・データへのアクセスが、マシンのrootパスワード自体へのアクセスと同じくらい厳密に保護されていないかぎり、バックアップの一部にはできません。 |
プリンシパル |
ホストのキータブの生成を有効化するKerberosデータベースのプリンシパルのHTTPホストを識別します。 |
KRB構成ファイル |
Kerberosインストールの特定の側面を制御する構成ファイルのパスを識別します。krb5.confファイルは、Kerberosを実行している各UNIXコードの/etcディレクトリに存在する必要があります。 krb5.confには、Kerberos V5ライブラリに必要な構成情報が含まれます(デフォルトのKerberosレルムおよび既知のレルムのKerberosキー配布センターの場所)。 |
Oracleでは、次の2つのLDAP認証モジュールを提供しています。
LDAP
LDAPNoPasswordAuthModule
図19-6に示すように、両方のモジュールが同じ要件(「名前」と「ユーザー・アイデンティティ・ストア」)を持っています。詳細は、図の後に説明します。
表19-8は、LDAP認証モジュールの要素を示しています。同じ要素と値がLDAPNoPasswordAuthnModuleでも使用されます。
注意: これらの標準LDAP認証モジュールは廃止対象になっています。将来の拡張機能は、この標準モジュールでは使用できなくなります。Oracleでは、プラグイン・ベースのモジュールの使用を強くお薦めします。 |
表19-8 ネイティブのLDAP認証モジュールの定義
要素 | 説明 |
---|---|
名前 |
このモジュールの一意の名前。 |
ユーザー・アイデンティティ・ストア |
指定されたLDAPユーザー・アイデンティティ・ストアは、このモジュールの認証に必要なユーザー資格証明を含んでいる必要があります。LDAPストアはAccess Managerに登録されていなければなりません。 関連項目: 「OAMアイデンティティ・ストアの管理」 複数のアイデンティティ・ストア・ベンダーがサポートされています。インストール時には、ユーザー・アイデンティティ・ストアは1つのみで、それが指定されたシステム・ストアでもあります。アイデンティティ・ストアを追加し、別のストアをシステム・ストアとして指定する場合には、必ずそのシステム・ストアを参照するようにLDAPモジュールを変更してください。認証スキーム |
Access Managerは、デフォルトとして事前定義済X509認証モジュールを用意しています。管理者は、新しいX509認証モジュールも作成できます。暗号化の表現のX.509は、シングル・サインオン(SSO)に使用されるデジタル公開鍵証明書の標準です。X.509では、特に公開鍵証明書、証明書失効リストおよび属性証明書の標準形式を指定します。
X.509デジタル証明書を使用すると、証明書を発行する認証局(CA)の厳密な階層システムを取得できます。X.509システムで、CAは、特定の識別名または電子メール・アドレスやDNSエントリなどの代替名に公開鍵をバインドする証明書を発行します。
企業のPKIシステムで使用できるように、企業の信頼されたルート証明書をすべての従業員に配布できます。SSL証明書をすぐに使用できるように、特定のWebブラウザは、事前インストールされたルート証明書を用意しています。
Access Managerは、オンライン証明書ステータス・プロトコル(OCSP)インターネット・プロトコルを使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスします。OCSPは、X.509デジタル証明書の失効ステータスの取得に使用されます。OCSPは、証明書ステータスを含むサーバーおよびそのステータスを通知されるクライアント・アプリケーション間で使用される通信構文を指定します。
ユーザーがサーバーにアクセスしようとすると、OCSPは証明書ステータス情報のリクエストを送信します。OCSPは、特定のネットワーク・ホストが特定の時間に特定の証明書を使用していたことをリクエスタに公開します。サーバーは、「current
」、「expired
」、または「unknown
」というレスポンスを戻します。OCSPは、期限が切れた証明書を使用するユーザーに更新前の指定された期間にサーバーにアクセスできる構成可能な猶予期間を与えます。
OCSPメッセージはASN.1で暗号化され、HTTPで一般的に転送されます。OCSPのリクエストおよびレスポンス特性では、OCSPサーバーを参照する場合に「OCSP応答者」という用語を使用します。Access Managerを使用する場合、Oracle Access ManagementコンソールをホストするコンピュータはOCSP応答者です。
OCSP応答者は、リクエストで指定された証明書が適正、失効または不明であることを示す署名されたレスポンスを戻すことができます。OCSPがリクエストを処理できない場合、エラー・コードを戻すことができます。
表19-9は、ネイティブのX509認証モジュールの要件を示しています。
注意: この標準認証モジュールは廃止対象になっています。将来の拡張機能は、この標準モジュールでは使用できなくなります。Oracleでは、プラグイン・ベースのモジュールの使用を強くお薦めします。 |
表19-9 X509認証モジュールの定義
要素 | 説明 |
---|---|
名前 |
一意の名前でこのモジュール定義を識別します。 |
一致するLDAP属性 |
特定の「X509証明書属性」値に対して検索されるLDAP識別名属性を定義します。 たとえば、証明書のサブジェクトEMAILがme@example.comで、それがLDAP属性の"mail"に一致する必要がある場合、LDAP問合せは、me@example.com (cn)という値を持つ"mail"属性をLDAPから検索する必要があります。 デフォルト: cn |
X509証明書属性 |
公開鍵のバインドに使用される証明書属性を定義します(サブジェクト内の属性、証明書から抽出される発行者スコープ。たとえば、subject.DN、issuer.DN、subject.EMAIL)。 関連項目: この表の前半にある「一致するLDAP属性」 |
証明書検証有効 |
X.509証明書の検証を有効化(選択されていない場合は無効化)します。 有効化された場合、OAMサーバーは証明書検証を実行します(OAMサーバーに渡される前にWebLogicサーバーで証明書を捕捉して検証することはありません)。Access Managerが証明書のパス検証をすべて実行します。 |
OCSP有効 |
オンライン証明書ステータス・プロトコルを有効化(選択されていない場合は無効化)します。値は OCSP有効: true 注意: 「OCSP有効」を選択した場合のみ、OCSPサーバー別名、OCSP応答者URLおよびOCSP応答者タイムアウトが必要です。 |
OCSPサーバー別名 |
.oamkeystoreファイルのCA証明書を指すOSCSP応答者の別名--別名およびOSCSP応答者インスタンスの実際のインスタンス名またはIPアドレスのマッピング。 |
OCSP応答者URL |
オンライン証明書ステータス・プロトコル応答者のURLを入力します。たとえば、OpenSSLの応答者URLは次のようになります。 http://localhost:6060 |
OCSP応答者タイムアウト |
証明書の更新前の限定された期間にOAMサーバーにアクセスできる期限が切れた証明書を使用するユーザーの猶予期間を指定します。 |
有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証モジュールを変更できます。これには、既存のモジュール名の変更および他の属性の変更が含まれます。
前提条件
別の認証モジュールを使用するには、変更されるモジュールを参照する各認証スキームを変更します(必要な場合)。
注意: デフォルトでは、LDAP モジュールは、Oracle Access Managementコンソールを保護する認証スキームで使用されます。管理者アクセスの安全を確保するために、LDAP モジュールは、システム・ストアとして指定したユーザー・アイデンティティ・ストアを参照する必要があります。指定したシステム・ストアを変更する場合、新しく指定したシステム・ストアを参照するようにLDAPモジュールも変更する必要があります。 |
認証モジュールを検索、表示または編集する手順
Oracle Access Managementコンソールで、「認証モジュール」をクリックします。
目的の「認証モジュール」ページを開きます。
認証モジュール・ページで、必要に応じて情報を変更します。
「適用」をクリックして変更を送信し、確認ウィンドウを閉じます(または変更を適用しないでページを閉じます)。
「認証スキームの管理」の手順に従って、更新された認証モジュールを認証スキームに追加します(または、このモジュールを参照する各認証スキームで、別の認証モジュールに変更します)。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して認証モジュールを削除できます。
次の手順は、カスタム認証モジュールとネイティブ認証モジュールのどちらを削除する場合でも同じです。
前提条件
削除するモジュールを参照している各認証スキームで、別の認証モジュールを指定します。
認証モジュールを削除するには、次の手順を実行します。
Oracle Access Managementコンソールで、「認証モジュール」をクリックします。
オプション: モジュールを開いて削除するモジュールであることを確認してから、ページを閉じます。
目的のモジュール名をクリックし、「削除」ボタンをクリックします。
削除を確認します(またはモジュールを保持する確認ウィンドウを閉じます)。
認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。認証処理では、1つの認証モジュールを使用して、バックエンド認証スキームに対する情報の要件および転送を制御するルールを定義します。プラグインにより収集され、コンテキストに保存された情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。
注意: カスタム認証モジュールの作成には、認証プラグインを使用するようにお薦めします。 |
この項では次のトピックを記載しています:
関連項目: カスタム認証プラグインを作成する場合は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。 |
単純フォームベースの認証は、デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタと、Access Manager認証メカニズムでユーザー・ログインを処理するWebフォームに依存します。単純フォームベースの認証は、デフォルトであるため、フォームをカスタマイズしないときには、追加の設定は必要ありません。単純フォームベースの認証を使用する場合:
すべての資格証明が1つの単純フォームで提供されます。
資格証明の検証および認証時に、成功または失敗のステータスが返されます。
認証は失敗時、再試行できます。
関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびフォームのカスタマイズの詳細 |
動的なマルチステップ認証のために、Access Managerは、独自にカスタマイズした認証モジュールで設計および編成できる、いくつかのプラグインを提供しています。認証プラグインは、特定のニーズを満たす処理を実現します。
また、管理者はAccess Manager用の複数のユーザー・アイデンティティ・ストアをインストールすることもできます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。各認証プラグインは、別々のユーザー・アイデンティティ・ストアを使用するように構成できます。
DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、反復および変数)の認証プロセスを、次のように処理します。
必要な資格証明が、一度に提供されない場合。
認証ステータスに応じて、PENDING状態になり、予期される資格証明とコンテキスト・データが返され、該当する資格証明が次回に提供されると予期されます。
成功または失敗のステータスが返されるまでは、各中間ステップで認証エンジンに必要な資格証明とコンテキスト・データが送信されます。
認証プラグインは、複数のステップで構成できます。
注意: マルチファクタ認証を使用している場合、認証プロセス中の最後のパスでUserIdentificationPluginを起動する必要があります。 |
表19-10に、これら2つの形式の認証についての詳細を示します。
表19-10 単純フォーム認証とマルチステップ認証
認証方式 | 説明 |
---|---|
フォームベースの簡易認証 |
単純フォームベースの認証は、資格証明コレクタ(ECCおよびDCC)と、Access Manager認証メカニズムを使用してユーザー・ログインを処理するWebフォームに依存します。これはデフォルトであるため、フォームをカスタマイズしないときには、追加の構成は必要ありません。 関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』: ログイン・ページおよびフォームのカスタマイズの詳細 |
マルチステップ認証 |
マルチステップ認証には、複数の認証プラグインで構成されるカスタム認証モジュールが必要になります。このモジュールは、ログイン処理時に、バックエンドの認証スキームに情報を複数回伝送します。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。 マルチステップ認証は、次のものに依存しています。
関連項目: 「DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加」 カスタム認証プラグインの詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。 |
カスタム・プラグイン・ベースの認証モジュールは、この章で説明されているように、既存のAccess Managerを使用して作成できます。Oracle Fusion Middleware Oracle Access Management開発者ガイドの説明に従って、ユーザー独自のプラグインを作成することもできます。
プラグインは、デフォルトの埋込みの資格証明コレクタ(ECC)か、オプションのデタッチされた資格証明コレクタ(DCC対応のWebゲート)のいずれかと連動します。各認証プラグインは個別の機能部分を提供しており、これらは単独で使用するか、一連の手順につなぎ合わせて使用することができます。プラグインのライフサイクルは、プラグインを追加および使用して、OAMサーバーの拡張機能として動作する機能やワークフローを構築できるようにすることに中心が置かれています。各プラグインはJARファイルとしてデプロイされるので、各プラグインの構成要件はXML形式で指定する必要があります。
注意: 標準(ネイティブの)認証モジュールは、非推奨になる予定です。将来の拡張機能は、標準モジュールでは使用できなくなる予定です。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースの認証モジュールを使用することを強くお薦めします。 |
図19-8は、Oracle Access Managementコンソールの「システム構成」タブの「共通構成」セクションから使用できるデフォルトのプラグインを示しています。カスタム認証モジュールを構築するためのステップを追加すると、これらのプラグインと、ユーザーがSDKや使用して作成したりインポートしたプラグインが、リストに表示されます。
一般的に、「名前」によって、プラグインに依存するコンポーネントが定義されます。「説明」はオプションです。「タイプ」列は、プラグインの目的を示しています。「アクティブ化のステータス」によって、このプラグインがアクティブで使用可能かどうかがわかります。
関連項目: ユーザー独自のカスタム・プラグイン構築の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。新しいプラグインをインポートしたり、カスタム・プラグインを配布、アクティブ化、非アクティブ化、削除することができます。 |
Oracle提供のプラグインを使用する場合も、ユーザー独自のプラグインを作成する場合も、カスタム認証モジュールの作成時にプラグインを追加することは同じです。
各カスタム・モジュールには、次のタイプの情報が必要です。
「一般」: 個々のプラグインの一意の名前とオプションの説明を識別します。
「ステップ」: 各プラグインの構成詳細(使用するユーザー・アイデンティティ・ストアを含む)に基づいて、使用する固有のプラグインと、その実行順序を識別します。
「ステップ編成」: 成功時、失敗時、またはエラー時に実行するアクションを指定します。
さらに、マルチファクタ認証を使用している場合、認証プロセス中の最後のパスでUserIdentificationPluginを起動する必要があります。
図19-9に、「システム構成」ツリーの「Access Manager」にある「カスタム認証モジュール」を示します。モジュールごとに、モジュールの情報を入力する3つのサブタブが表示されます。
表19-11は、「一般」タブの内容の説明です。
「ステップ」タブをクリックすると、新しいページが開き、そこで新規ステップを追加できます。新規のステップを追加するときには、次のダイアログ・ボックスが表示されます。ここで入力する情報を使用して、表と、ページの「詳細」セクションにデータが移入されます。
表19-12では、新規ステップの追加に必要な情報について説明します。各ステップに1つのプラグインが必要です。また、各プラグインには、適切な操作のための具体的な詳細が必要です。
表19-12 「新規ステップの追加」のエントリ、ステップの結果表、「詳細」セクション
要素 | 説明 |
---|---|
ステップ名 |
ステップを識別するために入力する一意の名前で、60文字以内です。 |
説明 |
ステップを追加するときにオプションで入力する、このステップの説明(250文字以内)。 |
プラグイン名 |
特定のステップに対して選択するプラグインです。インポートされアクティブ化されているプラグインのリストから選択します。 関連項目: カスタム・プラグインの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。 |
ステップの詳細 |
正しい操作を確実に実行するために、プラグインの構成詳細を指定する必要があります。詳細の内容は、選択したプラグインと、そのプラグインの要件によって異なることがあります。 関連項目: 表19-13 |
表19-13に、Oracle付属のプラグインで必要になるプラグイン・パラメータの詳細を示します。この表に記載されていないプラグインのKerberosTokenIdentifier
、FedAuthnRequestPlugin
およびFedUserAuthenticationPlugin
は、例外的なプラグインです(これらのプラグインには、初期パラメータがありません)。
表19-13 各種プラグインのパラメータの詳細
プラグイン・パラメータ | 表示名 | 説明 |
---|---|---|
KEY_IDENTITY_STORE_REF |
アイデンティティ・ストア名 |
認証時に適切なユーザー・アイデンティティ・ストアが呼び出されるようにするために、ほとんどのプラグインでこの属性が必要になります。 次のプラグインは、このプロパティのみを使用します。
このプロパティを採用するプラグインに必要な追加の詳細は、次を参照してください。
|
CredentialCollectorPlugIn |
CredentialCollectorPlugIn |
このプラグインにより、管理者は、認証用にどの資格証明を収集するかを構成できます。収集される資格証明は、ステップ・パラメータとして構成されます。プラグインは、これらのパラメータを検証して、資格証明を収集するUIを表示します。ユーザーの入力後、資格証明パラメータを解析し、資格証明オブジェクトでユーザー・コンテキストを構築します。 注意: 資格証明が無効で、プラグインが失敗を返した場合、プラグイン・エラー・レスポンスがコンテキストに設定されます。 このプラグインは、ステップ・レベル・パラメータとして4つの資格証明のコレクションをサポートします。
次の例は、ユーザー名とパスワードを収集する方法を示しています。 CRED_PARAM_1= {ID=KEY_USERNAME},{DISPLAY_NAME=KEY_USERNAME},{TYPE=text} {ID=KEY_PASSWORD},{DISPLAY_NAME=KEY_PASSWORD},{TYPE=password} ID、DISPLAY_NAMEおよびTYPEは定数です。 |
Actiontype |
アクション・タイプ |
プラグインが資格証明を収集するログイン・ページにリダイレクト(REDIRECT)するか転送(FORWARD)するかを示します。 |
loginPageURL |
ログイン・ページのURL |
資格証明の収集においてユーザーを転送またはリダイレクトするURL。 |
NO_OF_CREDENTIALS |
プラグイン・インスタンスに対して提供される資格情報の数。インスタンス数が5つ以上ある場合、ユーザーは、oam-configファイルを更新して、プラグイン・パラメータのCRED_PARAMSを追加する必要があります。 |
|
UserIdentificationPlugIn |
UserIdentificationPlugIn |
このネイティブ・プラグインは、ユーザーを特定のLDAPユーザー・レコードにマップします。 |
KEY_LDAP_FILTER |
LDAPフィルタ |
ユーザーを特定するために必要な検索フィルタです。LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。 |
KEY_SEARCHBASE_URL |
LDAP検索ベース |
問合せに必要な検索ベースです。ディレクトリ情報ツリー(DIT)のノードです。このノード以下にユーザー・データが格納されるため、すべてのユーザー・データ検索の最高位のベースになります。 |
UserAuthenticationPlugIn |
UserAuthenticationPlugIn |
このネイティブ・プラグインは、提供されたユーザー名とパスワードの資格証明をLDAPディレクトリに対して認証します。 |
KEY_PROP_AUTHN_EXCEPTION |
LDAPエラーの伝播 |
LDAPエラーの伝播を有効(または無効)にします。UserAuthenticationPlugInは、この属性を採用しています。 |
UserAuthnLevelCheckPlugin |
UserAuthnLevelCheckPlugin |
このネイティブ・プラグインは、ユーザーが認証レベルXに対して認証済かどうかを判断します。このX値は、プラグイン・パラメータAUTHN_LEVEL_FOR_PLUGINによって提供されます。たとえば、指定値で、現在のユーザーの認証レベルをチェックします。加えて、このプラグインは、認証レベル・チェックが成功したか失敗したかに応じて、収集するパラメータのリストを指定します。 |
AUTHN_LEVEL_FOR_PLUGIN |
AUTHN_LEVEL_FOR_PLUGIN |
認証レベルを整数で指定します。 複数のステップの場合はUserAuthnLevelCheckPluginを使用できます。ただし、各ステップに一意の名前とAUTHN_LEVEL_FOR_PLUGINがある必要があります。 関連項目: 「ステップアップ認証の作成と管理」 |
UserPasswordPolicyPlugin |
UserPasswordPolicyPlugin |
|
PLUGIN_EXECUTION_MODE |
操作モード |
プラグイン(UserPasswordPolicyPlugin)の実行モードです。このプラグインは、構成に従って、単独または他のプラグインとともに動作可能です。値は次のいずれかになります。
|
POLICY_SCHEMA |
使用するポリシー・スキーマ |
パスワード・サービス(UserPasswordPolicyPluginで使用)のスキーマを指定します。OAM10Gのみがサポートされています。 デフォルト: OAM10G |
NEW_USERPSWD_BEHAVIOR |
初回ログイン時にパスワードの変更を強制 |
新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。UserPasswordPolicyPluginに使用します。値は、次のどちらかになります。
デフォルト: FORCECHANGEPASSWORD |
DISABLED_STATUS_SUPPORT |
無効化されたアカウント・ステータスのサポート |
無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。 デフォルト: TRUE |
URL_ACTION |
パスワード管理アクションURL |
パスワード管理のために、ユーザーを移動するURLを指定します。ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。
デフォルト: REDIRECT_POST |
FedUserProvisioningPlugin |
||
KEY_USER_RECORD_ATTRIBUTE_LIST |
ユーザー属性のリスト |
フェデレーション用です。ユーザー・レコードの作成に必要なアサーション属性を、カンマで区切ったリストです。 |
KEY_PROVIDERID_ATTRIBUTE_NAME |
パートナ属性名 |
フェデレーション用です。LDAPユーザー・レコードの属性名です。このレコードの値は、ユーザーをプロビジョニングするときにパートナのアイデンティティ・プロバイダIDに設定されます。最初のフィールドはオプションであり、このフィールドを空にすると、パートナのアイデンティティ・プロバイダIDは、LDAPユーザー・レコードに設定されなくなります。 |
KEY_USERID_ATTRIBUTE_NAME |
ユーザーのUserID属性 |
フェデレーション用です。LDAP UserIDとして使用されるアサーション属性の属性名です。 |
TAPIdentifyPlugIn |
||
KEY_TAP_RETURN_ATTRIBUTE |
ユーザー名マッピング属性 |
TAPIdentifyPlugInでアカウントをリンクするために使用する属性の名前です。 |
SequentialPlugInExecutionStrategy |
||
StrategyName |
編成戦略 |
SequentialPlugInExecutionStrategyに必要なプラグイン編成戦略の名前です。 |
KerberosTokenAuthenticator |
||
KEY_KEYTAB_FILE |
キー・タブ・ファイルの場所 |
Kerberosプリンシパルと暗号化されたキーを含むファイルの名前です。これは、KerberosTokenAuthenticatorに必要になります。 |
KEY_PRINCIPAL |
OAMサービス・プリンシパル |
OAMアカウントのSPNです。KerberosTokenAuthenticatorに必要になります。 |
KEY_KRB_CONFIG_FILE |
Kerberos構成ファイルの場所 |
Kerberos構成プロパティ・ファイルの場所です。KerberosTokenAuthenticatorに必要になります。 |
KEY_DOMAIN_DNS2DN_MAP |
ADドメインDNS名のDNへのマッピング |
Active Directory DNSドメインのDNへのマッピングをカンマで区切ったリストです。KerberosTokenAuthenticatorに必要になります。 |
X509CredentialExtractor |
||
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT |
ユーザーのマッピング属性 |
X509証明書属性です。X509CredentialExtractorに必要なユーザー・マッピングに使用します。 |
KEY_IS_CERT_VALIDATION_ENABLED |
証明書検証 |
X.509証明書の検証を有効または無効にします。X509CredentialExtractorに必要になります。 |
TAPRequestPlugin |
||
TAPS2PVersion |
統合プロトコルのバージョン |
統合用のトークン・バージョンです。 |
TAPPartnerId |
統合PartnerId |
統合パートナ識別子です。 |
TAPChallengeURL |
パートナ統合のエンドポイントURL |
リモート・パートナのエンド・ポイントURLです。 |
TAPUserAuthenticationPlugin |
||
KEY_USERNAME_ATTRIBUTE |
ユーザー名マッピング属性 |
アカウントのリンクに使用される属性の名前です。TAPUserAuthenticationPluginに必要になります。 |
KEY_CHECK_TOKEN_EXPIRY |
トークンの有効期限チェックの有効化 |
統合トークンの有効期限を有効または無効にします。 |
TenantDisambiguationPlugin |
||
KEY_FEDERATED_TENANTS |
FederatedTenantNames |
フェデレーテッド認証が有効にされている、オプションの各テナントの名前(カンマ区切り)です。プラグインは、フェデレーション・エンジンにテナントの名前が記述されていないことを問い合せます。 |
RSA SecurIDプラグイン |
||
username |
ユーザー名パラメータ |
ユーザー名プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
passcode |
パスコード・パラメータ |
パスコード・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
nexttoken |
次のトークン・パラメータ |
次のトークン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
newpin |
新規PINパラメータ |
新規ピン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
confirmnewpin |
新規PINの確認パラメータ |
新規pinの確認プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
HTTPTokenExtractor |
||
KEY_HEADER_PROPERTY |
HTTPヘッダー名 |
HTTPヘッダーのカンマ区切りのリストです。第19.7.7項「HTTPTokenエクストラクタ・プラグインの構成」を参照してください。 |
KEY_COOKIE_PROPERTY |
HTTP Cookie名 |
Cookieのカンマ区切りのリストです。第19.7.7項「HTTPTokenエクストラクタ・プラグインの構成」を参照してください。 |
図19-11は、カスタム認証モジュールの「ステップ」サブタブと「詳細」セクションを示しています。ステップを追加する際には、表に表示するデータはありません。ただし、1つ以上のステップを表に追加すると、「詳細」セクションに移入されます。
図19-12は、カスタム認証モジュールの「ステップ編成」サブタブを示しています。このサブタブには、定義された各ステップ(および各操作条件に対して選択したアクション)の情報が移入されます。
表19-14では、「ステップ編成」サブタブの要素について説明します。OnSuccess
、OnFailure
、OnError
で選択できるリストの項目は次のとおりです。
成功
失敗
StepName (モジュールの任意のモジュールを、操作条件のアクションとして選択できます)
表19-14 「ステップ編成」サブタブ
要素 | 説明 |
---|---|
初期手順 |
リストから開始ステップを選択します。リストに含まれるのは、このモジュールに定義されているステップのみです。 |
名前 |
このモジュールに追加された各ステップが、追加するときに入力した名前別にリストされます。 |
説明 |
ステップを追加するときにオプションで入力した、このステップの説明。 |
OnSuccess |
操作が成功した場合に選択されるアクション。選択できるアクションがリストに示されます。
|
OnFailure |
このステップが失敗した場合に選択されるアクション。選択できるアクションがリストに示されます。
|
OnError |
このステップを実行してエラーになる場合に選択されるアクション。選択できるアクションがリストに示されます。
|
図19-13は、現在使用できるネイティブなプラグイン・ベースの認証モジュールのリストです。
次の各項では、事前移入済のプラグインで提供されるネイティブなカスタム・モジュールのいくつかについて説明します。これらを使用すると、独自のカスタム認証モジュールを編成できます。
KerberosPlugin
第50章の説明に従い、Windowsネイティブ認証用にAccess Managerを構成するときには、このプラグインを使用します。
図19-14は、Access Manager 11gにバンドルされているKerberosPluginモジュールを示しています。これはリソースを暗号化された「Kerberosチケット」にリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致する資格証明マッピング・モジュールです。
図19-15は、デフォルトのステップと詳細を示しています。図19-16は、ステップの編成と条件を示しています。
LDAPPlugin
図19-17は、Access ManagerにバンドルされているLDAPPluginモジュールを示しています。デフォルトでは、図19-18のようにLDAPPluginには2つのステップがあります。図19-19は、LDAPpluginのステップのデフォルト編成を示しています。
X509Plugin
図19-20は、Access Manager 11gにバンドルされているX509Pluginモジュールを示しています。X509PluginはLDAPPluginと似ていますが、LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示すプロパティが追加されています。図19-21は、このプラグインのデフォルトのステップと詳細を示しています。図19-22は、X509Pluginのステップのデフォルト編成を示しています。
このプラグインでは、ルートとサブのCA証明書を$DOMAIN_HOME/config/fmwconfig/amtruststoreに追加する必要があります。X509CredentialExtractorプラグインがこの場所から証明書をロードするからです。
表19-15では、stepX509のサブジェクトとサブジェクト代替名の値をリストしています。これらの処理は、X509Pluginの使用時のみサポートされます。
表19-15 X509の「ステップの詳細」(KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT)
issuer.D | サブジェクト |
---|---|
subject. |
EDIPI 注: EDIPIはElectronic Data Interchange Personal Identifierの略です。 |
subjectAltName. |
OTHER_NAME (FASC-N) 注: FASC-NはFederal Agency Smart Credential Numberの略です。 |
subjectAltName. |
RFC822_NAME |
subjectAltName. |
UNIFORM_RESOURCE_IDENTIFIER |
パスワード・ポリシー検証モジュールとプラグイン
Oracleでは、認証プロセスで次のプラグインを個別のステップとして採用するパスワード・ポリシー検証モジュールを提供しています。
ユーザー識別ステップ
ユーザー認証ステップ
ユーザー・パスワード・ステータス・ステップ
図19-23は、「ステップ」タブを示しています。詳細は、図の後に説明します。
図19-24は、パスワード・ポリシー検証モジュールのプラグインの「ステップ編成」ページです。ステップの編成内容は、この図のとおりです。
Access Manager 11gはPIV (Personal Identity Verification)カード(米国連邦政府のスマート・カード)をサポートしており、これは、X.509認証時に、SubjectaltName拡張のFASC-NおよびEDIPI属性を使用してユーザーをマッピングするために使用されます。複数のOCSPプロバイダはサポートされませんが、OCSP Gatewayを使用するか、OSDT OCSP APIを使用するカスタム認証プラグインを作成することで、複数のOCSPプロバイダに対する検証を行うことができます。
次の機能は、X.509プラグイン(X.509認証モジュールではない)のみで使用できます。このプラグイン構成では、X.509クライアント証明書から抽出した属性のマップ先のLDAP属性を指定します。
例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法
Oracle Access Managementコンソールで、「認証モジュール」、「カスタム認証モジュール」および「X509plugin」をクリックします。
「一般」タブ:
名前: CustomX509Plugin。
「説明」: X509のカスタム・プラグイン
「ステップ」タブ:
「+」をクリックして、プラグインにステップを追加します。
「名前」と「説明」を入力して、「X509CredentialExtractor」プラグインを選択します。
「ステップの詳細」:
KEY_IS_CERT_VALIDATION_ENABLED: true
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT (表19-15): subject.EDIPI, subjectAltName.OTHER_NAME (FASC-N), subjectAltName.RFC822_NAME, subjectAltName.UNIFORM_RESOURCE_IDENTIFIER
「Save」ボタンをクリックします。
別のプラグインの追加:
「+」をクリックして、別のプラグインを追加します。
「名前」と「説明」を入力して、UserIdentificationPluginを選択します。
2つ目のプラグインの「ステップの詳細」:
必要なアイデンティティ・ストアに関するKEY_IDENTITY_STORE_REFを設定します。
KEY_LDAP_FILTER属性にLDAPフィルタを追加します。例:
(&(uid= Unknown macro: {subject.CN} )(mail= Unknown macro: {subject.E} ))
必要な場合は、KEY_SEARCH_BASE_URL属性にユーザー検索ベースを追加します。
「Save」ボタンをクリックします。
「ステップ編成」タブ(ステップ2)に進みます。
ステップの編成:
「最初のステップ」: ドロップダウンから「X509CredentialPlugin」ステップを選択します。
「成功時」: 「X509CredentialPlugin」ステップで、ドロップダウン・リストから「UserIdentificationPlugin」を選択します。
「成功時」: 「UserIdentificationPlugin」ステップで、ドロップダウン・リストから「Success」
を選択します。
「失敗時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」
を選択します。
「エラー発生時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」
を選択します。
「適用」ボタンをクリックし、プラグインが正常に作成されたことを示す確認ウィンドウを確認します。
OCSPを使用して、「証明書検証」と「証明書失効」に証明書検証モジュールを設定します。
Oracle Access Managementコンソールで、「証明書検証」をクリックします。
「証明書失効リスト」セクションで、「有効」が選択されていることを確認し、「保存」をクリックします。
「OCSP/CDP」セクションでOCSPを有効にし、OCSPのURLと、OCSPサーバーの証明書のサブジェクトを入力し、「保存」をクリックします。
コマンド行でJavaのkeytoolアプリケーションを使用し、信頼できる証明書のエントリとして$DOMAIN_HOME/config/fmwconfig/amtruststoreキーストアに信頼できる証明書をインポートします。
注意: 初期状態ではキーストアは空です。パスワードは、Java keytoolアプリケーションを最初に使用するときに設定されます。 |
有効な管理者の資格証明を持つユーザーは、次の手順を使用して、1つ以上の認証プラグインを使用するカスタム認証プラグイン・モジュールを作成できます。
この手順は、認証モジュールの一般ステップの概要を示しています(オンライン証明書ステータス・プロトコル(OCSP)を使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスするために、認証X509モジュールを構成する場合のサンプル情報も含んでいます)。
前提条件
モジュールに関連付けられているユーザー・アイデンティティ・ストアが実行中であり、必要なユーザー移入が含まれていることを確認します。
バンドルされているプラグインを使用してカスタム認証モジュールを作成する手順
Oracle Access Managementコンソールで、「認証モジュール」をクリックします。
新規作成:
「カスタム認証モジュール」ノードをクリックします。
「作成」(+)ボタンをクリックします。
一般的な情報の追加: 「名前」と、オプションの「説明」。たとえば、順に「CustomX509Plugin」と「X509のプラグイン」とします。
「適用」をクリックして一般情報を保存します。
ステップの追加:
「ステップ」サブタブをクリックします。
「ステップ」表の上にある「追加」(+)ボタンをクリックします。
「新規ステップの追加」ダイアログ・ボックスで、一意の「ステップ名」と、オプションで「説明」を入力します。
目的のカスタム・プラグイン名(たとえば、X509CredentialExtractor)を参照して選択し、「OK」をクリックします。
結果表の情報を確認します。
モジュールに必要なすべてのプラグインがリストされるまで、bからeを繰り返して他のステップを追加します。
「ステップの詳細」の定義: 要求されるパラメータに適切な値を使用します(表19-12、表19-13、表19-17「カスタム・プラグインの管理アクション」および「例: SubjectAltName拡張データを利用して複数のOCSPエンドポイントを統合する方法」)。
表の「StepName」をクリックして必要な詳細を表示させ、必要な詳細に適切な値を入力します。
OCSPを使用したユーザー証明書の検証:
KEY_IS_CERT_VALIDATION_ENABLEDがtrue
に設定されていることを確認します。
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACTで抽出される証明書属性を追加します(表19-15):
subject.EDIPI subjectAltName.OTHER_NAME (FASC-N) subjectAltName.RFC822_NAME subjectAltName.UNIFORM_RESOURCE_IDENTIFIER
「Save」ボタンをクリックします。
手順を繰り返し、各ステップを適切に構成します。
ステップで割り当てるユーザー・アイデンティティ・ストアに、ユーザーがプロビジョニングされていることを確認します。
ステップの編成: 表19-14を参照して、次の手順を実行します。
「ステップ編成」サブタブをクリックします。
「最初のステップ」リストで、使用する最初のステップの名前を選択します。
表でステップ名を選択します。
「OnSuccess」リストから、条件(成功または失敗)またはステップ名を選択します。
「OnFailure」リストから必要な条件またはステップ名を選択します。
「OnError」リストから必要な条件またはステップ名を選択します。
手順cからfを繰り返し、このモジュールの各プラグインの操作を編成します。
編成を確認します。
戦略の検証の開始: 「適用」をクリックして、編成戦略の検証を開始します。
戦略が正常な場合: 編成戦略が適用され、認証スキームにモジュールを追加できるようになります。ステップ9と10を続行します。
戦略が無効な場合: 「エラー」ボックスで「OK」をクリックし、OnSuccess、OnFailure、OnErrorの戦略を編集(プラグインを追加または削除)して問題を修正します。戦略が成功するまでこの手順を繰り返します。
ナビゲーション・ツリーで新しいカスタム認証モジュールがリストされていることを確認し、終わったらページを閉じます。
「認証スキームの管理」の説明に従って、カスタム・モジュールを認証スキーム内で使用します。
この項では、カスタマイズしたモジュール内でプラグインを使用してステップアップ認証を定義する方法について説明します。この例では、社内ポータルのページにアクセスするための標準レベルのアクセス権を必要とするユーザーと、機密情報にアクセスするためのアクセス権を必要とするユーザーがいます。標準アプリケーションに対する認証資格証明にはユーザー名とパスワードが含まれます。センシティブ・アプリケーションに対する資格証明には、ユーザー名、パスワードおよびセキュリティ・コード(コードの検証を行うカスタム・プラグインで取得)が含まれます。
図19-25は、ステップアップ認証モジュール内のステップを示しています。このカスタマイズされたステップアップ認証モジュール内の処理は、表19-16で説明されているステップとプラグインによって発生します。詳細は、表19-13を参照してください。
表19-16 カスタマイズされたステップアップ認証モジュール内のステップとプラグイン
ステップ番号 | ステップ名 | プラグイン名 | 説明 |
---|---|---|---|
1 |
StandardLevelCheck-2 |
UserAuthnLevelCheckPlugin |
LevelCheckルールと、チェック結果としてSUCCESSまたはFAILUREに関連付けられる資格証明パラメータで構成します。 このプラグインは、認証エンジンにアクセスして、ユーザーの現在の認証レベルを決定し、これを、プラグイン・レベル・パラメータAUTHN_LEVEL_FOR_PLUGINと比較します。また、カスタム資格証明コレクタとやり取りして、ユーザーの現在の認証レベルを指定値と比較します。たとえば、X値が2の場合:
認証レベル・チェックが成功したか失敗したかに応じて収集するパラメータのリストを指定します。
|
2 |
CollectUserNamePassword |
CredentialCollectorPlugin フローは、収集する資格証明パラメータを伝えるプラグインから開始する必要があります。アクションは、サーバーがパラメータを不変としてマークできることをサポートする必要があります。 |
このプラグインは、資格証明コレクタ(CustomReadServlet)と対話して、管理者が、認証用に収集した資格証明を構成できるようにします。収集される資格証明は、ステップ・パラメータとして構成されます。プラグインは、これらのパラメータを検証して、資格証明を収集するUIを表示します。 ユーザーが、ステップ・パラメータで収集する必要がある資格証明を提供します。この例では、前のステップで、ユーザーがレベル2の認証を受けていないので、ユーザーはユーザー名とパスワードを入力するように要求されます。
収集する資格証明は、UIインタフェースを表示する資格証明コレクタ用に、この形式で指定する必要があります。 また、次のアクションも指定します。
|
3 |
UserIdentificationProcess |
UserIdentificationPlugIn |
ユーザーを特定のLDAPユーザー・レコードにマップする即時使用プラグイン。
|
4 |
UserAuthenticationStep |
UserAuthenticationPlugin |
提供されたユーザー名とパスワードの資格証明をLDAPディレクトリに対して認証する即時使用可能プラグイン。
|
5 |
SensitiveLevelCheck-6 |
UserAuthnLevelCheckPlugin |
このプラグインは、認証エンジンにアクセスして、ユーザーの現在の認証レベルを決定し、これを、プラグイン・レベル・パラメータAUTHN_LEVEL_FOR_PLUGINと比較します。また、カスタム資格証明コレクタとやり取りして、ユーザーの現在の認証レベルを指定値と比較します。チェックが成功したか失敗したかに応じて収集するパラメータを指定します。
|
6 |
CollectSensitiveLevelCreds |
CredentialCollectorPlugin |
レベル6認証用に資格証明を収集するためのUIを表示します。これはCollectUserNamePwdと似ています。
|
7 |
ValidateSensitiveLevelCreds |
SubjectSetPlugin |
このカスタム・プラグインは、サーバーに対してセキュリティ・コードを検証します。
|
プラグインを定義して、認証モジュールに編成した後、認証スキームでモジュールを使用して、そのスキームをポリシーで使用できます。
タスクの概要: ステップアップ認証の構成
ステップアップ認証用に認証モジュールを作成または編集します。
ここで示したステップに基づいてカスタム認証モジュールを定義します。
表19-16で説明したステップとプラグインをここに示すように編成します。
センシティブ・スキーム: カスタマイズしたステップアップ認証モジュールを使用するセンシティブ・アプリケーション用の認証スキームを作成または編集します。例:
下位レベル・スキーム: カスタマイズされたステップアップ認証モジュールを使用して、下位レベル・アプリケーション用の認証スキームを作成または編集します。次に例を示します。
センシティブ・ポリシー: カスタマイズしたステップアップ認証スキームを使用するセンシティブレベル・リソース用の認証ポリシーを作成または編集します。例:
下位レベル・ポリシー: カスタマイズしたステップアップ認証スキームを使用する下位レベル・リソース用の認証ポリシーを作成または編集します。例:
検証: リソースと、リソースを保護するポリシーを検証します。例:
HTTPTokenエクストラクタ・プラグインを構成するには、次のプロセスに従う必要があります。
認証を行うアプリケーションにユーザーをリダイレクトする、サンプル・プラグインを作成します。
認証を行うアプリケーションは、ユーザーを認証し、HTTPヘッダーまたはCookieにユーザー名を設定します。
任意の該当するプラグインにアクセスする、カスタム認証モジュールを作成します。
たとえば、前の手順で作成したプラグインとHTTPTokenエクストラクタおよびユーザー識別のプラグインを追加すると、この3つのプラグインすべての処理が正常に完了したときに、認証が成功します。
ヘッダー名およびユーザー検索フィルタのプロパティの値を追加します。
KEY_HEADER_PROPERTYはHTTPTokenエクストラクタ・プラグインで設定され、KEY_LDAP_FILTERはUIプラグインで設定されます。例:
KEY_HEADER_PROPERTY = cookieorheadername
KEY_LDAP_FILTER = (uid={cookieorheadername
})
注意: 使用されるデータ・ストアにユーザーが存在する必要があります。 |
標準トークンを使用してRESTまたはWebサービスを保護する必要がある場合に、このプラグインを使用します。JSON Webトークン・プラグインはOAMトークンおよびMobile and Social JWTトークンの両方を発行します。これは、Webサービスのアクセス用に使用できます。Oracle API GatewayおよびOracle Web Services Managerは、Webサービスの保護のためにこのJWTトークンを使用できます。
次のフローでは、デプロイメントでこの認証プラグインを使用する方法について説明します。
OAM認証およびJSON Webトークン・プラグインの両方を使用するように、Oracle Access Management WebGateを構成します。
ユーザーがWebGateで保護されたリソースにアクセスする場合、WebGateはユーザーをリダイレクトしてAccess Managerで認証します。
認証時に、プラグインは、どのOAuthサービス・エンド・ポイントがJWTトークンを発生させたのかを特定します。(OAuthサービス・エンド・ポイントは一意であるため、特定のアイデンティティ・ドメイン内で特定のOAuthサービス・プロファイルを指すように構成できます。)Oracle Access Manager Mobile and SocialではJWTトークンを作成し、プラグインではこれをcookieとして返します。(プラグイン構成でcookie名を構成できます。)
Webアプリケーションは、Webサービス・アクセス用に後で使用できるように、レスポンスを捕捉してcookieにアクセスします。Webアプリケーションのデプロイ方法によっては、JWTトークンを取得するために他のオプションを使用できる場合があります。ユーザーは、これでWebリソースにアクセスできます。
WebリソースがWebサービスにアクセスする必要がある場合、OAM Mobile and Social JWTトークンを抽出して、これをOracle API Gatewayに送信します。
Oracle API Gatewayは、Oracle OAuth Service REST APIを使用してトークンを検証します。その後、Webサービスにアクセス権を付与します。Oracle API Gatewayでは、OAuthサービスをリモート・コールしないで、ローカルにJWTトークンを検証することもできます。
注意: JWTトークンをOAM認証で発行しているときに、OAuthサービスにスコープを渡すメカニズムはありません。したがって、トークンはグローバル・スコープを持つとみなされます。OAMトークンのタイムアウトとJWTトークンのタイムアウトの両方を同じ値に設定すると、同じ有効性を持つことができます。OAMトークンとJWTトークンはリンクされていないため、シングル・ログアウトを使用して、これらを終了できません。 |
JSON Webトークン(JWT)プラグインを構成するには、次の手順を使用します。カスタム認証モジュールを作成します。
「起動パッド」から「認証モジュール」をクリックします。
「認証モジュールの検索」画面が表示されます。
「認証モジュールの作成」をクリックし、ドロップダウンから「カスタム認証モジュールの作成」を選択します。
「一般」タブが表示されます。
カスタム認証モジュールの名前および説明(オプション)を入力します。
この例のために、モジュールにJWTToken AuthnModuleという名前を付けます。
「ステップ」タブおよび+ (プラス記号)をクリックして、新しいステップを追加します。
「新規ステップの追加」ダイアログが表示されます。3つの新しいステップが追加されます。
ステップ名と説明(オプション)を指定し、「プラグイン名」ドロップダウン・リストからアクティブなプラグインを選択し、「OK」をクリックします。
この例では、値はStepUIおよびUserIdentificationPluginです。このプラグインのフロー・パラメータは、ステップに追加後、編集できるようになります。
UserIdentificationPluginパラメータの値を入力して、「保存」をクリックします。
+ (プラス記号)をクリックして2つ目のステップを追加します。名前としてStepUAと入力し、ドロップダウン・リストから「UserAuthenticationPlugin」を選択して「OK」をクリックします。
UserAuthenticationPluginパラメータの値を入力して、「保存」をクリックします。
+ (プラス記号)をクリックして3つ目のステップを追加します。名前としてStepOAuthと入力し、ドロップダウン・リストから「OAuthTokenResponsePlugin」を選択して「OK」をクリックします。
OAuthTokenResponsePluginパラメータの値を入力して、「保存」をクリックします。
「ステップ編成」タブをクリックして、次の順序でステップの編成を構成します。
StepUI
StepUA
StepOAuth
「適用」をクリックして、「カスタム認証モジュール」タブを閉じます。
「起動パッド」から「認証スキーム」をクリックします。
「LDAPScheme」を選択して、「複製」をクリックします。
LDAPSchemeのコピー画面が表示されます。
「名前」の値をJWTToken AuthnSchemeに、認証モジュールの値をJWTToken AuthnModuleに変更します。
「保存」をクリックします。
新しく定義されたJWTToken AuthnScheme認証スキームを使用して認証ポリシーを構成します。
この項では次のトピックを記載しています:
『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の情報を使用すると、カスタム認証プラグインを作成して、そのプラグインをカスタマイズしたマルチステップ認証モジュールの定義に使用できるようになります。
プラグインの開発後、JARファイルとして管理サーバーにデプロイする必要があり、自動的に検証されます。検証後、管理者はOracle Access Managementコンソールを使用してプラグインを構成および配布できます。
サーバーは、プラグインJARファイル内のXML構成ファイルを処理し、プラグインに関するデータを抽出します。プラグインがインポートされた後、管理者はAdminServerから使用できる情報に基づいて様々なプラグインの状態を参照し、変更できます。
図19-26は、「システム構成」タブの「共通構成」セクションにあるプラグイン・ノードおよびプラグイン・ページを示しています。この「プラグイン」ページに含まれるツールバーのコマンド・ボタンは、その多くが表で選択されたプラグインに作用します。この表は、既存のカスタム・プラグインとその状態に関する情報を提供します。ページ最下部の「プラグインの詳細」セクションは、表内の選択されたプラグインの構成詳細を反映しています。
表19-17に示すように、管理者はプラグイン・ページ上部の表の上にあるコマンド・ボタンを使用して、プラグインの状態を制御します。
表19-17 カスタム・プラグインの管理アクション
アクション・ボタン | 説明 |
---|---|
プラグインのインポート |
プラグインJARファイルをAdminServer $DOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。
成功時: ステータスが「アップロード済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アップロード済」と報告し、AdminServerにおけるステータスも「アップロード済」となります。 失敗時: ステータスは「アップロードに失敗しました」と報告されます。 関連項目: 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』のカスタム・プラグインのライフサイクルに関する項 |
選択項目の配布 |
成功時: ステータスが「配布済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「配布済」と報告し、AdminServerにおけるステータスも「配布済」となります。 失敗時: ステータスは「配布に失敗しました」と報告されます。 |
選択項目のアクティブ化 |
プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。 アクティブ化:
成功時: ステータスが「アクティブ化済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アクティブ化済」と報告し、AdminServerにおけるステータスも「アクティブ化済」となります。 失敗時: ステータスは「アクティブ化に失敗しました」と報告されます。 すべてのOAMサーバーについてアクティブ化した後、認証モジュールの作成または編成でプラグインを使用および実行できます。 |
選択項目の非アクティブ化 |
プラグインをアクティブ化した後で、管理者はプラグインが認証モジュールまたはスキームで使用されていない場合などに、プラグインの非アクティブ化を選択できます。登録済のすべてのOAMサーバーから選択されたプラグイン。 非アクティブ化:
成功時: ステータスが「非アクティブ化」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「非アクティブ化」と報告し、AdminServerにおけるステータスも「非アクティブ化」となります。oam-config.xmlからプラグイン構成が削除されます。 注: 非アクティブ化の後は、認証モジュールまたは編成でプラグインを使用または実行できません。 失敗時: ステータスは「非アクティブ化に失敗しました」と報告されます。 |
選択項目の削除 |
プラグインを非アクティブ化した後、管理者は選択したプラグインを削除できます。このプロセスで、Access Managerは次のことを行います。 削除:
成功時: ステータスが「削除済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「削除済」と報告し、AdminServerにおけるステータスも「削除済」となります。oam-config.xmlからプラグイン構成が削除されます。 失敗時: ステータスは「削除に失敗しました」と報告されます。 |
表19-18では、プラグイン・ステータス表の要素について説明します。
表19-18 プラグイン・ステータス表
要素 | 説明 |
---|---|
プラグイン名 |
XMLメタデータ・ファイルのプラグイン名要素から抽出されます。 |
説明 |
XMLメタデータ・ファイルの説明要素から抽出されます。 |
アクティブ化のステータス |
AdminServerの情報に基づいてアクティブ化のステータスが報告されます。 |
タイプ |
XMLメタデータ・ファイルのタイプ要素から抽出されます。 |
最終更新日 |
XMLメタデータ・ファイルの作成日要素から抽出されます。 |
最終更新者 |
XMLメタデータ・ファイルの作成者要素から抽出されます。 |
このページの「プラグインの詳細」セクションでは、表19-18に示すように、「アクティブ化のステータス」がAdminServerによって維持されます。
プラグインによっては、様々な構成詳細がXMLメタデータ・ファイルの構成要素から抽出され、「プラグインの詳細」セクションの「構成パラメータ」に移入されます。例を表19-19に示します。表19-13も参照してください。
表19-19 XMLメタデータ・ファイルから抽出されたプラグイン詳細の例
構成要素 | 説明 |
---|---|
データソース |
- <configuration> - <AttributeValuePair> <Attribute type="string" length="20">DataSource</Attribute> <mandatory>true</mandatory> <instanceOverride>false</instanceOverride> <globalUIOverride>true</globalUIOverride> <value>jdbc/CISCO</value> <AttributeValuePair> <configuration> |
Kerberos詳細 |
このプラグインを使用するには、Kerberos詳細を定義します。 |
ユーザー識別詳細 |
このプラグインを使用するには、ユーザー・アイデンティティ・ストアおよびフィルタの詳細を定義します。 |
ユーザー認証詳細 |
このプラグインを使用するには、ユーザー・アイデンティティ・ストアを定義します。 |
X.509詳細 |
このプラグインを使用するには、証明書詳細を定義します。 |
有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。
前提条件
カスタム・プラグインの開発の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。
カスタム認証プラグインを使用可能にする方法
プラグインをインポートします。
Oracle Access Managementコンソールにログインします。
https://hostname:port/oamconsole/
Oracle Access Managementコンソールで、「プラグイン」をクリックし、「アクション」メニューの「開く」をクリックします。
「プラグインのインポート」ボタンをクリックします。
「プラグインのインポート」ダイアログ・ボックスで、「参照」をクリックしてプラグインJARファイルの名前を選択します。
ダイアログ・ボックスのメッセージを確認し、「インポート」をクリックします。
Oracle Fusion Middleware Oracle Access Management管理者ガイドに示されているように、JARファイルが検証されます。
パラメータの構成: 「プラグインの詳細」セクションを開き、「構成パラメータ」をクリックして、必要に応じて適切な情報を入力します。例:
プラグインをOAMサーバーに配布します。
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目の配布」ボタンをクリックし、「アクティブ化のステータス」をチェックします。
プラグイン(およびカスタム・プラグイン実装クラス)をアクティブ化し、OAMサーバーで使用できるようにします。
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目のアクティブ化」ボタンをクリックし、「アクティブ化のステータス」をチェックします。
必要に応じて次のタスクを実行します。
有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。
前提条件
カスタム認証プラグインのアクティブ化ステータスをチェックする手順は、次のとおりです。
Oracle Access Managementコンソールで、「プラグイン」をクリックし、「アクション」メニューの「開く」をクリックします。
プラグイン表で、目的のプラグイン名をクリックして選択します。
サーバー・インスタンス名: 「プラグインの詳細」セクションを開き、「アクティブ化のステータス」をクリックしてプラグインの場所とステータスを表示します。例:
必要に応じて次のタスクを実行します。
有効な管理者資格証明を持つユーザーは、次の手順を使用してカスタム・プラグインを非アクティブ化してから削除できます。
管理者がカスタム認証プラグインを削除した場合、その名前はプラグインのリストから削除されません。プラグインを削除するには(同じプラグインを後で再インポートするため)、管理者はWebLogic Serverを停止し、oam-config.xmlを手動で編集する必要があります。
前提条件
プラグインが追加されており、コンソールで使用可能になっている必要があります。
カスタム認証プラグインを削除する手順は、次のとおりです。
Oracle Access Managementコンソールにログインします。例:
https://hostname:port/oamconsole/
Oracle Access Managementコンソールで、「プラグイン」をクリックします。
プラグインの非アクティブ化: プラグインを削除する前に、これを実行する必要があります。
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目の非アクティブ化」ボタンをクリックし、プラグインの「アクティブ化のステータス」をチェックします。
非アクティブ化したプラグインの削除:
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目の削除」ボタンをクリックします。
WebLogic管理サーバーを停止し、oam-config.xmlの場所を確認し手動で編集して、非アクティブ化したプラグインを削除してから、WebLogic管理サーバーを再起動します。
必要に応じて次のタスクを実行します。
リソースまたはリソースのグループへのアクセスは、認証スキームという単一の認証プロセスで制御できます。認証スキームは、ユーザーの認証に必要なチャレンジ・メカニズムを定義する名前の付いたコンポーネントです。各認証スキームには、定義済の認証モジュール(「個別の認証用プラグインのデプロイおよび管理」で説明した標準またはカスタムのモジュール)も含める必要があります。
管理コンソールまたはリモート登録ツールを使用してパートナを登録する場合、作成されるアプリケーション・ドメインには、デフォルト・スキームとして設定される認証スキームを使用するポリシーがシードされます。ポリシー作成中に使用されるデフォルトとして、既存の認証スキームを選択できます。
新しい認証スキームの作成、テンプレートとして使用する既存の定義のコピー、定義の変更または定義の削除も実行できます。コピーには、元の名前に基づくデフォルト名を使用します。たとえば、KerberosSchemeというスキームをコピーすると、そのコピーの名前は「KerberosSchemeのコピー」になります。
この項は次のトピックに分かれています:
すべての認証スキームには、異なる値を使用した同じ要素が含まれます。図19-28は、例としてデフォルトのLDAPSchemeページを示しています。「認証スキーム」ナビゲーション・ツリーは、提供される他のデフォルト・スキームを示しています。
表19-20は、認証スキームのそれぞれの要素および値の情報を示しています。「デフォルトとして設定」ボタンを使用して、これをデフォルト・スキームにします。
表19-20 認証スキームの定義
要素 | 説明 |
---|---|
名前 |
ナビゲーション・ツリーに表示されるこのスキームの一意の名前。 関連項目: 「事前構成済認証スキーム」 |
説明 |
このスキームの使用を示す200文字までのオプションの説明。 |
認証レベル |
認証スキームの信頼レベル。ユーザーからの資格証明のトランスポートの保護に使用されるチャレンジ・メソッドおよび信頼度が反映されます。 信頼レベルは、0(信頼なし)から99(最高の信頼レベル)の整数値で表現されます。 注意: レベル0は保護されていません。保護レベル0の認証スキームを使用する認証ポリシーには、保護されていないリソースのみ追加できます。詳細は、表20-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チャレンジ・メソッドを使用したスキームのみ、表19-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開発者ガイド』: ログイン・ページおよびメッセージのカスタマイズの詳細 |
表19-21は、Access Managerで使用できる事前構成済認証スキームおよびそれぞれの固有の詳細を示しています。チャレンジ・パラメータの詳細は、表19-21を参照してください。
表19-21 事前構成済認証スキーム
スキーム名 | 指定 | 目的 |
---|---|---|
AnonymousScheme |
認証レベル: 0 チャレンジ・メソッド: なし 認証モジュール: AnonymousModule |
特定のAccess Manager URLを保護されていない状態のままにするので、ユーザーは何も要求されずにこのURLにアクセスできます。ユーザーが要求されないので、資格証明を入力する必要はありません。 注: 認証レベル0は、公開ページに使用されます。カスタム認証スキームにレベル0を使用しないことをお薦めします。 付記: リソースがAnonymousSchemeによって保護されている場合、セッション検索では表示されません。 |
BasicFAScheme Oracle Fusion Applicationsのみ |
Fusion Applications用 |
この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。 |
BasicScheme |
認証レベル: 1 チャレンジ・メソッド: Basic 認証モジュール: LDAP |
ほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 注: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。 |
BasicSessionlessScheme |
認証レベル: 1 チャレンジ・メソッド: Basic 認証モジュール: LDAP |
主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 チャレンジ・パラメータ: CookieLessMode=true 注: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。 |
FAAuthScheme Oracle Fusion Applicationsのみ |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト: customWar コンテキスト値: /fusion_apps |
この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。 |
FederationMTScheme Oracle Fusion Applicationsのみ |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: FederationMTPlugin コンテキスト・タイプ: customWar コンテキスト値: /fusion_apps チャレンジ・パラメータ: initial_command=NONE is_rsa=true |
この認証スキームに固有の情報は、Oracle Technology Network (OTN) Webサイトの「Oracle Fusion Applications Technology Library」を参照してください。
関連項目: 「認証スキームのチャレンジ・パラメータについて」 |
FederationScheme Identity Federation 11.1.2のみ |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: FederationPlugin コンテキスト・タイプ: customWar コンテキスト値: /oam チャレンジ・パラメータ: initial_command=NONE is_rsa=true |
関連項目: 第VII部: Oracle Access ManagementのIdentity Federationの管理 注意: Oracle Identity Federation 11.1.1では、Oracle Fusion Middleware Oracle Access Manager統合ガイドの説明に従って、OIFSchemeを使用します。 |
KerberosScheme |
認証レベル: 2 チャレンジ・メソッド: WNA 認証モジュール: Kerberos コンテキスト・タイプ: customWar コンテキスト値: /fusion_apps |
Active DirectoryのWindows固有の認証チャレンジ・メソッドおよび有効なWNA資格証明に基づいて、ほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 |
LDAPNoPasswordValidationScheme |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAPNoPasswordAuthModule コンテキスト・タイプ: デフォルト コンテキスト値: /oam 注: LDAPNoPasswordAuthModuleは、DAP(アサータ)メカニズムに似ています。 この表の後半の「OAM10gScheme」も参照してください。 |
フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 WebLogicコンテナのリソースを使用している場合にSSOのアイデンティティ・アサータとともに使用されます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。 |
LDAPScheme |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: customWar コンテキスト値: /fusion_apps |
フォーム・チャレンジ・メソッドに基づくほとんどのディレクトリ・タイプのAccess Manager関連リソース(URL)を保護します。 |
OAAMAdvanced |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: 外部 |
外部コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの完全な統合が必要な場合、この認証スキームが使用されます。Webgateは、パートナのフロント・エンド処理を行う必要があります。 |
OAAMBasic |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: デフォルト コンテキスト値: /oam チャレンジ・パラメータ oaamPostAuth=true oaamPreAuth=true |
デフォルト・コンテキスト・タイプでOAAM関連リソースを保護します。OAAMとの基本統合が必要な場合、このスキームを使用する必要があります。ここでは、OTPなどの拡張機能はサポートされません。エージェントとしてmod_ossoを使用する場合、統合機能のようになります。 |
OAM10gScheme |
認証レベル: 2 チャレンジ・メソッド: OAM10G 認証モジュール: LDAPNoPasswordAuthModule この表の前半の「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 |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: デフォルト コンテキスト値: /oam |
Oracle Access Management管理コンソールの認証スキーム。 |
OICScheme |
認証レベル: 2 チャレンジ・メソッド: DAP 認証モジュール: TAPModule コンテキスト・タイプ: 外部 チャレンジ・パラメータ: TAPPartnerId=RPPartner MatchLDAPAttribute=mail |
Access Managerは、このスキームを使用して認証をMobile and Socialサービスに委任し、ユーザーを認証のためにMobile and Socialログイン・ページにリダイレクトします。 |
OIFScheme Oracle Identity Federation 11.1.1のみ Identity Federation 11.1.2の場合はFederationSchemeを使用します。 |
認証レベル: 2 チャレンジ・メソッド: DAP 認証モジュール: DAP コンテキスト・タイプ: 外部 |
このスキームは認証をOIFに委任し、その後、Oracle Fusion Middleware Oracle Access Manager統合ガイドで説明されているように、Oracle Identity FederationがOAMサーバーによってアサートされているトークンを送信します。 委任認証プロトコル(DAP)チャレンジ・メソッドを使用して、認証をサード・パーティ(この場合はOIF)に委任します。 チャレンジ・パラメータ: TAPPartnerId=OIFDAPPartner 関連項目: 「認証スキームのチャレンジ・パラメータについて」 |
OIMScheme |
認証レベル: 1 チャレンジ・メソッド: フォーム 認証モジュール: LDAP コンテキスト・タイプ: デフォルト コンテキスト値: /oam |
デフォルト・コンテキスト・タイプでOracle Identity Manager関連リソースを保護します。 注意: OAMおよびOIMを統合する場合、OAMは、次のいずれかが検出された場合にユーザーの認証レベルをダウングレードします。 パスワード期限切れ 強制的なパスワードの変更 未実行のチャレンジ設定 このため、ユーザーがリダイレクトされるアイデンティティ管理(OIM)ページの必要な操作を実行した後にのみ、ユーザーはページにアクセスできます。 レベル1の場合、必要な操作の公開ページおよびOIMページにのみアクセスできます。 注: 認証レベル1は、公開ページの0よりも1つ高いだけのレベルです。カスタム認証スキームにレベル1を使用しないことをお薦めします。 |
OSSOCoexistMigrateScheme |
OSSO 10gからAccess Manager 11gに移行されている環境のデフォルトの認証スキームとして設定します。 関連項目: Oracle Fusion Middleware Oracle Identity and Access Managementアップグレード・ガイド |
|
PasswordPolicyValidationScheme |
認証レベル: 2 チャレンジ・メソッド: フォーム 認証モジュール: パスワード・ポリシー検証モジュール コンテキスト: 外部 |
パスワード・ポリシー評価を有効にします。 |
TAPResponseOnlyScheme |
認証レベル: 2 チャレンジ・メソッド: DAP 認証モジュール: DAP |
|
TAPScheme |
認証レベル: 2 チャレンジ・メソッド: DAP 認証モジュール: DAP コンテキスト・タイプ: 外部 |
IAM Suiteアプリケーション・ドメイン、「Protected HigherLevel Policy」でIDM製品リソースにTAPSchemeを使用するには、「認証スキーム」の変更に加えて、次の構成を行う必要があります。
チャレンジ・パラメータ: TAPPartnerId=TAPPartnerName |
X509Scheme |
認証レベル: 5 チャレンジ・メソッド: X509 認証モジュール: X509 |
この認証スキームは、証明書ベースのユーザー識別方法です。この方法を使用するには、ユーザーのブラウザに証明書をインストールし、WebサーバーをSSL対応にする必要があります。 注: このスキームは、SSLに依存して、ユーザーのX.509証明書をOAMサーバーに送ります。 |
認証には、リソースへのアクセスのリクエスト、HTTPを介した資格証明の収集および資格証明の検証結果に基づくHTTPレスポンスの応答の実行時にユーザーが指定する必要がある資格証明の決定が含まれます。Access Managerは、認証スキームに使用する次の資格証明チャレンジ・メソッドを提供します。
フォーム
この認証チャレンジは、ユーザー資格証明のために1つ以上のテキスト入力フィールドを含むHTMLフォームを使用します。通常のフォームベース・チャレンジで、ユーザーはフォームの2つのテキスト・ボックスにユーザー名とパスワードを入力します。最も一般的な資格証明の選択はユーザー名とパスワードですが、ユーザー名、パスワード、ドメインなどの任意のユーザー属性を使用できます。
「送信」ボタンを使用して、フォームのコンテンツを転送します。ユーザーが「送信」ボタンをクリックすると、フォーム・データがWebサーバーに転送されます。OAMおよびOSSOエージェントは、フォーム・データを捕捉および処理します。フォームで収集されたユーザー資格証明の検証時に、ユーザーが認証されます。
注意: このチャレンジ・メソッドは、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認証モジュールに基づいています。 |
なし
なしチャレンジ・メソッドでは、ユーザーが要求されないので資格証明を入力する必要がありません。これは、AnonymousScheme認証スキームで使用されます。この認証スキームを使用すると、ユーザーは、保護しないAccess Manager固有のURLにアクセスできます。
DAP
委任認証プロトコル(DAP)チャレンジ・メソッドは、認証モジュールがDAP、コンテキスト・タイプが外部であるOIFScheme (Oracle Identity Federation 11.1.1統合)で必要です(表19-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
このメカニズムは、OSSO 10gと共存するOracle Access Manager 10g向けに作成されています。OAM10Gメソッドは常に認証/認可のプロバイダとして動作します。また、Oracle Access Manager 10gがドメインを保護し、さらにOSSO 10g統合クラシック・アプリケーション(Portal、Discoなど)を含んでいる場合に、OAM10gSchemeとLDAPNoPasswordAuthModuleを使用して信頼関係を円滑化するために、OAM10Gメソッドが必要です。
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)が生成され、リソースにリダイレクトされます。
関連項目:
|
チャレンジ・パラメータは、Webgateおよび資格証明コレクタ・モジュールによって使用および解釈される短いテキスト文字列で、その値で示された方法で動作します。
チャレンジ・パラメータは、次の構文で指定します。
<parmatername>=<value>
これは、Webgateのリリース(10gと11g)に固有の構文ではありません。認証スキームは、Webgateのリリースから独立しています。
表19-22は、チャレンジ・パラメータを持つ事前構成済のスキームを示しています。
表19-22 事前構成済スキームのチャレンジ・パラメータ
事前構成済スキーム | チャレンジ・パラメータ |
---|---|
BasicSessionlessScheme |
CookieLessMode=true 主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 |
FederationMTScheme |
initial_command=NONE 主に、複数要因認証をサポートするFusion Applicationsに使用されます。 is_rsa=true 第49章「Integrating RSA SecurID Authentication with Access Manager」および『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、RSAマルチステップ認証で使用されます。 |
FederationScheme Identity Federation 11.1.2のみ。Oracle Identify Federation 11.1.1の場合はOIFSchemeを使用します。 |
主に、URLリダイレクトまたはCookieをサポートしないクライアントに使用されます。 コンテキスト値: /fusion_apps チャレンジ・パラメータ: initial_command=NONE is_rsa=true 主に、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 |
認証スキームは、リクエストをアクセス・サーバーに送信する前に、コンテキスト固有の情報を収集できます。コンテキスト固有の情報は、情報の外部コールの形を取ることができます。表19-23に、認証スキームで使用できるユーザー定義チャレンジ・パラメータを示します。
表19-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が必要です。 関連項目: |
この項では次のトピックを記載しています:
各認証スキームに強度レベルが必要になります。数字が大きいほど、認証メカニズムのセキュリティが高く、数字が小さいほど、スキームの強度は低くなります。例:
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つのリソースをサポートしません。 |
関連項目: 例は、『Oracle Fusion Middleware Oracle Identity Management Suite統合ガイド』の「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のレベルを認証スキームのレベルと比較します。
不十分な場合、エージェントは認証プロセスを再起動します。
十分な場合、アクセス権が付与されます。
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コンソールで、「認証スキーム」をクリックします。
ツールバーの「作成」ボタンをクリックします。
新しい「認証スキーム」ページ(表19-20)で、デプロイメントに応じて次の情報を入力します。
「適用」をクリックして新しいスキームを送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じます。
オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。
ナビゲーション・ツリーで、新しいスキームがリストされていることを確認します(必要に応じて、ツリーを更新してください)。
「特定のリソースの認証ポリシーの定義」に進みます。
有効な管理者の資格証明を持つユーザーは、次のタスクを実行して特定の認証スキームを検索できます。
認証スキームを検索するには、次の手順を実行します。
Oracle Access Managementコンソールで、「認証スキーム」をクリックします。
テキスト・フィールドに目的のスキーム名を(ワイルドカード(*)の使用は任意)入力します。例:
OA*
「検索」ボタンをクリックして、検索を開始します。
「検索結果」タブをクリックして結果表を表示し、次の操作を実行します。
編集: ツールバーの「編集」ボタンをクリックして、構成ページを表示します。
削除: ツールバーの「削除」ボタンをクリックしてインスタンスを削除し、確認ウィンドウで削除を確認します。
連結解除: ツールバーの連結解除をクリックして、ページ全体に表を拡張します。
表示: 「表示」メニュー項目を選択して、結果表の表示を変更します。
この検索結果で終了する場合、「参照」タブをクリックして、ナビゲーション・ツリーに戻ります。
有効な管理者の資格証明を持つユーザーは、次の手順を使用して既存の認証スキームを表示または変更できます。
注意: 認証ポリシーに関連付けられている認証スキームを削除しようとすると、関連付けの詳細が表示され、確認を求められます。ポリシーが関連付けられていない場合、スキームは削除されます。 |
認証スキームを表示または変更するには、次の手順を実行します。
Oracle Access Managementコンソールで、「認証スキーム」をクリックし、目的のスキームを見つけます。
編集:
「認証スキーム」ページで、環境に合わせて値を変更します(表19-20)。
注意: OSSOエージェントを使用するアップグレード済のデプロイメントでは、SSOCoExistMigrateSchemeを使用するように、この認証スキームとすべての保護されたリソース・ポリシーを変更します。 |
「適用」をクリックして変更を送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じます。
デフォルトとして設定: 新しいアプリケーション・ドメインでポリシーを作成する際にこのスキームが自動的に使用されるようにするには、「デフォルトとして設定」ボタンをクリックして「確認」ウィンドウを閉じます。
削除:
この認証スキームを使用しているアプリケーション・ドメインがあるかどうかを確認し、あれば別のスキームを割り当てます。
「認証スキーム」ページを確認してこれが削除するスキームであることを確認し、ページを閉じます。
ナビゲーション・ツリーでスキームの名前をクリックし、ツール・バーの「削除」ボタンをクリックします。
削除を確認します(または確認ウィンドウを閉じます)。
拡張ルールが追加され、既存の認証ポリシーを拡張できるようになりました。認証前と認証後の両方のルールを適用できます。
拡張ルールには、ブール式が含まれています。トリガーされた認証ルール結果が複数の場合は、実行順序が最も早い結果が最終的な結果として選択されます。表19-24は、拡張ルールの作成時に定義する必要のある属性をまとめたものです。
表19-24 拡張ルールの属性
名前 | 説明 |
---|---|
名前 |
AuthnRule名。名前はチェックポイント内で一意であることが必要です。 |
説明 |
ルールの説明 |
実行順序 |
結果が複数ある場合の結果の実行順序 |
条件 |
スクリプト。ユーザーはHTTPリクエスト・ヘッダーの可用性に基づいて条件を構成し、目的の結果を設定できます。 |
結果 |
ルールが適用される認証スキームのID。アクセス/拒否。 |
顧客によっては、非ブラウザ・クライアントをサポートするためにフォームベース認証スキームの拡張が必要になることがあります。求められているのは、フォームベースのログイン・ページをブラウザに表示するが、非ブラウザ・クライアントも、ヘッダーを介して渡された資格証明に基づいてBasic認証を実行できるようにすることです。詳細は、次の各項を参照してください。
ユーザー認証では、ブラウザを通してユーザーが入力を行うフォームベースのログイン・ページが表示されます。非ブラウザ・クライアント(スイッチ、ルーターなど)が、リクエスト・ヘッダーを介して渡された資格証明に基づいてBasic認証を行うことが必要な場合もあります。(これは、フォームベース認証スキームで保護されている特定のリソースに、ブラウザを使用するユーザーだけでなくスイッチやルーターなどの非ブラウザ・クライアントからもアクセスできる場合に生じます。)非ブラウザ・クライアント認証のサポートは、認証前拡張ルールの1つとして追加されています(構成も可能です)。非ブラウザ・クライアント認証をサポートするには、目的の条件を(HTTPリクエスト・ヘッダーの可用性に基づいて)認証ルール内で構成し、目的の結果を設定します。
認証条件を実行する前に、Access Managerサーバーは利用できるリクエスト・データを使用してリクエスト・コンテキストを用意します(条件に基づいてブール式を作成するため)。次の表は、様々なリクエスト・コンテキスト・データの詳細の説明です。
表19-25 リクエスト・コンテキスト・データ
属性名 | 説明 |
---|---|
requestMap |
すべてのリクエスト・ヘッダー、パラメータおよびPOSTデータ値のマップ。この例では、カスタム・ヘッダー・キーをリクエスト・ヘッダーから取得して値'test'と比較できます。 str(request.requestMap['custom-header']).lower().find('test') > 0 |
resourceMap |
一致するリソースの詳細のマップ |
accept |
'Accept'ヘッダー値を返します。 |
acceptCharset |
'Accept-Charset'ヘッダー値を返します。 |
acceptEncoding |
'Accept-Encoding'ヘッダー値を返します。 |
acceptLanguage |
'Accept-Language'ヘッダー値を返します。 |
authorization |
'Authorization'ヘッダー値を返します。 |
connection |
'Connection'ヘッダー値を返します。 |
contentLength |
'ContentLength'ヘッダー値を返します。 |
cookie |
'Cookie'ヘッダー値を返します。 |
host |
'Host'ヘッダー値を返します。 |
ifModifiedSince |
'ifModifiedSince'ヘッダー値を返します。 |
pragma |
'Pragma'ヘッダー値を返します。 |
referer |
'Referer'ヘッダー値を返します。 |
userAgent |
'UserAgent'ヘッダー値を返します。 |
resourceHost |
一致したリソースのHost値を返します。 |
resourcePost |
一致したリソースのPort値を返します。 |
resourceOperation |
一致したリソースのOperation値を返します。 |
resourceQueryString |
一致したリソースのQueryStringを返します。 |
resourceName |
一致したリソースの名前を返します。 |
resourceType |
一致したリソースのタイプを返します。 |
resourceURL |
一致したリソースのURLを返します。たとえば、’landingPage’がrequest.resourceURLの中にある場合、resourceURLの中にlandingPageがあると、条件はtrueに評価されます。 |
表19-26 ロケーション・コンテキスト・データ
属性名 | 説明 |
---|---|
locationMap |
すべてのロケーション・データ値のマップ。例: location.locationMap['CLIENT_IP'] == '10.1.23.4' |
clientIP |
クライアントIPアドレスを返します。例: location.clientIP.startswith('10.2') |
proxyIP |
プロキシIPアドレスを返します。 |
表19-29に、拡張ルールのサンプルを示します。
表19-29 拡張ルールのサンプル
サンプル・ルール | Jythonスクリプト・ベースの条件のサンプル | 注意 |
---|---|---|
プライベートまたはパブリックのIPルールに基づいて認証スキームを切り替える |
location.clientIP.startswith('10.') または location.clientIP.startswith('172.16') または location.clientIP.startwith('192.168') |
このルールは、認証前および認証後のチェックポイントで使用できます。 |
ブラック・リストIP |
['130.35.50.115', '130.35.50.112', '130.35.50.113']のlocation.clientIP |
このルールは、認証前および認証後のチェックポイントで使用できます。 |
クライアント・ブラウザ・タイプ |
request.userAgent.lower().find('firefox') > 0 |
このルールは、認証前および認証後のチェックポイントで使用できます。 |
ユーザー属性'description'が'test'のユーザーへのアクセスをブロック |
user.userMap['description'] == 'test' |
このルールを使用できるのは、認証後チェックポイントのみです。 |
非ブラウザ・クライアント |
request.authorization.lower().startswith('basic') |
このルールを使用できるのは、認証前チェックポイントのみです。 |
カスタムHTTPヘッダー値 |
request.requestMap['param'] == 'test' |
このルールは、認証前および認証後のチェックポイントで使用できます。 |
この項では次のトピックを記載しています:
Access Managerは、OAMサーバーCookie (OAM_ID)に加えて、暗号化Cookieを使用してシングル・サインオンを実装します。
11g Webgate、エージェントごとに1つ: 認証の成功後にOAMサーバーから受け取った認証トークンを使用してWebgateで設定されたOAMAuthnCookie_<host:port>_<random number>
注: 有効なOAMAuthnCookieがセッションに必要です。
10g Webgate、すべての10g Webgateに対してObSSOCookieを1つ。
Access Managerが提供するssoCookie
チャレンジ・パラメータは、Webgateによる暗号化Cookieのフラグの設定方法を制御するために任意の認証スキーム内で使用できます。例:
暗号化Cookieの保護: 暗号化CookieがSSL接続を介してのみ送信され、暗号化CookieがセキュアでないWebサーバーに返信されないようにできます。
暗号化Cookieの永続性: ユーザーが、単一のセッションではなく、一定期間ログインできるようにします。Cookieの永続機能は、Internet ExplorerおよびMozillaブラウザと連動します。
表19-30は、Webgateがシングル・サインオンの暗号化Cookieのフラグを設定する方法を制御する、特定のチャレンジ・パラメータを示しています。
表19-30 10g/11g暗号化Cookieのチャレンジ・パラメータ
暗号化Cookieの11g/10g Webgateチャレンジ・パラメータの構文 | 説明 |
---|---|
ssoCookie= |
SSO CookieのOAMAuthnCookieのフラグを制御するパラメータです。 |
miscCookies= |
その他すべてのAccess Manager暗号化Cookieのフラグを制御するパラメータです。 |
Secure |
HTTPSによってリソースにアクセスした場合のみ、暗号化Cookieが送信されるようにします。ブラウザがHTTPSを使用してサーバーにアクセスする場合のみ、セキュアなCookieが必要です。 ssoCookie=Secure miscCookies=Secure |
|
セキュアCookieを明示的に無効にします。 ssoCookie=disableSecure miscCookies=disableSecure |
httponly |
11g Webgate SSO OAMAuthnCookieと、その他のCookieをデフォルトで有効にします。 ssoCookie=httponly miscCookies=httponly |
disablehttponly |
ssoCookie=disablehttponly miscCookies=disablehttponly |
ssoCookie=max-age=time-in-seconds
|
ブラウザ内に永続Cookieを作成します。これは、1つのセッションの間保持されるものではなく、Cookieの有効期限は時間間隔in-secondsで指定します。 たとえば、Cookieを30日(2592000秒)で期限切れにするには、次のように設定します。 max-age=2592000 |
チャレンジ・パラメータは、大文字/小文字が区別されません。
認証スキームを定義します。
このスキームのチャレンジ・パラメータのセクションで、次を追加します(表19-30)。
Webgate ssoCookie=max-age=
time-in-seconds
この項では次のトピックを記載しています:
Access Managerは、資格証明の収集時にユーザーとの対話用にいくつかのページを提供します(資格証明コレクタのパスワード・ページを参照)。この場所は、デプロイする認証スキームのトポロジに応じてカスタマイズできます。
表19-31 資格証明コレクタのパスワード・ページ
資格証明コレクタ | 説明 |
---|---|
ECCページ |
デフォルトの埋込み資格証明コレクタのjspフォーム。デフォルトでOAMサーバーに配置されます。
|
DCCページ |
DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSのhttpd.conf/webgate.confファイルを使用して自動的に除外されます。これらを、除外するポリシーを構成する必要はありません。Webgateホストの次の項目を参照してください。
関連項目: ページおよびメッセージのカスタマイズの詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。 |
表19-32に、提供されるパスワード・フォームを示します。デフォルト・ページは企業の要求に合せてカスタマイズしたり、すべてをカスタム・ページと置き換えたりできます。たとえば、デスクトップ・ブラウザ用のログイン・フォームと異なるものをモバイル・ブラウザ用に表示するために、カスタム・ページを設計、実装およびデプロイできます。
表19-32 パスワード管理フォームと機能
フォーム | 機能 |
---|---|
サインイン・フォーム |
「ユーザーID」と「パスワード」フィールドを表示する標準的なログイン・フォームです。「ログイン」ボタンをクリックすると、認証モジュールによって制御される認証プロセスが開始されます。 ログイン・フォームのカスタマイズ方法の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。 |
サインイン・エラー |
この標準のログイン・フォームはエラーが発生したときに表示されます。赤く表示された文字は、エラーを示します。このエラーは表示と非表示を指定できます。 表示と非表示の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。 |
パスワードの期限切れの通知 |
次のメッセージは、通知ポリシーに従って、ユーザーにパスワードの期限が切れることを通知するために表示されます。 |
パスワードの変更フォーム |
パスワードの期限切れポリシーの構成に従って、ポリシーを施行し、ユーザーにパスワードの変更を要求する次のウィンドウが表示されます。 |
パスワードの変更の成功 |
次のパスワードの変更が成功したことを確認するメッセージが表示されます。 |
ユーザー・アカウントのロックまたは無効化 |
許可される最大ログイン試行回数の範囲内で、パスワード・ポリシーに基づいて指定した資格証明が拒否された場合は、ユーザー・アカウントのロックアウトが発生します。 |
図19-29は、Oracle Access Managementコンソールで表示した「パスワード・ポリシー」ページを示しています。管理者はこのページで、企業の要求に従ってポリシーを定義します。
表19-33は、構成可能なパスワード・ポリシーの要素の説明です(コンソールの左から右の順番に記載されています)。これらの要素は、ECCとDCCの両方で使用します。
表19-33 パスワード・ポリシーの要素
要素 | 説明 |
---|---|
最小大文字数 |
パスワードに必要な大文字の最小数を定義します。 |
最小小文字数 |
パスワードに必要な小文字の最小数を設定します。 |
最小英字数 |
パスワードで許可される特殊文字の最小数を定義します。 |
最小数字数 |
パスワードに必要な数字の最小数を設定します。 |
最小英数字数 |
パスワードに必要な英数文字の最小数を定義します。 |
最小特殊文字数 |
パスワードに必要な特殊文字の最小数を設定します。 |
最大特殊文字数 |
パスワードで許可される特殊文字の最大数を定義します。 |
最小Unicode文字数 |
パスワードに必要なUnicode文字の最小数を定義します。 |
最大Unicode文字数 |
パスワードで許可されるUnicode文字の最大数を設定します。 |
パスワードの最小文字数 |
パスワードに必要な合計の最小文字数を設定します。 |
最大パスワード長 |
パスワードで許可される合計の最大数文字数を定義します。 |
必須の文字 |
パスワードに必要な特定の文字を定義します。この定義にはデリミタは必要なく、また使用できません。 |
許可されていない文字 |
パスワードで使用可能な特定の文字を設定します。この定義にはデリミタは必要なく、また使用できません。 |
許可されている文字 |
パスワードで許可されるすべての文字を定義します。この定義にはデリミタは必要なく、また使用できません。 |
許可されていないサブ文字列 |
パスワードで許可されない特定の文字列です。この定義ではカンマをデリミタとして使用します。 |
アルファベットで始まる |
選択時は、パスワードの先頭文字に英文字が必要であることを指定します。 |
姓の許可 |
選択時は、ユーザーの姓がパスワードに含まれることを許可します。 |
名の許可 |
選択時は、ユーザーの名がパスワードに含まれることを許可します。 |
ユーザーIDの許可 |
選択時は、ユーザーのユーザーIDがパスワードに含まれることを許可します。 |
警告までの時間 |
ユーザーにパスワードが期限切れになることをいつ(何日前に)警告するかを定義します。 |
最大試行回数 |
ユーザーがロックアウトになるまでに行えるログイン試行回数を示します。 |
有効期限切れまでの時間 |
パスワードの有効期間(日数)を定義します。 |
ロックアウト期間 |
指定された回数だけログイン試行が失敗した後に、ユーザーがロックアウトされる期間(分単位)を示します。この期間の後、ユーザーは新たにログインを試行できます。 |
永続的ロックアウト |
指定された回数だけログイン試行が失敗した後の永続的ロックアウトを指定します。 |
姓の禁止 |
ユーザーがパスワードを変更するとき、いくつ前のパスワードまで使用できないかを定義します。 |
パスワード辞書ファイル |
パスワードで指定できない禁止単語のリストを含むOAMサーバー上の物理ファイルを示します。 |
パスワード・ファイル・デリミタ |
パスワード辞書ファイルでいくつかのワードを区切るために使用するデリミタを定義します。たとえば、ファイルの内容が |
パスワード・サービスURL |
いくつかのパスワード・ページの場所です。 |
資格証明コレクションにどの方法を選択していても、1つのグローバル・パスワード・ポリシーを構成して、Access Managerで(認証スキームのパスワード・ポリシー検証モジュールを使用して)保護するリソースのすべてに適用することになります。また、資格証明コレクタと関連するフォームに対応するURLは、表19-34で説明したように指定する必要があります。
表19-34 認証用の資格証明コレクタと関連フォームの指定
指定する場所 | ECCの場合 | DCCの場合 |
---|---|---|
OAMエージェント登録 DCCのみ |
なし。 |
OAMエージェント登録ページの「管理操作の許可」の横にあるチェック・ボックスを選択します。 関連項目: 「DCCの資格証明操作の有効化」 |
ログイン、エラーおよびパスワード・ページ |
ユーザーが資格証明を入力するページです。OAMサーバーにデフォルトで付属し、追加の設定や変更は必要ありません。
|
DCCを使用する汎用のログイン/ログアウトおよびパスワード・ポリシーの動的ページは、OHSの Webgateホストのディレクトリ(
DCCベースのログインおよびログアウトを行うPerlスクリプト Perl実行ファイルのパス名は、Webgateホストの 関連項目: 表19-5「DCCとECCの比較」 |
パスワード・ポリシー、パスワード・サービスURL |
Default/ECCのパスワード・ページが自動的に使用されます。 ECCのパスワード・サービスURL: 関連項目: 「グローバル・パスワード・ポリシーの定義」 |
DCCパスワード・ページに次を入力します。 DCCのパスワード・サービスURL: |
ユーザー・アイデンティティ・ストア |
Access Managerスキーマのユーザー・データ・オブジェクト定義は、パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性で拡張されます。この定義は、LDIFファイルで指定して、 |
DCCとECCのどちらについても同じです。 関連項目: |
パスワード・ポリシー検証認証モジュール |
3つの各プラグイン/ステップのKEY_IDSTORE_REFとしてデフォルト・ストアを入力します(失敗時のエラーのリダイレクトも指定します)。 関連項目: |
DCCとECCのどちらについても同じです。 |
認証スキーム、チャレンジ・リダイレクトURL |
資格証明コレクタのホストを入力します。
|
資格証明コレクタのホストを入力します。
|
認証スキーム、チャレンジURL |
資格証明コレクタのログイン・フォームの相対URIを入力します。
|
資格証明コレクタのログイン・フォームの相対URIを入力します。
|
認証スキーム、チャレンジ・パラメータ |
ECC: ユーザー定義のチャレンジ・パラメータ: OverrideRetryLimit=0 initial_command=NONE 関連項目: |
DCC: ユーザー定義のチャレンジ・パラメータ:
関連項目: |
サーバー・エラー・モード |
DCCとECCのどちらについても同じです。 |
DCCとECCのどちらについても同じです。 |
認証ポリシー |
認証ポリシーの資格証明コレクタ:
|
認証ポリシーの資格証明コレクタ: リソースWebgateから独立したDCC: ***保護(リソース)Webgateアプリケーション・ドメイン(リソースを保護する 認証ポリシー)は、DCC関連の認証スキームを使用します。 ***DCC Webgateアプリケーション・ドメイン、 リソースを保護する認証ポリシーは、 DCC関連の認証スキームを使用します。次の事項を考慮します: --アクションURLなし: DCCは、デフォルトの/oam/server/auth_cred_submitを使用します。これは、DCC関連の認証スキームで自動的に保護されます。 --アクションURLあり: 指定したアクションURLを DCCスキームで明示的に保護します。 |
ログアウト構成 |
ECC: 保護(リソース)Webゲート・エージェントの登録で、 |
DCC:
|
統合デプロイメントの注意事項
Oracle Internet Directoryで、Oracle Identity ManagementとOracle Access Managementを使用する場合、2種類のパスワード・ポリシー定義および施行が存在します。
Oracle Identity ManagementとOracle Internet Directoryの両方のパスワード・ポリシー定義
次のいずれかで、パスワード・ポリシーを施行します。
Oracle Access Managementは、Webアクセスの間に状態ポリシー(間違ったパスワードなど)を施行します。Oracle Internet Directoryは独自の状態ポリシーとLDAP処理(バインドや比較など)を施行します。
Oracle Identity Managementは、パスワード更新のユーザー作成の間に値ポリシー(パスワードの特性)を施行します。Oracle Internet Directoryは独自の値ポリシーとLDAP処理用のポリシー(追加や変更など)を施行します。
1つのポリシー・セットのみを使用する場合は、次のいずれかを実行します。
Oracle Internet DirectoryポリシーをOracle Identity ManagementおよびOracle Access Managementポリシーよりも低い優先度か同じ優先度にします。ただし、これにより2つの施行が発生します。
ネイティブのLDAPパスワード・ポリシー検証を無効にします。ただし、直接のLDAP操作に対するポリシー強制もなくなります。
認証では、リソースへのアクセスのリクエスト、資格証明の収集および資格証明の検証結果に基づくレスポンスの返信の際に、ユーザーが指定する必要がある資格証明の決定が行われます。
Access Managerの認証プロセスは、認証モジュール(またはプラグイン)を使用して、要件およびバックエンド認証スキームへの情報転送を制御するルールを定義します。デフォルトで、Access Managerは、認証処理に対するOAMサーバー埋込み資格証明コレクタ(ECC)の使用をサポートしています。ただし、外部資格証明コレクタ(DCC)を使用するように、11g Webgateを構成することもできます。
ECCとDCCは、どちらも資格証明が一度に提供されない場合のマルチステップ認証フローを簡単にできます。これにより、認証関連の情報を収集するための、ユーザーやプログラム的なエンティティとの対話処理の柔軟性が向上します。複数要因による認証の詳細は、Oracle Fusion Middleware Oracle Access Management開発者ガイドを参照してください。
資格証明コレクションにどの方法(デフォルトのECCまたはオプションのDCC)を選択していても、この項で説明するようにグローバル・パスワード・ポリシーを構成して、Access Managerで保護されたすべてのリソースに適用できます。
前提条件
次に示す概要では、このパスワード・ポリシーを構成および使用する方法について説明している項へのリンクを示します。特に明記しないかぎり、すべてのタスクはECCとDCCに同様に適用できます。ご使用のデプロイメントに該当しないタスクは省略してください。
タスクの概要: パスワード・ポリシー管理のタスクは次のとおりです。
Oracle Access Management管理者の資格証明を持つユーザーは、次の手順を使用して、企業で定義された要件に基づいた共通のパスワード・ポリシーを定義できます。
注意: ECCとDCCのグローバル・パスワード・ポリシーの唯一の相違点は、パスワード・サービスURL です。これは、資格証明コレクタ固有であり、デフォルトは手順2で示すようにECCページです。 |
この例の仕様は、説明の目的のみに使用されているものです。環境はユーザーによって異なります。
Oracle Access Managementでパスワード・ポリシーを構成するには
Oracle Access Managementコンソールで、「Access Manager」パネルの「パスワード・ポリシー」をクリックします。
「パスワード・ポリシー」ページで、目的の資格証明コレクタのログイン・ページ(ECCまたはDCC、表19-34)のパスワード・サービスURLを入力します。
ECCのパスワード・サービスURL | DCCのパスワード・サービスURL | |
---|---|---|
/pages/login.jsp |
/oamsso-bin/login.pl |
「パスワード・ポリシー」ページで、企業の要件に基づいた値(表19-33)を入力します。例:
警告までの時間: 3
有効期限切れまでの時間: 20
永続的ロックアウト: (無効)
ロックアウト期間: 1
最小特殊文字数: 1
「適用」をクリックして、ポリシーを送信します。
それぞれの環境に合せて次の手順に進みます。完了済のタスクはスキップしてください。
パスワード・ポリシーは、デフォルト・ストアが指定されている場合にのみ動作します。管理者のロールと資格証明は、システム・ストアに存在している必要があります。
グローバル・パスワード・ポリシーにデフォルト・ストアを指定するには
Oracle Access Managementコンソールで、「ユーザー・アイデンティティ・ストア」をクリックします。
システム・ストアの設定: このストアに管理者ロールおよび証明書が存在する必要があります。
システム・ストアとして指定するストアのページを開きます。
「システム・ストアとして設定」をクリックします(ドメイン全体の認証および認可操作用)。
「適用」をクリックします。
管理者の追加: 「管理者ロールの管理」を参照してください。
認証モジュール: OAMAdminConsoleScheme
(認証スキーム)によって使用されるLDAP認証モジュールがシステム・ストアを使用するように設定します。
このストアを使用するように、1つ以上の認証プラグインを構成します。詳細は、「プラグイン・ベースのモジュールによるマルチステップ認証の編成」を参照してください。
デフォルト・ストアの設定: このストアは、パッチ適用時のパスワード・ポリシー、セキュリティ・トークン・サービスおよび移行に必要です。
デフォルト・ストアとして指定するストアのページを開きます。
「デフォルト・ストアとして設定」の横にあるボックスを選択します。
認証モジュール: OAMAdminConsoleScheme
を見つけて、LDAPモジュールがこのストアを参照していないことを確認します。「ネイティブ認証モジュールの管理」を参照してください。
認可ポリシー条件: 認可ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。認証ポリシー条件の定義を参照してください。
トークン発行ポリシー条件: トークン発行ポリシーのアイデンティティ条件の設定時に、特定のアイデンティティ・ストアを選択します。「トークン発行ポリシー、条件およびルールの管理」を参照してください。
登録ページを閉じます。
パスワード・ポリシーは、デフォルト・ストアが指定されている場合にのみ動作します。この項では、Oracle Access Managementのパスワード・ポリシー処理のデフォルト・ストア・スキーマを拡張する手順を説明します。
Access Managerの一部として配布されているLDIF (Lightweight Directory Interchange Format)ファイルは、必須のオブジェクト・クラスでスキーマを拡張するためのものです。一般に、これらを適用するには、idmConfigToolを使用するか、手動で連結してあるAccess ManagerとOracle Identity Managementを使用します。
Access Managerスキーマのユーザー・データ・オブジェクト定義は、パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性で拡張されます。この定義は、LDIFファイルで指定して、ldapadd
ツールを使用して各ユーザー・アイデンティティ・ストアに追加する必要があります。オラクル社が提供するLDIFについて表19-35に示します。
注意: OAM_HOMEホームには、Oracle Access Managementをホストするためにインストールされているファイルが含まれます。OAM_HOMEは、ミドルウェア・ホーム($MW_HOME)のディレクトリ構造の内部にあります。 |
表19-35 LDAPプロバイダ用のオラクル社提供LDIFのロケーション
LDAPプロバイダ | LDIFロケーション |
---|---|
OID: Oracle Internet Directory |
$OAM_HOME/ oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif |
OVD: Oracle Virtual Directory |
$OAM_HOME/ oam/server/pswdservice/ldif/OVD_PWDPersonSchema.ldif |
AD: Microsoft Active Directory |
$OAM_HOME/ oam/server/pswdservice/ldif/AD_PWDPersonSchema.ldif |
SJS: sun Java System Directory |
$OAM_HOME/ oam/server/pswdservice/ldif/IPLANET_PWDPersonSchema.ldif |
eDirectory: Novell eDirectory |
$OAM_HOME/ oam/server/pswdservice/ldif/EDIR_PWDPersonSchema.ldif |
ODSEE: Oracle Directory Server Enterprise Edition |
$OAM_HOME/ oam/server/pswdservice/ldif/OJD_PWDPersonSchema.ldif |
OUD: Oracle Unified Directory |
$OAM_HOME/ oam/server/pswdservice/ldif/OUD_PWDPersonSchema.ldif |
SLAPD: OpenLDAP Directory |
$OAM_HOME/ oam/server/pswdservice/ldif/OLDAP_PWDPersonSchema.ldif |
IBM: OBM Tivoli Directory |
$OAM_HOME/ oam/server/pswdservice/ldif/TIVOLI_PWDPersonSchema.ldif |
パスワードのユーザー・ステータスとパスワード履歴のメンテナンスを有効化する属性を表19-36に示します。各ユーザー・アイデンティティ・ストアのユーザー・データ・オブジェクトには、表19-36に示す属性を含める必要があります。これらは、ldapadd
ツールを使用して、LDIF (Lightweight Directory Interchange Format)ファイルに追加できます。
表19-36 パスワード・ポリシーのキー・パスワード属性
属性 | 説明 | 書式および値 |
---|---|---|
obPasswordCreationDate |
日付と時刻(ユーザー・ログインの時点)です。パスワードの有効期限が切れているかどうか、また警告を発行する必要があるかどうかを計算するために使用します。 |
YYYY-MM-DDThh:mm:ssZ |
obPasswordHistory |
最後に使用されたパスワードの数を追跡するために使用します。Access Managerは、10g oblixPersonPwdPolicyの書式を認識して、新しい書式に変換します。 |
新しい書式: 以前の書式:
|
obPasswordChangeFlag |
初回ユーザー・ログイン時のパスワード変更の強制(または、管理者が開始したパスワード変更の強制)に使用します。 |
ブール文字列値。
空の文字列は、 |
obuseraccountcontrol |
無効になったユーザーを表します。 |
暗号化されていない文字列値。
空の文字列は、activatedを意味します。 |
obpasswordexpirydate |
この時刻以降は、ユーザー・パスワードが期限切れであるとみなされます。 |
YYYY-MM-DDThh:mm:ssZ 空の値は、 |
obLockoutTime |
この時刻までは、ログインの試行回数が多すぎるために、ユーザーがロック・アウトされるとみなされます。 |
時期値(秒単位)は、将来の時間を表します。
|
obLoginTrvCount |
ユーザーによるログインが連続して失敗した回数。このカウンタは、最初に正しいパスワードが入力された時点でリセットされます。 |
暗号化されていない整数値。
|
oblastsuccessfullogin |
前回成功したログインの時間。 |
YYYY-MM-DDThh:mm:ssZ |
oblastfailedlogin |
前回失敗したログインの時間。 |
YYYY-MM-DDThh:mm:ssZ |
環境が idmConfigTool -prepareIDStore
を使用して構成されている場合、このタスクをスキップできます。
ユーザー・アイデンティティ・ストアがoblix
スキーマで拡張されていない場合は、このスキーマを更新して、パスワード・サービスに必要なオブジェクト・クラスを含める必要があります。
LDAPツールは、$OAM_HOME
配下の/bin
ディレクトリから実行する必要があります。次の手順は、Oracle Internet Directoryスキーマの拡張方法を示しています。環境によっては異なることがあります。
デフォルト・ユーザー・アイデンティティ・ストア・スキーマを拡張するには
次のコマンドを使用して、パスワード・サービスに必要な、指定されたデフォルト・ストアのOracle Internet Directoryオブジェクトを更新します。
ldapadd -D "cn=orcladmin" -w <password> –h <hostname> -p 3060 –x -f $OAM_HOME/ oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif
この手順では、デフォルト・ストア(この例ではOracle Internet Directory)を変更して、別の権限が与えられたアカウントをバインドDNとして使用します。これにより、パスワードの変更後、ユーザー属性を変更可能な権限が与えられます。
前提条件
サポートされているLDAPストアを登録し、デフォルト・ストアに指定します。追加したユーザーがデフォルト・ストア内で定義されていることを確認します。
図19-30は、指定されたデフォルト・ストアの完成した登録ページを示しています。この図の次に管理者の追加手順を示します。
新しい管理者を追加するには
通常どおり、Oracle Access Managementコンソールにログインします。
https://hostname:port/oamconsole/
目的の「ユーザー・アイデンティティ・ストア」登録ページを開きます。
新しい管理者を追加します。
このページの「アクセス・システム管理者」セクションで、表の上にある「+」をクリックします。
ダイアログ・ボックスで、すべてのユーザーを検索し、desireduserを強調表示して、「選択済の追加」をクリックします。
「適用」をクリックして変更を送信します。
デフォルト・ストア: 指定したデフォルト・ストアであることを確認(または「デフォルト・ストア」をクリック)して、「適用」をクリックします。
「パスワード・ポリシー認証の構成」に進みます。
パスワード・ポリシー、デフォルト・ストアおよび管理者の準備が完了すると、この項で説明するように、認証モジュールとスキームを作成できるようになります。
ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加: DCCを使用している場合は、この項をスキップして「DCC対応の11g Webゲートと認証ポリシーの構成」に進みます。
デフォルト・ストアを使用するには、パスワード・ポリシー検証認証モジュールも構成する必要があります。
注意: 認証用のパスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。 |
サンプル・モジュールを図19-31に示します。ユーザー・パスワードのステータス・ステップは、UserPasswordPolicyPlugin
に基づく一意のステップです。
各ステップは、特定の名前付きプラグインが提供するアクションを特定します。
図19-32は、認証モジュール内でのステップの編成を示しています。モジュールとステップの詳細は、「プラグイン・ベースのマルチステップ認証モジュールについて」を参照してください。
表19-37では、指定したパスワード・ポリシー検証モジュール・ステップの詳細を説明します。
表19-37 ユーザー・パスワード・ステップの詳細
ステップ名 | ステップの詳細 | 説明 |
---|---|---|
ユーザー識別ステップ |
KEY_LDAP_FILTER |
KEY_LDAP_FILTER属性にLDAPフィルタを追加します。LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。例: (uid={KEY_USERNAME}) 関連項目: アイデンティティ・ストアの正確な構文は表20-22「Access ManagerのLDAP検索フィルタの例」 およびベンダーのドキュメントを参照 |
KEY_IDENTITY_STORE_REF |
モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。 デフォルト: 登録済デフォルト・ストア |
|
KEY_SEARCH_BASE_URL |
ユーザーの検索のベースURL。例: dc=us,dc=example,dc=com |
|
ユーザー認証ステップ |
KEY_IDENTITY_STORE_REF |
モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。 デフォルト: 登録済デフォルト・ストア |
KEY_PROP_AUTHN_EXCEPTION |
LDAPエラーの伝播を有効または無効にします。 |
|
ユーザー・パスワード・ステータス・ステップ |
PLUGIN_EXECUTION_MODE |
プラグインの実行モード。このプラグインは、構成に従って、単独または他のプラグインとともに動作可能です。値は次のいずれかになります。
デフォルト: PSWDONLY |
KEY_IDENTITY_STORE_REF |
モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。 デフォルト: 登録済デフォルト・ストア |
|
NEW_USERPSWD_BEHAVIOR |
新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。値は、次のどちらかになります。
デフォルト: FORCEPASSWORDCHANGE |
|
POLICY_SCHEMA |
パスワード・サービスのポリシー・スキーマ。現在はOAM10Gのみがサポートされています。 デフォルト: OAM10G |
|
URL_ACTION |
ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。
デフォルト: REDIRECT_POST |
|
DISABLED_STATUS_SUPPORT |
無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。 デフォルト: TRUE |
前提条件
注意: パスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。3つの各プラグイン/ステップのKEY_IDSTORE_REFとしてデフォルト・ストアを入力します(失敗時のエラーのリダイレクトも指定します)。 |
パスワード・ポリシー検証モジュールを構成するには
Oracle Access Managementコンソールで、「認証モジュール」、「カスタム認証モジュール」およびパスワード・ポリシー検証モジュールをクリックします。
「ステップ」タブをクリックします。3つのステップのそれぞれに、KEY_IDSTORE_REFの横のフィールドで デフォルト・ストア名を追加します(それぞれの変更で保存します)。例:
ユーザー識別ステップ
KEY_IDSTORE_REF: OID
保存:
ユーザー認証ステップ
KEY_IDSTORE_REF: OID
保存:
ユーザー・パスワード・ステータス・ステップ
KEY_IDSTORE_REF: OID
保存:
「適用」をクリックします。
グローバル・パスワード・ポリシーには複数の認証スキームを使用することができます。管理者の資格証明を持つユーザーは、この手順に従って、PasswordPolicyValidationSchemeを構成できます。
図19-33のスキーム例は、ECC用に構成されています。図19-34のスキーム例は、ECC用に構成されています。認証スキームは、ユーザーによって異なります。
前提条件
PasswordPolicyValidationSchemeを構成するには
Oracle Access Managementコンソールで、「認証スキーム」をクリックし、「PasswordPolicyValidationScheme」をクリックします。
使用環境のスキームを設定します。例:
認証レベル2
デフォルト(空白)
チャレンジ・メソッド: フォーム
チャレンジ・リダイレクトURL: http://
CredCollector_host:port/
認証モジュール: パスワード・ポリシー検証モジュール
チャレンジURL: /CredCollector_pages/
コンテキスト・タイプ: 外部
チャレンジ・パラメータ:
ECCチャレンジ・パラメータ | DCCチャレンジ・パラメータ | |
---|---|---|
OverrideRetryLimit=0 initial_command=NONE |
OverrideRetryLimit=0 creds=userid password |
|
関連項目: 表19-23「認証スキームのユーザー定義チャレンジ・パラメータ」
|
「適用」をクリックします。
管理権限を持つユーザーは、保護Webゲート(リソースWebゲート)のアプリケーション・ドメインで、ECC用に構成したPasswordPolicyValidationSchemeを使用できます。
前提条件
PasswordPolicyValidationSchemeの構成
ECC認証ポリシーにPasswordPolicyValidationSchemeを追加するには
ECC: コンソールで、該当するアプリケーション・ドメインを検索して開きます。(「既存のアプリケーション・ドメインの検索」を参照)。
ECC: PasswordPolicyValidationSchemeを使用してリソースを保護します。
「認証ポリシー」タブで保護されたリソース・ポリシーを探して開きます(「認証ポリシーの表示または編集」を参照)。
保護されたリソース・ポリシー(認証スキーム)の「PasswordPolicyValidationScheme」を選択して、「適用」をクリックします。
認可および認証ポリシーの更新を終了します(第20章を参照してください)。
使用する環境の必要に応じて次に進みます:
ECC: 「パスワード・ポリシー構成の完了」
次のタスクの概要は、11g Webゲートおよび認証ポリシーをDCCとともに使用するように構成する方法を示しています。各手順には、該当する項へのリンクが示されています。
DCCの資格証明操作の有効化には、次の両方の構成手順が説明されています。
リソースWebゲートと一体化されたDCC: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にします。
独立したDCCとリソースWebゲート: DCCのOAMエージェント登録ページで、「資格証明コレクタ操作の許可」を有効にして、「ログアウト・リダイレクトURL」
にDCCのlogout.plを設定します。
DCCの認証ポリシーへのPasswordPolicyValidationSchemeの追加には、次の両方の構成手順が説明されています。
一体化されたDCC/リソースWebゲート: 一体化されたDCC/リソースWebゲート・アプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。
独立したDCCとWebゲート: 独立したリソースWebゲートのアプリケーション・ドメインで、DCC認証スキームを使用するように、保護されたリソースの認証ポリシーを更新します。
「DCCによるフェデレーション・フローのサポート」では、DCCをフェデレーションのフローに取り込む手順を説明しています。
独立したDCCを使用しているか、DCCとリソースWebゲートを一体化しているかにかかわらず、DCCのOAMエージェント登録ページで「資格証明コレクタ操作の許可」を有効にする必要があります。
DCCとリソースWebゲートが独立している場合は、リソースWebゲート登録ページを編集して、手順3で示すように、「ログアウト・リダイレクトURL」
の値がDCCのlogout.plとなるように設定する必要があります。
次の手順は、デプロイメントでオープン・モード通信を使用していると仮定しています。デプロイメントで簡易モードまたは証明書モードの通信を使用している場合は、手順4の実行時に適切なアーティファクトをコピーしてください。
前提条件
パスワード・ポリシー認証の構成(DCC固有の詳細を使用する場合)
DCCの資格証明操作を有効化するには
Oracle Access Managementコンソールの「Access Manager」セクションでSSOエージェントをクリックして、DCCとして動作する11.1.2 Webゲートの登録ページを検索して開きます。
DCC Webゲート登録: 「資格証明コレクタ操作の許可」を選択し、「適用」をクリックして、手順4と5を実行します。
注意: DCCをリソースWebゲートと一体化している場合は、手順3をスキップしてください。 |
独立したWebゲート: リソースWebゲート登録を編集して、「ログアウト・リダイレクトURL」
にDCCのlogout.pl (表19-34)を設定し、「適用」をクリックして、手順4と5を実行します。
AdminServer (コンソール)ホストからエージェント構成ファイル(簡易モード・ファイルまたは証明書モード・ファイルを含む)をエージェント・ホストにコピーします。例:
エージェントおよびアーティファクト | アーティファクト | |
---|---|---|
11g Webgate/アクセス・クライアントの場合:
ObAccessClient.xmlとcwallet.sso |
コピー元: AdminServer (コンソール)ホスト
$DOMAIN_HOME/output/$Agent_Name/ コピー先: エージェント・ホストの$11gWG_install_dir/webgate/config。 |
|
簡易または証明書モード | エージェント・ホストにコピー: $11gWG_install_dir/webgate/config
関連項目: 付録C「通信の保護」 |
OHS Webサーバーを再起動します。
Access Managerは、DCCに対するユーザー操作のためにいくつかの動的なページを提供します。
関連項目: Oracle Fusion Middleware Oracle Access Management開発者ガイド |
前提条件
DCCフォームを検索して更新するには
WebgateホストでDCCフォームを検索します(表19-34):
$WEBGATE_HOME/webgate/ohs/oamsso/*、
$WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl
および
。
$WEBGATE_HOME/webgate/ohs/oamsso-bin/templates/*
それらの場所は、デプロイする認証スキームのトポロジに応じてカスタマイズします。
Perlの場所を更新します: Webgateホストの$WEBGATE_HOME/webgate/ohs/oamsso-bin/*pl
にあるlogin、logoutおよびsecuridスクリプトの最初の行で、Perlの場所を実際の場所と一致するように更新します(表19-34の「DCCベースのログインおよびログアウトを行うPerlスクリプト」を参照)。
デフォルト・ページを企業に合せてカスタマイズするか、デフォルト・ページ全体をカスタム・ページと置き換えます。たとえば、デスクトップ・ブラウザ用のログイン・フォームと異なるものをモバイル・ブラウザ用に表示するために、カスタム・ページを設計、実装およびデプロイできます。
次に、保護されたリソースの認証ポリシーでDCC認証スキームを使用するために、実行する必要がある手順を説明します。実行する手順は、デプロイメントのタイプに応じて異なります。
一体化されたDCC/リソースWebゲート: 手順1を実行して、一体化されたDCC/リソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。
独立したリソースWebゲート: 手順3を実行して、独立したリソースWebゲート・アプリケーション・ドメインの保護されたリソースの認証ポリシーに、DCC認証スキームを追加します。
手順2は、DCCのデプロイメント・タイプにかかわらず実行してください。デフォルトでは、ログインおよびログアウトのフォームは、OHSの/httpd.conf/webgate.confを通じて除外されるため、これらのフォームをポリシーから除外する必要はありません。ただし、Chromeブラウザの場合は、明示的にasync favicon.icoリクエストを除外する必要があります(このリクエストは、DCCCtxCookieを無視します)。
前提条件
アプリケーション・ポリシーでDCC認証スキームを使用するには
一体化されたDCC/リソースWebゲート: DCCアプリケーション・ドメインを開きます。
認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。
このポリシーにDCC認証スキームを追加します(「特定のリソースの認証ポリシーの定義」を参照してください)。
Chromeブラウザを使用する場合は、手順2を実行します。それ以外の場合は、手順4に進みます。
Chromeブラウザ: 次の手順を実行して、DCCDomainで/favicon.ico
を追加します。
DCCDomainで、「リソース」タブをクリックします。
HTTPリソースの/favicon.ico
を見つけて開きます(または、「新規リソース」ボタンをクリックして、このリソースを追加します)。
「リソースURL」を確認または編集して、次のようにします。
/favicon.ico
「保護」セクションで、「保護レベル」リストから「除外」を選択して、「適用」をクリックします。
手順4に進みます。
独立したWebゲート: リソースWebゲート・アプリケーション・ドメインを開きます。
認証ポリシー、保護されたリソース・ポリシーを検索して開きます(「認証ポリシーの検索」を参照してください)。
このポリシーに、DCC認証スキームと、オプションの失敗URLを追加します(指定していない場合、失敗URLはデフォルトのエラー・ページを表示します)。「特定のリソースに対する認証ポリシーの定義」を参照してください。
Chromeブラウザを使用する場合は、手順2を実行します。それ以外の場合は、手順4に進みます。
Webサーバーを再起動して、「パスワード・ポリシーの構成の完了」に進みます。
DCCは、Access Managerサーバーに対するパブリック・エンドポイントとして動作するように機能が拡張されています。DCCへのHTTPリクエストは、NAPを介してAccess Managerサーバーのプロキシ・モジュールにトンネリングされます。JSPのページおよびサーブレットがAccess Managerサーバーで実行され、レスポンスがトンネリングによりDCCに返されます。実質的に、エンド・ユーザーが通信する相手はDCCのみとなります。
注意: WebGateがDCCとして構成されていてフェデレーテッド・フローが使用中の場合、DCC WebGateを使用してリソースを保護できません。リソースを保護するには、別のWebGateを構成して使用する必要があります。 |
DCCを集約フェデレーション・フローに使用する場合は、次の手順を手動で実行します。
次の内部リソースを、除外ではなくパブリックとして構成します。
/oamfed/…/* /oam/…/* /…/*
DCC Webゲートのログアウトの値を、有効なDCC Webゲート・ログアウトURLに設定します。たとえば、/oamsso-bin/logout.pl
です。
DCCエージェントのエントリを更新します。次に示すエントリを、Access Manager管理コンソールを使用して「ユーザー定義パラメータ」のリストに追加してください。
TunneledUrls=/oam,/oamfed
ここで説明するタスクは、どの証明書コレクタを構成していても同じです。次のタスクを実行して、パスワード・ポリシーの構成を完了します。
管理権限を持つユーザーは、この手順を使用して、図19-35に示すように、パスワード・ポリシー・メッセージのサーバー・エラー・モードを設定できます。
前提条件
エラー・メッセージ・モードを設定するには
Oracle Access Managementコンソールで、「Access Managerの設定」をクリックします。
「ロード・バランシング」セクションで、「サーバー・エラー・モード」を「内部」に設定します。
「適用」をクリックします。
前述のとおり、ネイティブLDAPパスワード・ポリシー検証を無効にした後でないと、非ネイティブのパスワード・ポリシーは使用できるようになりません。
たとえば、Oracle Access Managementに登録されたOracle Internet Directoryの使用時、ネイティブのパスワード・ポリシーは、通常次の場所にあります。
dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,<DOMAIN_CONTAINER>
注意: ネイティブLDAPパスワード・ポリシー検証を無効にすると、直接のLDAP操作に対するポリシー強制がなくなります。Oracle Internet Directoryには、次のうちの1つを含む様々なパスワード・ポリシーがあります。dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext ただし、これはドメインに適用することはできません。 |
orclpwdpolicyenable
パラメータをゼロ(0)に設定することで、Oracle Internet Directoryパスワード・ポリシーを無効にできます。
関連項目: Oracle Fusion Middleware Oracle Internet Directory管理者ガイドには、様々な属性が説明されています。 |
次の手順は1つの例です。環境はユーザーによって異なります。
前提条件
パスワード・ポリシー・メッセージのエラー・メッセージ・モードの設定
ネイティブLDAPポリシーをOracle Access Managementパスワード・ポリシーでオーバーライドするには
LDAPディレクトリ・ベンダーのマニュアルを参照してください。
Oracle Internet Directory: orclpwdpolicyenable
をゼロ(0)に設定することで、ネイティブ・ポリシーを無効にします。
ドメインのパスワード・ポリシーの場所を確認します。
適切なネイティブLDAPポリシーがわかっている場合は、そのポリシーを無効にします。例:
orclpwdpolicyenable = 0
使用するデプロイメントに応じて、次の作業を実行します。
DCCとECCの共存を許可して、両方の資格証明コレクタに認証スキームとポリシーを保持する場合、このタスクはスキップできます。
ECCを無効にする場合は、ここで説明するように、oam-config.xmlファイルを編集する必要があります。通常、oam-config.xmlファイルは編集しないことをお薦めします。このファイルを変更するとデータが失われたり、データ同期操作中にファイルが上書きされる可能性があります。ただし、他の方法でECCを完全に無効にして、DCCを選択できません。
注意: ECCを無効にすると、そのECCに依存するスキームとポリシーで保護されているリソース(Oracle Access Managementコンソールを含む)にはアクセスできなくなります。 |
前提条件
ECC操作を無効にして、DCCを単独で使用するには
AdminServerを実行されているノードで、他のAdminServerユーザーによって発生する可能性がある競合ができるだけ少なくなるように変更を加えます。
必要に応じて、$DOMAIN_HOME/config/fmwconfig/にあるoam-config.xmlをバックアップし、後で使用するためにコピーを別の場所に保存します。
OAMServicesDescriptor
セクションでECCEnabled
パラメータを見つけて、次の太字で示された部分を変更します。
<Setting Name="OAMServicesDescriptor" Type="htf:map">
... ...
<Setting Name="ECCEnabled" Type="htf:map">
<Setting Name="ServiceStatus" Type="xsd:boolean">false</Setting>
</Setting>
ファイルの先頭にある構成バージョン番号を1増加させて、この変更を関連付け、実行中のすべてのOAMサーバーに対する自動伝播と動的アクティブ化を有効にします(この例の、最後の行のすぐ上を参照してください)。
<Setting Name="Version" Type="xsd:integer">
<Setting xmlns="http://www.w3.org/2001/XMLSchema"
Name="NGAMConfiguration" Type="htf:map:>
<Setting Name="ProductRelease" Type="xsd:string">11.1.1.3</Setting>
<Setting Name="Version" Type="xsd:integer">2</Setting>
</Setting>
「マルチステップ認証のテスト」に進みます。
この項では、各自のデプロイメントが適切に動作していることを確認するために実行できる、いくつかの評価方法について説明します。
マルチステップ認証を確認するには
ログイン後のアクセスを確認します。
ブラウザを開き直して、リソースをリクエストします。
ユーザー資格証明を使用してログインします。
リソースにアクセスできることを確認します。
不正なログインでアクセスできないことを確認します。
ブラウザを開き直して、リソースをリクエストします。
不正なユーザー資格証明を使用してログインします。
再認証が必要になることを確認します。
不正なログインの最大試行回数を超過したときのロックアウトを確認します。
ブラウザを開き直して、リソースをリクエストします。
不正なユーザー資格証明を使用して、繰り返しログインします。
ユーザー・アカウントがロックされたことを確認します。
パスワード有効期限ポリシーを変更および評価します。
Oracle Access Managementコンソールにログインします。
パスワード・ポリシーで、有効期限とロックアウト期間(表19-33)をリセットして、次回のログイン時に警告が表示されるようにします。
ポリシーの更新を保存します。
ブラウザを開き直して、リソースをリクエストします。
パスワードが期限切れになることを示す警告ページが表示されることを確認します。
パスワードを変更しないで続行するリンクをクリックします。
パスワードを変更します。
ブラウザを開き直して、リソースをリクエストします。
パスワード有効期限切れの警告ページで、パスワードを変更するリンクをクリックします。
パスワード変更のページで、古いパスワードを正しく入力します。
新しいパスワードのフィールドで、パスワード・ポリシーに従わない新しいパスワードを入力して、パスワード検証のエラーを確認します。
要件を満たす新しいパスワードを入力して、変更の成功とリソースへのアクセスを確認します。
POSTデータの保持/リストア機能は、両方の資格証明コレクタ(ECCまたはDCC)に適用されます。この項では次のトピックを記載しています:
POSTデータの保持/リストア機能は、アプリケーションに、ユーザーが資格証明(または他のデータ)を入力しているフォームがあり、ユーザーがフォームを送信したときには、セッションの有効期限が切れたり、アイドル・セッション・タイムアウトが発生したり、トークンの有効期限が切れてしまった場合に、効力を発揮する機能です。このような場合、POSTデータの保持/リストアが行われなければ、ユーザーには新しいログイン・フォーム(認証スキームによります)が表示されます。
管理者は、有効期限切れになったユーザーと新しく認証されるユーザーが同じ場合にPOSTデータを保持するようにリソースWebgateを構成できます。表19-38に、POSTデータに対するリソースWebgateのサポートと動作を示します。
注意: Access Managerがカスタム・エージェントを使用して認証を行う場合は、認証POSTデータの保持/リストアはサポートされません。 |
表19-38 POSTデータの保持/リストアに対するリソースWebgateのサポート
リソースWebgate | 説明 |
---|---|
認証スキームのサポート |
LDAP、Basic、Sessionless Basic、X509、WNA |
フォーム・エンコーディングのサポート |
アプリケーション・フォームからポストされるtext/html、text/plain、multipart/form-dataおよびapplication/x-www-form-urlencodedタイプのデータ。 |
保持 |
ファイル・タイプの入力フィールドを除く、元のアプリケーション・フォームからポストされたデータのエンコーディング・タイプ。 |
保証 |
ダウンストリーム・アプリケーションは、元のアプリケーション・フォームからポストされた同じPOSTデータを取得します。 |
制約 |
インバウンド・リクエスト・データまたはインバウンド・フロント・チャネル・メッセージの全体サイズ。コード・デフォルト値をオーバーライドする構成パラメータを設定する必要があります。このパラメータは、アプリケーション単位になります。 |
アプリケーション・データの機密性と整合性の維持 |
リソースWebgateも資格証明コレクタも、アプリケーションPOSTデータの解釈または記録は行いません。 有効期限後、および再認証中、ユーザーが別の資格証明で認証を行った場合、前回のユーザーのPOSTデータはリソースWebgateによって消去され、リストアされません。ただし、元のアプリケーション・フォームからポストされていたダウンストリーム・アプリケーションURLへのポストは行われます。 |
保持が無視される場合... メッセージが記録される場合... 標準認証が実行される場合... エラーが表示される場合... |
POSTデータが構成済またはハードコーディングされた制限値より大きい場合、保持は無視されます。 POSTデータが許可された制限値より大きいためにスキップされた場合、メッセージが記録されます。 POSTデータがハードコーディングされた制限値(または構成された値)より大きい場合、標準承認フローが使用されます。 フロント・チャネル・メッセージ・データとアプリケーションPOSTデータの両方が大きい場合、エラーが発生します。 |
表19-39に、資格証明コレクタ機能によるPOSTデータ・ハンドリングのサポートを示します。
表19-39 POSTデータ・ハンドリングに対する資格証明コレクタのサポート
資格証明コレクタのサポート |
---|
ECCとDCC |
旧11g Webgateと互換性あり |
即時使用可能なデフォルト・ログイン・フォーム付きフォームベース認証スキーム用のPOSTデータの保持をサポートします。 |
次の方法により、認証中、アプリケーションPOSTデータが保持されます。
アプリケーションPOSTデータの解釈は行われません。 |
アプリケーション単位で、デフォルト値をオーバーライドする構成パラメータを使用して、インバウンド・フロント・チャネル・メッセージの全体サイズを制御します。 |
POSTデータが許可される制限値より大きいためにスキップされた場合、警告が記録されます。 |
次の場合、アプリケーションPOSTデータの保持は行われません。
|
ECCのみ
|
DCCのみ
|
表19-40に、認証POSTデータ・ハンドリングをサポートする認証スキームの概要を示します。
表19-40 認証POSTデータ・ハンドリングをサポートする認証スキーム
認証スキーム |
---|
|
表19-41に、認証POSTデータ・ハンドリングの完全構成要件の概要を示します。表19-41で示すすべての要件は、表19-40の認証スキームを使用するとエンドツーエンドでサポートされます。
表19-41 認証POSTデータ・ハンドリングに必要なパラメータ
パラメータ | 説明 |
---|---|
MaxPostDataBytes |
この認証スキーム・チャレンジ・パラメータは、DCCによるPOSTデータ保持に対してのみ構成します。ログイン・フォームからポストできるPOSTデータの最大サイズを制限します。DCCは、Content-Lengthヘッダーの値と、設定されている制限値とを比較します。 デフォルト: unlimited この認証スキーム・チャレンジ・パラメータは、ユーザーの資格証明として送信され、OAMサーバーに転送されるPOSTデータの最大バイト数を制限する正の整数値を必要とします。 |
MaxPreservedPostDataBytes |
認証POSTデータの保持に対してこの認証スキーム・チャレンジ・パラメータ(またはユーザー定義Webgateパラメータ)を構成します。 デフォルト: 8192バイト 注: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作は8192バイトです。 このパラメータは、Webgateが保持できるPOSTデータの最大長を定義します。インバウンド・ロー・ユーザーPOSTデータ(または処理後に暗号化されるPOSTデータ)がこの制限を超えた場合、POSTデータは削除され、既存の認証フローが続行されます。イベントは通常どおり記録されます。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
TempStateMode=form DCCのみ |
DCCでのフォームベース認証スキーム用のPOSTデータ・リストアには、チャレンジ・パラメータTempStateMode=formが必要です。フォーム認証スキームに対して、このパラメータが定義されていない場合、値はformになります。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
ChallengeRedirectMaxMessageBytes |
obrareq.cgiおよびobrar.cgiとして受信するメッセージ・データのサイズを制限するためにこのユーザー定義Webgateパラメータを構成します。メッセージ・データは、問合せ文字列長(存在する場合)で構成されます。また、POSTデータが存在する場合は、POSTデータ長で構成されます。メッセージ長がこの制限を超える場合、メッセージは処理されることなく、ブラウザには既存メッセージが表示されます。イベントは通常どおり記録されます。 デフォルト: 8192バイト 注意: obrareq.cgiは、Webgateから資格証明コレクタ(OAMサーバーまたはDCC)にリダイレクトされる問合せ文字列の形式での認証リクエストです。 obrar.cgiは、資格証明コレクタ(OAMサーバーまたはDCC)からWebgateにリダイレクトされる認証レスポンス文字列です。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
PostDataRestoration |
このユーザー定義Webgateパラメータは、リソースWebgateに対する認証POSTデータの保持を開始するために構成します。このパラメータは、 デフォルト:
関連項目: 「認証POSTデータ・ハンドリングの構成」 |
serverRequestCacheType ECCのみ |
このOAMパラメータは、埋込み資格証明コレクタ(ECC)によってリクエスト・コンテキストを記録するために使用されるメカニズムを定義します。 $DOMAIN_HOME デフォルト: COOKIE POSTデータの保持、長いURLの処理およびフォームベース認証スキームでは、FORMであることが必要です。 関連項目: この表内の |
ユーザーが入力する通常のフォーム・データは数キロバイトであることが前提になっているので、着信リクエストから発生するデータ消費に制限を設けることは一般的な要件になります。フロント・チャネル・プロトコルで転送されるデータも(リクエスト、レスポンスともに)、サイズ・チェックを受けることが必要です。次のような状況があります。
MaxPostDataBytes認証チャレンジ・パラメータを使用して、バック・チャネル上のOAMサーバーに渡されるデータのサイズを制限します。
DCCが使用されている場合、MaxPostDataBytes認証チャレンジ・パラメータはPOSTデータ全体に対してこのチェックを実行します。
MaxPreservedPostDataBytes認証スキーム・チャレンジ・パラメータを使用して、エンド・ユーザー・アプリケーションからのPOSTデータのサイズを制限します。
MaxPreservedPostDataBytes認証スキーム・チャレンジ・パラメータがこれを処理します。加えて、ユーザー定義Webgateパラメータとしてこれを設定することもできます。
Webgateユーザー定義パラメータChallengeRedirectMaxMessageBytesでobrar.cgiまたはobrareq.cgiのフロント・チャネル・ペイロードのサイズを制限します。
この手順を実行する前に、この項のすべてのPOSTデータについてのトピックに目を通しておく必要があります。認証スキームに明示的な変更を加える必要はありません。
認証POSTデータ・ハンドリングを構成するには、次の手順に従います。
認証スキームを構成します。
Oracle Access Managementコンソールで、目的のスキームを作成または見つけます(表19-40)。
「認証スキーム」ページで、POSTデータ・ハンドリングの値を変更します。
この例では、埋込み資格証明コレクタ(表19-20)と、POSTデータ・ハンドリングに対する値(表19-23)を使用します。
ECCでのPOSTデータに対する認証スキーム・チャレンジ・パラメータ | DCCでのPOSTデータに対する認証スキーム・チャレンジ・パラメータ |
---|---|
MaxPreservedPostDataBytes= 9000 |
MaxPreservedPostDataBytes= 9000TempStateMode=form |
「適用」をクリックして変更を送信します。
ECC: ECCを使用する場合は、serverRequestCacheType (oam-config.xml内のOAMパラメータ)を構成します。
管理対象サーバーを停止します。
管理サーバーを停止します。
oam-config.xmlを開いて、serverRequestCacheType値を変更します。
ファイルを保存します。
管理サーバーを再起動します。
管理対象サーバーを再起動します。
POSTデータ・ハンドリング用のWebgateパラメータを構成します。
「システム構成」タブの「Access Manager」セクションで、目的のOAMエージェント登録を作成するか、見つけます。
エージェント登録ページで、POSTデータ・ハンドリングの値を送信します(表19-23)。
ECCでのユーザー定義Webgate POSTデータ・パラメータ | DCCでのユーザー定義Webgate POSTデータ・パラメータ | |
---|---|---|
PostDataRestoration=true |
PostDataRestoration=true |
「適用」をクリックして変更を送信します。
POSTデータ・ハンドリング構成をテストするには、次の一連のアクションを順番に実行します。
説明されているすべての構成を完了します。
Webgateにより保護されるPOSTデータとURLを出力するシンプルなスクリプトを作成します。
ブラウザを使用して保護されたリソースにアクセスします。
資格証明を提供し、SSOを構築します。アイドル・セッション・タイムアウトが発生するのを待ちます。
同じブラウザで、フォームからPOSTデータを出力できるURLを使用して同じWebgateにデータをポストします。資格証明コレクタにリダイレクトされます。
前回使用した同じ資格証明を入力します。
HTTPヘッダーで、資格証明コレクタからobrar.cgiを取得した後に、保護されているリソースWebgateが200レスポンスを返していること(以前は302)を確認できます。また、スクリプトによりPOSTデータを出力できます。
長いURLの処理は、両方の資格証明コレクタ(ECCまたはDCC)に適用され、デフォルトの操作になります。
認証には、ユーザーのリクエストを一元化されたコンポーネントにリダイレクトする操作が含まれます。このコンポーネント(資格証明コレクタと呼びます)が、認証を実行します。ユーザーをポリシー強制点(OAMエージェント)から資格証明コレクタにリダイレクトするメカニズムは、HTTP上のフロント・チャネル・プロトコル専用です。このプロトコルは、現時点では、リクエストのコンテキストと、問合せ文字列に対する認証レスポンスを提供します。リクエストされたページのURLが大きい場合、コンテキスト全体が大きくなり、ブラウザで許容されているサイズを超えてしまうことがあります。これに対応するのが長いURLの処理機能です。
デフォルトでは、リソースWebgateが、フロント・チャネル・プロトコル・メッセージのサイズをチェックし、コーディングされている制限値より大きくないかどうか判断します。長いURLの処理機能が明示的に有効になっている場合、この制限は無視され、影響は発生しません。
資格証明コレクタは、次の場合、フロント・チャネル・レスポンス・ペイロードをHTTP POSTデータとして送信するかどうか決定します。
着信リクエストにより、エージェントがHTTP POSTまたはREDIRECTのレスポンス・タイプを処理できることが示されている。
資格証明コレクタがペイロードを常にHTTP POSTデータとして送信するように構成されている。
資格証明コレクタがペイロードを常に問合せ文字列として送信するように構成されている。
明示的な構成がされていない場合、そしてペイロード・サイズが事前定義済制限を超えている場合、ペイロードはHTTP POSTデータとして送信されます。ペイロード・サイズが事前定義済の制限を下回っている場合は、問合せ文字列で送信されます。
注意: アプリケーションPOSTデータも保持される場合、影響はありません。 |
表19-42に、ECCとDCC両方での長いURLの処理機能を説明します。
表19-43に、認証時における長いURLの処理機能をサポートする認証スキームの概要を示します。
表19-43 長いURLの処理をサポートする認証スキーム
認証スキーム |
---|
|
表19-44に、認証時に長いURLの処理用に必要とされるパラメータと構成内容の概要を示します。表19-44で示すすべての要件は、表19-43の認証スキームを使用するとエンドツーエンドでサポートされます。
表19-44 長いURLの処理に必要なパラメータ
パラメータ | 説明 |
---|---|
ChallengeRedirectMethod |
これは、埋込み資格証明コレクタ(ECC)と外部資格証明コレクタ(DCC)の両方に対して、POSTデータ保持のための認証スキーム・チャレンジ・パラメータ(またはユーザー定義Webgateパラメータ)として構成します。 注: まず、このパラメータを含む認証スキーム、次に、このユーザー定義パラメータを提供するWebgateが参照されます。そうでない場合、デフォルト動作はDynamicです。 値: GET|POST|DYNAMIC 各値のときの動作:
関連項目: 「認証POSTデータ・ハンドリングの構成」 |
ChallengeRedirectMaxMessageBytes |
obrareq.cgiおよびobrar.cgiとして受信するメッセージ・データのサイズを制限するためにこのユーザー定義Webgateパラメータを構成します。メッセージ・データは、問合せ文字列長(存在する場合)で構成されます。また、POSTデータが存在する場合は、POSTデータ長で構成されます。メッセージ長がこの制限を超える場合、メッセージは処理されることなく、ブラウザには既存メッセージが表示されます。イベントは通常どおり記録されます。 デフォルト: 8192バイト 注意: obrareq.cgiは、Webgateから資格証明コレクタ(OAMサーバーまたはDCC)にリダイレクトされる問合せ文字列の形式での認証リクエストです。 obrar.cgiは、資格証明コレクタ(OAMサーバーまたはDCC)からWebgateにリダイレクトされる認証レスポンス文字列です。 関連項目: 「認証POSTデータ・ハンドリングの構成」 |
serverRequestCacheType ECCのみ |
このOAMパラメータは、埋込み資格証明コレクタ(ECC)によってリクエスト・コンテキストを記録するために使用されるメカニズムを定義します。 $DOMAIN_HOME デフォルト: COOKIE POSTデータの保持、長いURLの処理およびフォームベース認証スキームでは、FORMであることが必要です。 関連項目: この表内の |
長いURLの処理機能は、デフォルトで有効になっています。Webgate/資格証明コレクタは、データを問合せ文字列またはPOSTデータのいずれかで送信します。obrareq.cgiおよびbrar.cgiとともに送信されるquerystringパラメータの長さは最大2000文字です。
機密性の高いURLや操作にユーザーがアクセスしている場合、Access Managerはアプリケーションが起動する可能性のある再認証URLを公開します。この再認証は、そのユーザーに有効なセッションがあるかどうかにかかわらずトリガーされます。アプリケーションでは、次の/oamreauthenticate
URLを呼び出して、再認証をトリガーできます。
http://<ohs_host>:<ohs_port>/oamreauthenticate
Access Managerは、/oamreauthenticateが登録済で認証ポリシーに関連付けられているものとして動作します。再認証の実行には、このポリシーに関連付けられたスキームが使用されます。再認証URLは、問合せパラメータとしてリダイレクトURLを取ります。再認証の完了後に、Access ManagerによってユーザーがこのURLにリダイレクトされます。ユーザー再認証のリクエストは、次のようになります。
http://<host>:<port>/reauthenticate.cmd? redirect_url=http://<host>:<port>/<redirection_resource_url>
リダイレクトURLが指定されていない場合は、404エラー・コードが返されます。再認証時に指定された資格証明が正しくない場合は、ユーザーに対してログイン・ページが表示されたままになり、再試行回数の上限に達すると、ユーザーは該当するエラー・ページにリダイレクトされます。アプリケーションで開始される認証を構成する方法は次のとおりです。
http://<ohs_host>:<ohs_port>/oamreauthenticate
リソースを作成し、目的の認証スキームを割り当てます。
リダイレクトURLの中で、再認証に成功したことを確認し、再認証のレスポンスについてアプリケーションに伝えるための適切なレスポンスを設定します。
Access Managerによって、最後の再認証日時がOAM_LAST_REAUTHENTICATION_TIMEヘッダーとして設定され、この値はユーザーが再認証されるたびに更新されます。
パスワードだけでは、リソースをハッカーやサイバー犯罪から守るのには不十分であることがしばしばあります。アダプティブ認証サービスは、ユーザー名とパスワードによる標準的な認証とともに、多要素認証を提供するワン・タイム・パスワード・オーセンティケータです。多要素認証は2段階処理となっており、ユーザーは、要求したサービスへのアクセスが認められる前に、ユーザー名、パスワード、そして生成した2つ目のパスワードの入力を求められます。ワン・タイム・パスワード(OTP)と呼ばれる2つ目のパスワードは、アプリケーションやモバイル・デバイスを使用して生成します。サポートしているアプリケーションは、Oracle Mobile AuthenticatorとGoogle Authenticatorです。(このリリースでは、iOSデバイスとAndroidデバイスのみがサポートされています。)
注意: 時間ベースのワン・タイム・パスワード(TOTP)は、Internet Engineering Task Force (IETF)によってRFC 6238で規定された2要素認証スキームであり、アダプティブ認証サービスで使用されています。TOTPは、HMACベースのワンタイム・パスワード・アルゴリズムを拡張したものであり、時間ベースの移動要素(新規パスワードを生成するたびに変更が必要な値)をサポートしています。 |
アダプティブ認証サービスを使用するには、ユーザーは、オーセンティケータ・アプリケーションの1つをモバイル・デバイスに(例: Oracle Mobile AuthenticatorをApple iPhoneに)ダウンロードし、Access Manager管理者から与えられたリンクをクリックすることによって構成を行います。その後、秘密鍵を取得するために、ユーザーはアプリケーションを立ち上げて「オンライン構成」をクリックし、自分の資格証明を入力します。認証が成功すると、アプリケーションは有効なOTPを表示します。次の各項では、さらに詳細を説明します。
注意: アダプティブ認証サービスでは、Oracle Adaptive Access ManagerライセンスとApplication Management Servicesライセンスのいずれかを必要とします。 |
次のセクションでは、アダプティブ認証サービスに特有な詳細について説明します。
オーセンティケータ・モバイル・アプリケーションを使用してワン・タイム・パスワード(OTP)を生成する場合には、OTPを生成する秘密鍵を取得するため、まず最初に、Access Managerサーバーの詳細情報を使ってオーセンティケータ・アプリケーションを構成します。それが終わってから、ユーザーが正しい資格証明を使用してAccess Managerで認証を行うと、Access Managerはそのユーザーの秘密鍵を返します。この秘密鍵はユーザー固有のものであり、Access Managerとオーセンティケータ・アプリケーションだけがその内容を知っています。(詳細は、「秘密鍵の生成」を参照してください。)
ユーザーが保護されたリソースにアクセスすると、ユーザー名とパスワードを要求するページが表示されます。この初期資格証明の認証に成功すると、OTPページが表示されます。ユーザーは、モバイル・オーセンティケータ・アプリケーションがOTPページに表示したOTPを入力します。OTPがAccess Managerによって検証されると、アクセスが許可されます。
注意: オーセンティケータ・アプリケーションはOTPを30分ごとにリフレッシュしますので、ユーザーが入力したOTPはその期間内だけ有効です。また、Access Managerも、同一の秘密鍵を持つユーザーに対して同じリフレッシュ期間だけOTPを生成します。したがって、Access Managerによって生成されたOTPがユーザーが入力したOTPと一致すれば、保護されたリソースに対するアクセスは許可されます。入力されたOTPが一致しない場合には、アクセスは許可されません。 |
企業は様々な方法で秘密鍵を生成できます。秘密鍵がどのように生成されてもAccess Managerにとっては関係ありませんが、Access Managerが必要とする特定の情報が含まれていなければなりません。秘密鍵は、Access Managerとオーセンティケータ・アプリケーションの間で共有される必要があります。共有秘密鍵を生成する前に、次に示すパラメータとその値のリストを、担当者に渡す必要があります。
クライアントID: 「Google Authenticator用OAuthの構成」で構成したMobile and Socialクライアントの識別子。例: 54321id
クライアント・パス: 「Google Authenticator用OAuthの構成」で構成したMobile and Socialクライアント・パスワード。
OAMMSエンドポイントURL: Mobile and SocialのRESTサービスがデプロイされているURL。例: http://host.example.com:14100/ms_oauth
秘密鍵属性名: 共有秘密鍵が格納されるLDAP属性。
アダプティブ認証サービスを使用するには、Access Managerとモバイル・オーセンティケータ・アプリケーションを構成する必要があります。アダプティブ認証サービスを使用するためのAccess Managerの構成は、次を参照してください。
ご使用のモバイル・オーセンティケータ・アプリケーションをアダプティブ構成サービスで使用するための構成は、次の対応する節を参照してください。
次の各項で、管理コンソールを使用した2要素認証の構成の詳細を説明します。Access Manager 11gR2PS2、WebゲートおよびOracle HTTP Server (OHS)がインストールされ、構成済であることを前提としています。
管理コンソールを使用して、この手順に従ってMobile and Socialサービスを有効化してから、基本認証スキームを使用してREST秘密鍵サービスを保護するために、ユーザー・プロファイル・サービスを更新します。この構成は、Oracle Mobile Authenticatorを使用するためのものです。
「起動パッド」から、「構成」パネルに移動して「使用可能なサービス」をクリックします。
「有効化」をクリックしてMobile and Socialを有効化します。
「起動パッド」で、「Mobile and Social」パネルの「OAuthサービス」をクリックします。
「OAuthアイデンティティ・ドメイン」の下のDefaultDomainをクリックします。
「リソース・サーバー」タブで、「ユーザー・プロファイル・サービス」の下の「ユーザー・プロファイル」をクリックします。
リソースURIを開きます。
/secretkey
タブから、basicauth.allowed
の値を「true」に更新します。
「適用」をクリックします。
管理コンソールを使用して、この手順に従ってOAuth Webクライアントを作成します。この構成は、Google Authenticatorを使用するためのものです。
「起動パッド」から、「構成」パネルに移動して「使用可能なサービス」をクリックします。
「有効化」をクリックしてMobile and Socialを有効化します。
「起動パッド」で、「Mobile and Social」パネルの「OAuthサービス」をクリックします。
「OAuthアイデンティティ・ドメイン」タブで、「DefaultDomain」アイデンティティ・ドメインを開きます。
「DefaultDomain」タブの「OAuthクライアント」タブをクリックします。
「OAuthクライアント」タブの「作成」をクリックしてWebクライアントを作成します。
新しい構成タブが開きます。
次の詳細を入力します。
名前: Mobile and Socialクライアントの必須名称。
説明: Mobile and Socialクライアントの省略可能な説明。
クライアントID: Mobile and Socialクライアントの必須識別子。例: 54321id
クライアント・シークレット: Mobile and Socialクライアントの必須パスワード。
詳細は、「秘密鍵の生成」を参照してください。
「権限」セクションを開いて「すべてのスコープにアクセスを許可する」チェック・ボックスを選択します。
スコープは、ユース・ケースごとに構成されます。
「権限タイプ」の下の「すべて」チェック・ボックスを選択します。
権限付与は、ユース・ケースごとに構成されます。
「作成」をクリックします。
次の構成をAccess Managerに対して行います。
Access Managerには、TOTPModuleという名前の認証モジュールがあり、そのままTOTP認証に使用できます。この手順に従って、このモジュールのインスタンスを作成します。
「起動パッド」で、「Access Manager」パネルの「認証モジュール」をクリックします。
「認証モジュール」タブの「検索」をクリックします。
検索結果が表示されます。
「TOTPModule」をクリックしてこのタブを開きます。
「TOTPModule」タブの「ステップ」タブをクリックします。
新しいステップを作成するには、プラス記号(+)をクリックします。
デフォルトではステップ・インスタンスが作成されます。これを使用して構成することも、削除して新しいものを作成して構成することもできます。
ステップ名(たとえばOTPInstance)を入力し、「プラグイン」ドロップダウンでTOTPプラグインを選択します。
KEY_OTP_SECRETKEY_ATTRIBUTEプロパティおよびKEY_IDENTITY_STORE_REFプロパティを構成します。
これらのパラメータは、秘密鍵が格納されるユーザー属性名を値として取ります。その他のプロパティはデフォルトのままにします。
注意: KEY_OTP_TIME_WINDOWの値は、Access Managerが検証に受け入れるモバイル・デバイスによって生成されるOTPコードの個数です。モバイル・デバイスは30秒ごとに新規のOTPを生成するので、このプロパティの値が3の場合には、Access Managerは、モバイル・デバイスが生成する現在のものを含む最後の3個のOTPを受け入れます。 |
変更を保存して「適用」をクリックします。
この手順に従って、TOTPプラグインのパラメータを構成します。
「起動パッド」の「Access Manager」パネルの下にある「プラグイン」をクリックします。
「TOTPPlugin」をクリックします。
構成の詳細ページが表示されます。
プラグインのプロパティKEY_OTP_SECRETKEY_ATTRIBUTEおよびKEY_IDENTITY_STORE_REFを構成します。
その他のプロパティは、デフォルト値のままにします。
注意: KEY_OTP_TIME_WINDOWの値は、Access Managerが検証に受け入れるモバイル・デバイスによって生成されるOTPコードの個数です。モバイル・デバイスは30秒ごとに新規のOTPを生成するので、このプロパティの値が3の場合には、Access Managerは、モバイル・デバイスが生成する現在のものを含む最後の3個のOTPを受け入れます。 |
「保存」をクリックします。
この手順に従って、以前作成したモジュール・インスタンスで使用するOTP認証スキームを作成します。
「起動パッド」で、「Access Manager」パネルの「認証スキーム」をクリックします。
「認証スキーム」の下の「LDAPScheme」をクリックします。
「LDAPScheme」タブが表示されます。
「LDAP Scheme」タブで、「複製」をクリックしてコピーを作成します。
新しいコピーのタブで、名前(現時点ではTOTPScheme)およびチャレンジURL(現時点では/pages/getOTP.jsp)の値を変更します。
スキーム名は、有効な名前であればどれでもかまいません。
「適用」をクリックします。
特定のユース・ケースの詳細を構成します。この手順は例の1つです。実際の手順は、異なる可能性があります。
「起動パッド」で、「Access Manager」パネルの「アプリケーション・ドメイン」をクリックします。
保護されているリソースが構成されているアプリケーション・ドメインを検索します。
検索結果が表示されます。
検索結果の該当するアプリケーション・ドメインの名前をクリックし、その構成を表示します。
「認証ポリシー」から、リソースを保護している「保護されているリソース・ポリシー」に移動します。
「保護されているリソース・ポリシー」の「拡張ルール」タブをクリックし、認証後ルールをクリックします。
新しいルールを作成します。
新しいルールを作成するには、「+」アイコンをクリックします。
「ルール名」および「説明」の値を入力します。
条件の値を入力します。
条件は、Jythonスクリプトです。値は、たとえばlocation.clientIP.startwith("127.1")です。詳細は、「承認前拡張ルールの使用」を参照してください。
条件がtrueに評価されるときに何を行うかを指定します。
オプションは、「アクセスの拒否」と「認証スキームの変更」の2つです。現在の例では、認証スキームをTOTPSchemeに変更します。
「追加」をクリックしてルールを追加します。
「適用」をクリックして、ポリシーに対する変更を保存します。
「適用」をクリックします。
次の節には、iOSまたはAndroidのモバイル・デバイスでOracle Mobile Authenticator (OMA)アプリケーションを使用する場合の構成の詳細が記載されています。
Oracle Mobile Authenticator (OMA)アプリケーションは、OTPの生成に必要な秘密鍵を取得できます。これはオンラインまたはオフラインのいずれでも実行できます。
オンライン構成は、「Oracle Mobile Authenticator用OAuthの構成」に記載されているMobile and Social OAuth機能を使用したREST Webサービスを有効化します。いったん有効化されると、Oracle Mobile Authenticatorアプリケーションは、このサービスを呼び出してAccess Managerから秘密鍵を取得できるようになります。
RESTを呼び出すためには、Oracle Mobile Authenticatorはその位置のURLを知る必要がありますので、管理者はそれを構成するリンクが含まれたWebページを作成します。ユーザーがこのリンク(電子メール経由で提供)をクリックすると、Oracle Mobile Authenticatorが起動してURLがそれに渡されて、REST位置が構成されます。URLの形式は次のとおりです。
oraclemobileauthenticator://settings?LoginURL::=http://host:port/secretKeyURL
LoginURL問合せパラメータに指定される値は、Oracle Mobile Authenticator用のOAuth設定に基づいています。詳細は、「Oracle Mobile Authenticator用OAuthの構成」を参照してください。オンライン構成の詳細は、オンライン・オプションを使用したiOS用OMAの構成およびオンライン・オプションを使用したAndroid用OMAの構成に記載されています。
オフライン構成では、モバイル・デバイスがネットワークにアクセスできないか、RESTエンド・ポイントに接続できないユース・ケースがサポートされています。Access Manager管理者は、ユーザーによる秘密鍵の生成や再作成を可能とするWebアプリケーションを設定します。ユーザーはこのWebアプリケーションにログインして認証した後に、秘密鍵を表示させて、オーセンティケータ・アプリケーションに(「オフライン構成」ボタンのクリック後に)手動で入力できます。「Google Authenticator用OAuthの構成」に記載されているように、このWebアプリケーションはOAuthを使用して保護されます。オフライン構成の詳細は、オンライン・オプションを使用したAndroid用OMAの構成およびオフライン・オプションを使用したAndroid用OMAの構成に記載されています。
次の節には、iOSモバイル・デバイスでOMAを使用する場合の構成の詳細が記載されています。
この手順では、管理者URLを使用してiOS用OMAを構成し、アカウントを作成します。URLの詳細は、「Oracle Mobile Authenticator構成の理解」に記載されています。
ご使用のモバイル・デバイスのブラウザを使用して、Access Manager管理者から提供されたURLにナビゲートします。
そのページにあるリンクをクリックして、Oracle Mobile Authenticatorを構成します。
OAMアプリケーションが開き、ユーザーは更新の受け入れを求められます。
「確定」をタップして更新します。
更新が完了すると、通知画面が表示されます。
通知画面の「OK」をタップします。
「サインイン」をタップします。
新しい画面が開きます。
ユーザー名とパスワードを入力して、「送信」をタップします。
ユーザー名とパスワードが正しければ、新規アカウントの詳細が記載されたOTP画面が開きます。サーバーの認証は成功したものの、同じユーザー名のアカウントがすでに存在する場合には、新たなユーザ名の入力を要求されます。重複していないユーザー名が入力されると、新規アカウントの詳細が記載されたOTP画面が開きます。
秘密鍵を手動で入力して、アカウントの作成とOTPの取得を行うこともできます。
「指定キーの入力」をタップします。
新しい画面が開きます。
ユーザー名と秘密鍵を入力し、「アカウントの追加」をタップします。
ユーザー名とキーが有効であれば、新規アカウントの詳細が記載されたOTP画面が開きます。ユーザー名が一意ではないか、鍵が有効ではない場合には、その情報を再入力するように求められます。
OTPをコピーしたいアカウントをタップします。
アイコンが3個表示されます。
左側のアイコンをタップして、アカウントをコピーします。
OTPがクリップボードにコピーされるので、それを好きなテキスト入力領域にペーストできます。
編集するアカウントをタップします。
アイコンが3個表示されます。
中央のアイコンをタップして、アカウントを編集します。
新規画面が表示され、ユーザー名と秘密鍵の編集が可能となります。ユーザー名とパスワードの両方を更新できます。
「アカウントの更新」をタップして、変更を完了します。
削除するアカウントをタップします。
アイコンが3個表示されます。
右側のアイコンをタップして、アカウントを削除します。
決定の確認を求めるプロンプトが表示されます。
「アカウントの削除」をタップして、確認と削除を行います。
次の節には、Androidモバイル・デバイスでOMAを使用する場合の構成の詳細が記載されています。
この手順では、管理者URLを使用してAndroid用OMAを構成し、アカウントを作成します。URLの詳細は、「Oracle Mobile Authenticator構成の理解」に記載されています。
ご使用のモバイル・デバイスのブラウザを使用して、Access Manager管理者から提供されたURLにナビゲートします。
OMAアプリケーションが開き、ユーザーは更新の受け入れを求められます。
「確定」をタップして更新します。
更新が完了すると、通知画面が表示されます。
通知画面の「OK」をタップします。
アカウントの構成後に、秘密鍵を取得してOTPを生成します。
OMAアプリケーションを開きます。
「サインイン」をタップします。
新しい画面が開きます。
ユーザー名とパスワードを入力して、「送信」をタップします。
ユーザー名とパスワードが正しければ、新規アカウントの詳細が記載された認証コード画面が開きます。サーバーの認証は成功したものの、同じユーザー名のアカウントがすでに存在する場合には、新たなユーザ名の入力を要求されます。サーバーの認証は成功したものの、そのアカウントはすでに別のデバイスで構成されている場合には、1つのアカウントがサーバーで構成が可能であるのは単一デバイスのみであるため、そのアカウントの構成はできません。次のようなエラーが表示されます。
秘密鍵を手動で入力して、アカウントの作成とOTPの取得を行うこともできます。
OMAアプリケーションを開きます。
「指定キーの入力」をタップします。
新しい画面が開きます。
名前と鍵を入力し、「アカウントの追加」をタップします。
ユーザー名とキーが有効であれば、新規アカウントの詳細が記載されたOTP画面が開きます。ユーザー名が一意ではないか、鍵が有効ではない場合には、その情報を再入力するように求められます。
「サインイン」をタップします。
新しい画面が開きます。
ユーザー名とパスワードを入力して、「送信」をタップします。
ユーザー名とパスワードが正しければ、新規アカウントの詳細が記載された認証コード画面が開きます。サーバーの認証は成功したものの、同じユーザー名のアカウントがすでに存在する場合には、新たなユーザ名の入力を要求されます。サーバーの認証は成功したものの、そのアカウントはすでに別のデバイスで構成されている場合には、1つのアカウントがサーバーで構成が可能であるのは単一デバイスのみであるため、そのアカウントの構成はできません。次のようなエラーが表示されます。
OTPをコピーしたいアカウントを長押しします。
メニュー・バーが開き、アイコンが3個表示されます。
左側のアイコンをタップして、アカウントをコピーします。
OTPがクリップボードにコピーされます。どのテキスト入力領域にもペーストできます。
編集するアカウントを長押しします。
メニュー・バーが開き、アイコンが3個表示されます。
中央のアイコンをタップして、アカウントを編集します。
ポップアップが表示され、ユーザー名と鍵の編集が可能となります。
新しい名前または鍵の値、あるいはその両方を入力します。
「保存」をタップしてアカウントを更新します。
削除するアカウントを長押しします。
メニュー・バーが開き、アイコンが3個表示されます。
右側のアイコンをタップして、アカウントを削除します。
決定の確認を求めるプロンプトが表示されます。
「アカウントの削除」をタップして、確認と削除を行います。
秘密鍵を受け取ったら、ユーザーがその秘密鍵を手動でTOTPクライアント・モバイル・アプリケーションに入力します。たとえば、サポートされるGoogle Authenticatorで構成を開始するには、ユーザーはこのアプリケーションを使用する2要素認証用のアカウントを作成します。アカウント作成後に、ユーザーはリソース所有者から受け取った共有秘密鍵を手動で入力します。さらに、Google Authenticatorの画面の一番下で時間ベースOTPが有効化されていることを確認します。Google Authenticatorアプリケーションによって、OTPコードがオフラインの切断モードで生成されます(Access Managerとの相互作用はしません)。