| Oracle® Fusion Middleware Oracle Access Management開発者ガイド 11gリリース2 (11.1.2) B69537-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management開発者ガイド 11gリリース2 (11.1.2) B69537-02 |
|
前 |
次 |
OAMサーバーでは、デフォルトのログイン・ページ、ログアウト・ページおよびエラー・ページが用意されています。会社のルック・アンド・フィールに合せてカスタム・ログイン・ページおよびカスタム・エラー・ページを作成し、Access Managerで使用できます。この章では、カスタム・ページの開発方法および使用している環境へのデプロイ方法について説明します。この章の内容は次のとおりです。
この項には次のトピックが含まれます。
Access Managerでは、カスタマイズされたユーザー・ログイン・ページを作成するための拡張可能なフレームワークを提供しています。ログイン、ログアウトおよびエラー条件処理時の認証で使用する対話型のカスタム・ページを作成できます。最も簡単な形態として、Access Managerには、そのままユーザーに表示される静的HTMLページのセットが用意されています。しかし通常、ユーザー・インタフェースは動的であり、必要なロジックを実行できるスクリプトまたはアプリケーションとして実装する必要があります。
Access Managerでは、ユーザーと対話可能なデフォルトの動的ページのセットを提供しています。これらのデフォルト・ページを自社のルック・アンド・フィールに合せてカスタマイズしたり、すべてカスタム・ページに置き換えたりできます。たとえば、ユーザーがモバイル・ブラウザかデスクトップ・ブラウザのどちらからアクセスしているかに応じて異なるバージョンのログイン・フォームを表示するカスタム動的ページを設計、実装およびデプロイできます。
開発するカスタム・ページは、既存のAccess Manager認証モジュールまたはカスタム認証プラグインと組み合せて使用できます。この章では、ログイン、ログアウトおよびエラー用のカスタム・ページの開発について説明しています。カスタム認証プラグインの開発の詳細は、第3章「カスタム認証プラグインの開発」を参照してください。
OAMサーバーの次の2つの資格証明収集コンポーネントのどちらか一方を有効化できます。これらのコンポーネントは、通信エンドポイントの役割を果たし、カスタマイズされたユーザー・インタフェースとの相互作用を容易にします。
組込み資格証明コレクタ(ECC): 追加のインストールや設定手順なしで使用できます。
外部資格証明コレクタ(DCC): 本番デプロイにおけるスケーラビリティおよびセキュリティ分離を向上させる場合には、これをお薦めします。
OAMサーバーの資格証明コレクタの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の11g Webgateの動的資格証明収集のための構成に関する項を参照してください。
ユーザーとの対話用にどちらの資格証明収集コンポーネントを有効化した場合も、使用している環境におけるカスタム・ページの設計や実装はほとんど同じです。この2つの資格証明収集方法による開発の違いの詳細は、第4.4項「外部資格証明コレクタを使用した開発」を参照してください。
認証プロセスでは、リソースへのアクセスをリクエストしているユーザーに必要な資格証明を確認し、HTTPを介して資格証明を収集し、資格証明の検証結果に基づいてHTTPレスポンスを返します。
図4-1は、OAMで保護されたリソースにアクセスするユーザーを認証するエンドツーエンドのリクエスト・フローで、最終的にエラー・ページが表示されます。
プロセスの概要: 認証リクエスト・フロー
ユーザーが保護されたリソースをリクエストします。認証フローがトリガーされ、ログイン・ページが表示されます。必要な資格証明が認証エンジンに送信されます。
このリソースは、認証(AuthN)プラグインを使用する特定の認証スキームによって保護されています。AuthNプラグインがアイデンティティ・ストアAPIを使用して資格証明を認証します。AuthNプラグインは、サード・パーティAPIもコールできます(図には非表示)。
認証を行うために、アイデンティティ・ストアAPIがバックエンド・ストアとの接続を確立します。アイデンティティ・ストアの例としてADとOVDが記載されています。
認証エラー・コードを含む結果がアイデンティティ・ストア・レイヤーから返され、プラグインおよび認証エンジン・レイヤーに送信されます。認証レイヤーで、バックエンドからのエラー・コードが対応するOAMサーバー・エラー・コードにマップされます。標準エラー・コードの詳細は、表4-2を参照してください。
結果にはアイデンティティ・ストアから取得したネイティブ・エラー・コードが含まれており、それらのエラー・コードはアンマップ・セカンダリ・エラー・コード(p_sec_error_msg)としてログイン・ページに返されます。セカンダリ・エラー・コードの詳細は、第4.3.6項「セカンダリ・エラー・メッセージの伝播」を参照してください。
エラー・コードが問合せパラメータとしてエラー・ページとログイン・ページに返されます。エラー・コードはHTTPリクエスト・パラメータとしてエラー・ページに送信されます。問合せパラメータはp_error_codeという名前です。
プライマリ・エラー・コード・メッセージとは、エラー・コードの詳細テキストを含むローカライズされた文字列です。これは、該当するリソース・バンドル・ファイルからエラー・コードを使用して取得できます。
この項には次のトピックが含まれます。
フォームベース認証では、Access Managerの認証メカニズムを使用してログイン資格証明を処理するカスタムWebフォームを開発できます。これらのフォームはHTMLページであり、ログイン情報を複数言語で表示したり、会社のプレゼンテーション標準に準拠したユーザー・インタフェース・エレメントを表示したり、パスワード管理に必要な機能を追加することができます。
フォームまたはログイン・アプリケーションは、ユーザーからのリダイレクトを処理してHTMLをレンダリングする任意のテクノロジを使用して記述できます。カスタム・ログイン・ページの記述には、JSPページ、ASP.net、Perl、PHPなどが使用できます。メリットの1つは、ページのルック・アンド・フィールを会社の基準に合うようにカスタマイズできることです。また、別のメリットとして、ユーザーの資格証明をOAMサーバーに送信する前に、必要に応じてユーザーの送信(POST)を前処理できます。
Access Managerによる認証に対応したカスタム・ログイン・ページを記述する場合、OAMサーバーの外部でホストされたログイン・ページへユーザーをリダイレクトするのが一般的な方法です。ユーザーは、記述したカスタム・ログイン・ページまたはアプリケーションにリダイレクトされます。詳細は、第4.2.2項「ページ・リダイレクション・プロセス」を参照してください。
リクエスト・キャッシュのモードとして、basic、cookie、formの3つがサポートされています。basicモードで動作する場合、request_idが必須パラメータであり、返送する必要があります。formモードでは、OAM_REQトークンが必須であり、存在する場合は返送する必要があります。cookieモードでは、OAM_REQがCookieとして設定されます。
カスタム・ログイン・フォーム・ページには次のような要件があります。
目的の認証モジュールをサポートするようにページを構築する必要があります。
ページでOAM_REQトークンの取得をサポートする必要があります。第4.2.1.1項「OAM_REQトークンを返す」を参照してください。
ページでエンド・ポイントを取得する必要があります。第4.2.1.2項「エンド・ポイントを返す」を参照してください。
OAM_REQは、認証リクエスト・コンテキストCookieが有効な場合にOAMサーバーによって設定または消去される一時的なCookieです。このCookieは、OAMサーバーでのみ認識されるキーで保護されます。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のSSO Cookieの概要に関する項を参照してください。
OAM_REQは、問合せ文字列から取得して非表示のフォーム変数として返送する必要があります。
リソースがリクエストされると、OAMサーバーは資格証明コレクタ・ページにリダイレクトまたはフォワードして資格証明を収集します。また、OAM_REQトークンをログイン・ページに送信します。カスタマイズされたログイン・アプリケーションの場合、そのログイン・アプリケーションでリクエストからOAM_REQトークンを取得して、資格証明とともにOAMサーバーに送り返すようにする必要があります。OAM_REQは、問合せ文字列から取得して非表示のフォーム変数として返送する必要があります。次に例を示します。
String reqToken = request.getParameter(GenericConstants.AM_REQUEST_TOKEN_IDENTIFIER);
<%
if(reqToken != null && reqToken.length() > 0) { %>
<input type="hidden" name="<%=GenericConstants.AM_REQUEST_TOKEN_IDENTIFIER%>" value="<%=reqToken%>">
<%
}
%>
エンド・ポイント/oam/server/auth_cred_submitをOAMサーバーに返す必要があります。次に例を示します。
<form action="/oam/server/auth_cred _submit"> or "http://oamserverhost:port/oam/server/auth _cred_submit".
フォームベース認証スキームが外部チャレンジ・タイプで作成されている場合、OAMエージェントはユーザーをまずobrareq.cgi URLへリダイレクトし、このURLはこのユーザーを、認証スキームのチャレンジURLとして指定されたログイン・ページへリダイレクトします。チャレンジ・リダイレクトURLは、DCCまたはECCエンドポイントを宣言します。チャレンジURLは、FORMなどのチャレンジ・メソッドに関連付けられたURLです。
リダイレクト・ページで、request_idとredirect_urlが問合せ文字列に追加されます。次に例を示します。
?request_id=5092769420627701289&redirect_url=http%3A%2F%2Fmycompany.com%3A7777%2Fscripta%2Fprintenv
x509認証スキームを使用する場合は、透過的に認証が実行されるため、ログイン資格証明専用のページはありません。ただし、ページ・リダイレクションは非フォームベースの認証方式にも適用されます。たとえば、x509認証スキームを使用する場合、保護されているリソースを表示する前に、機密保護に関する免責条項などへユーザーをリダイレクトできます。この場合、免責条項ページへのパスを入力し、そのページを/oam/CredCollectServlet/X509ページにリダイレクトさせます。オリジナルの問合せスキームを必ず提示してください。
このセクションのトピックは次のとおりです:
カスタム・エラー・ページは、カスタム・ログイン・アプリケーションの一部としてパッケージ化されます。認証ポリシーに基づいて、失敗リダイレクトURLをカスタム・エラー・ページの絶対URLに設定します。
すぐに使用できるカスタムUI Webアプリケーション・アーカイブ(WAR)ファイルが用意されており、これを開始ポイントしてカスタム・ログインおよびパスワード・ページを開発できます。このWARファイルは、MW_HOME/OAM1/oam/server/tools/custompages/oamcustompages.warにあります。
カスタム・エラー・ページを作成するには、次の手順を実行します。
エラー・メッセージの表示に必要なHTMLページを作成します。詳細は、第4.2項「カスタム・ログイン・ページの開発」を参照してください。
エラー・コード問合せパラメータp_error_codeとp_sec_error_msgを、使用している環境のカスタム・エラー・コードにどのようにマップするかを検討します。詳細は、第4.3.7項「エラー・コードの取得」を参照してください。
Access Managerでは、失敗の理由を示す標準エラー・コードを提供しています。一般的な失敗の理由として、ユーザー名とパスワードの無効な組合せが提供された、ユーザー・アカウントがロック中か無効になっている、内部処理エラーが発生したなどがあります。認証エラーの理由はバックエンド・アイデンティティ・ストアから取得され、OAMサーバーで管理されている特定のエラー・コードにマップされます。そして、このエラー・コードがログインまたはエラー・ページに伝播されます。認可リクエスト・フローの詳細は、第4.1項「カスタム・ページの概要」を参照してください。
表4-1は、ログイン・ページおよびエラー・ページで使用できる標準エラー情報をまとめたものです。
表4-1 エラー情報の種類
| メッセージ・タイプ | 説明 |
|---|---|
|
エラー・コード |
特定の数値を含む文字列。エラー・コードはAccess Managerのみによって管理されます。問合せ文字列パラメータは |
|
プライマリ・エラー・メッセージ |
エラー・コードの詳細テキストを含むローカライズされた文字列。クライアントのロケール、つまりユーザーのブラウザの言語設定に依存します。 |
|
セカンダリ・エラー・メッセージ |
失敗の実際の原因を含むローカライズされていない文字列。セカンダリ・エラー・メッセージは、カスタム認証プラグインから提供される場合と、アイデンティティ・ストアから返される場合があります。問合せ文字列パラメータは |
表4-2は、OAMサーバーによって送信されるエラー・メッセージ・コードおよび対応するプライマリ・エラー・メッセージを網羅したリストです。プライマリ・エラー・メッセージがアプリケーション用にカスタマイズされている場合、アプリケーションでこのカスタム・メッセージを、OAMサーバーによって管理されている対応する標準エラー・コードにマップする必要があります。エラー・コードOAM-1とOAM-2に違いはありません。
表4-2 標準エラー・コードおよびメッセージ
| エラー・コード | プライマリ・エラー・メッセージ |
|---|---|
|
OAM-1 |
指定したユーザー名またはパスワードが正しくありません。 |
|
OAM-2 |
指定したユーザー名またはパスワードが正しくありません。 |
|
OAM-3 |
資格証明の処理中に予期しないエラーが発生しました。アクションを再試行してください。 |
|
OAM-4 |
システム・エラーです。システム管理者に連絡してください。 |
|
OAM-5 |
ユーザー・アカウントがロックされているか、無効です。システム管理者に連絡してください。 |
|
OAM-6 |
ユーザーはすでにセッションの最大許容数に達しました。ログインを再試行する前に、既存のセッションの1つをクローズしてください。 |
|
OAM-7 |
システム・エラーです。アクションを再試行してください。このエラーが続く場合は、管理者に連絡してください。 |
|
OAM-8 |
認証に失敗しました。 |
|
OAM-9 |
システム・エラーです。アクションを再試行してください。このエラーが続く場合は、管理者に連絡してください。 |
|
OAM-10 |
パスワードの有効期限が切れました。システム管理者に連絡してください。 |
組込み資格証明コレクタ(ECC)を使用している場合、次のデフォルト・ページにアクセスします。
ログイン・ページ: http(s)://host:port/oam/pages/login.jsp
エラー・ページ: http(s)://host:port/oam/pages/servererror.jsp
外部資格証明コレクタ(DCC)を使用している場合、次のデフォルト・ページにアクセスします。
ログイン・ページ: /oamsso-bin/login.pl
ログイン・アクションURL: /oam/server/auth_cred_submit。これは、認証スキーム・パラメータでactionが構成されていない場合のデフォルトのアクションURLです。デフォルトのURLに対応する物理ページはありません。URLの場所に物理ページが必要になるのは、認証スキーマでactionが構成されており、アクションURLでランタイムaction typeの結果がパス・スルーの場合のみです。
エラー・ページ: /oberr.cgi。これは、DCCによって認識されるURLパターンであり、物理的な場所ではありません。
エラー・コードのセキュリティ・レベルによってOAMサーバーが返すエラー・コードが決まります。セキュリティ・レベルは、管理者がAccess Manager管理コンソールの構成パネルを使用して構成します。カスタム・ログイン・ページのエラー・コードを構成するとき、次のセキュリティ・レベル設定が使用できます。
セキュア: セキュリティ・レベルが最も高い設定。汎用的なエラー・メッセージを表示し、エラーの内部的な理由についての情報はほとんど提供しません。
外部: 推奨するデフォルトのレベル。
内部: セキュリティ・レベルが最も低い設定。エラー・コードをログイン・ページまたはエラー・ページに伝播できます。
表4-3は、セキュリティ・レベルに応じてログインまたはエラー・ページに伝播される標準エラー・コード(表4-2を参照)のリストです。
表4-3 セキュリティ・レベル別のエラー状態マッピング
| エラー状態 | 内部モード | 外部モード | セキュア・モード |
|---|---|---|---|
|
無効なログインを試行しました。 |
OAM-1 |
OAM-2 |
OAM-8 |
|
送信された資格証明の処理がなんらかの理由で失敗しました。たとえば、WNAモードで |
OAM-3 |
OAM-3 |
OAM-8 |
|
なんらかの理由で認証例外が発生しました。 |
OAM-4 |
OAM-4 |
OAM-9 |
|
ユーザー・アカウントがなんらかの状況によりロックされています。たとえば、無効な試行の回数が上限を超えた場合などです。 |
OAM-5 |
OAM-5 |
OIMが統合されている場合はOAM-8またはOAM-9 |
|
ユーザー・アカウントが無効です。 |
OAM-5 |
OAM-5 |
OAM-9 |
|
ユーザーが最大許容セッション数を超えました。 これは構成可能な属性です。 |
OAM-6 |
OAM-6 |
OAM-9 |
|
複数の理由が考えられます。セキュリティ上の理由から、正確な理由はユーザー・レベルには伝播されません。 特定のメッセージが伝播されない場合は、デフォルトのエラー・メッセージが表示されます。 |
OAM-7 |
OAM-7 |
OAM-9 |
エラー状態が発生すると、デフォルト・ページが認証ポリシーのfailure-redirect-urlでオーバーライドされていないかぎり、OAMサーバーはデフォルト・エラー・ページをフォワードします。カスタム・エラー・ページを使用する場合は、サーバーがカスタム・ページへリダイレクトするように、そのエラー・ページの絶対URLを認証ポリシーのfailure_redirect_urlで設定する必要があります。カスタム・ログイン・ページは通常、エラー・ページとして機能するロジックを持っています。
エラー状態OAM-1およびOAM-8の場合、資格証明を再度収集できるので、ユーザーはログイン・ページに戻されます。
パスワード・プラグインがパスワード・ページにリダイレクトし、対応するメッセージがパスワード・ポリシーから取得されます。これらのエラー・コードは、HTTPリクエスト・パラメータruleDesとしてパスワード・ポリシー・ページに送信されます。
表4-4は、パスワードの検証時に返される可能性のあるエラー・コード、メッセージ・キーおよび対応するメッセージのリストです。
表4-4 パスワード検証エラー・コード
| URL内のメッセージ・キー | リソース・バンドルのメッセージ・キー | メッセージ・テキスト |
|---|---|---|
|
PSWD-1 |
passwordPolicy.message.minLength |
パスワードは{0}文字以上である必要があります。 |
|
PSWD-2 |
passwordPolicy.message.maxLength |
パスワードは{0}文字以下である必要があります。 |
|
PSWD-3 |
passwordPolicy.message.minAlpha |
パスワードには英文字を{0}文字以上含める必要があります。 |
|
PSWD-4 |
passwordPolicy.message.minNumber |
パスワードには数字を{0}文字以上含める必要があります。 |
|
PSWD-5 |
passwordPolicy.message.minAlphaNumeric |
パスワードには英数字を{0}文字以上含める必要があります。 |
|
PSWD-6 |
passwordPolicy.message.minSpecialChars |
パスワードには特殊文字を{0}文字以上含める必要があります。 |
|
PSWD-7 |
passwordPolicy.message.maxSpecialChars |
パスワードには特殊文字を最大{0}文字しか使用できません。 |
|
PSWD-8 |
passwordPolicy.message.maxRepeated |
パスワードでの特定の文字の繰返しは{0}回までです。 |
|
PSWD-9 |
passwordPolicy.message.minUnique |
パスワードには一意の文字を{0}文字以上含める必要があります。 |
|
PSWD-10 |
passwordPolicy.message.minUpperCase |
パスワードには大文字を{0}文字以上含める必要があります。 |
|
PSWD-11 |
passwordPolicy.message.minLowerCase |
パスワードには小文字を{0}文字以上含める必要があります。 |
|
PSWD-12 |
passwordPolicy.message.maxAge |
パスワードは最終パスワード変更の{0}日後に期限切れになります。 |
|
PSWD-13 |
passwordPolicy.message.warnAfter |
パスワード変更リマインダは最終パスワード変更の{0}日後に送信されます。 |
|
PSWD-14 |
passwordPolicy.message.reqdChars |
パスワードには次の文字を含める必要があります: {0} |
|
PSWD-15 |
passwordPolicy.message.invalidChars |
パスワードに次の文字を含めることはできません: {0} |
|
PSWD-16 |
passwordPolicy.message.validChars |
パスワードには次の文字を含めることができます: {0} |
|
PSWD-17 |
passwordPolicy.message.invalidStrings |
パスワードに次の文字列を含めることはできません: {0} |
|
PSWD-18 |
passwordPolicy.message.startsWithChar |
パスワードはアルファベットで開始する必要があります。 |
|
PSWD-19 |
passwordPolicy.message.disAllowUserId |
パスワードは、ユーザーIDと同じにすることも、ユーザーIDを含めることもできません。 |
|
PSWD-20 |
passwordPolicy.message.disAllowFirstName |
パスワードは、名と同じにすることも、名を含めることもできません。 |
|
PSWD-21 |
passwordPolicy.message.disAllowLastName |
パスワードは、姓と同じにすることも、姓を含めることもできません。 |
|
PSWD-22 |
passwordPolicy.message.dictMessage |
辞書にあるような言葉はパスワードにできません。 |
|
PSWD-23 |
passwordPolicy.message.enforceHistory |
{0}つ前までのパスワードはいずれもパスワードにできません。 |
|
PSWD-24 |
passwordPolicy.message.minAge |
最終パスワード変更後{0}日間はパスワードを変更できません。 |
|
PSWD-25 |
passwordPolicy.message.minUnicode |
パスワードにはUnicode文字を{0}文字以上含める必要があります。 |
|
PSWD-26 |
passwordPolicy.message.maxUnicode |
パスワードには{0}文字を超えるUnicode文字は使用できません。 |
認証エンジン・レイヤーで、バックエンド・アイデンティティ・ストアからの例外がOAMサーバー固有のエラー・コードにマップされます。その後、これらのコードが伝播されます。プラグインは、セカンダリ・エラー・コードを取得して伝播することにより、適切なアクションを実行させることができます。
|
注意: プライマリ・エラー・コードは、どのモードでもエラーまたはログイン・ページに伝播されます。セカンダリ・エラー・メッセージは、セキュリティ・レベルが内部に設定されている場合のみ伝播されます。詳細は、第4.3.4項「セキュリティ・レベルの構成」を参照してください。 |
セカンダリ・エラー・メッセージは、HTTPリクエスト・パラメータとしてエラー・ページに送信されます。問合せパラメータはp_sec_error_msgという名前です。このメッセージはバックエンドからのコードとメッセージ・テキストを連結した文字列で、翻訳はされていません。
たとえば、OVDがバックエンドであり、無効な資格証明が入力されると、認証が失敗し、その理由としてバックエンドからLDAP:error code 49-Invalid Credentialsが返され、OAMサーバー・エラー・コードOAM-1が返されます。この場合、次のデータがログイン・ページに表示されます。
| エンティティ | 説明 |
|---|---|
|
エラー・コード |
OAM-1 |
|
プライマリ・メッセージ(コードから取得) |
指定したユーザー名またはパスワードが正しくありません |
|
セカンダリ・エラー・コード |
LDAP:error code 49- Invalid Credentials |
エラー・コードは、HTTPリクエスト・パラメータとしてエラー・ページに送信されます。問合せパラメータはp_error_codeという名前です。このパラメータ値には、OAMサーバーが返したOAM-1などのエラー・コード値が含まれています。Access Managerの標準エラー・コードおよび対応するメッセージは、表4-2を参照してください。これらのエラー・コードに追加情報はありません。
カスタム・ログイン・ページをカスタム・リソース・バンドルに関連付けることにより、エラー・コードを意味のあるメッセージに変換してエンド・ユーザーに表示できます。ただし、意味のあるエラー・メッセージや翻訳がカスタム・ログイン・ページで必要なければ、カスタム・リソース・バンドルは必要ありません。
ローカル・リソース・バンドル・ファイルを作成し、表4-3のように、エラー状態をAccess Managerエラー・コードにマップする必要があります。このファイルをログイン・ページまたはエラー・ページで使用できます。
例4-1にリソース・バンドル・コードの例を示します。また、例4-2にエラー・コード・ページの例を示します。
例4-1 リソース・バンドル・コード
package mytest.error;
Import java.util.ListResourceBundle;
public class ExampleErrorMsg extends ListResourceBundle {
/* (non-Javadoc)
* @see java.util.ListResourceBundle#getContents()
*/
public Object[][] getContents()
{
return m_contents;
}
/** The Constant m_contents. */
private static final Object[][] m_contents =
{
{"OAM-1", " An incorrect Username or Password was
specified "},
{"OAM-2", " An incorrect Username or Password was
specified "},
{"OAM-3", "Unexpected Error occurred while processing
credentials. Please retry your action again!"},
{"", ……};
}
}
例4-2 エラー・コード・ページ
<%@page import="mytest.error.ExampleErrorMsg"%>
//initializing the messageBundle first
String defaultResourceBundle = "mytest.error.ExampleErrorMsg";
java.util.Locale myLocale = request.getLocale();
ResourceBundle msgBundle=
ResourceBundle.getBundle(defaultResourceBundle,myLocale);
String errCode = request.getParameter("p_error_code");
String secondaryErrMessage = request.getParameter("p_sec_error_msg");
<%
if(errCode != null && errCode.length() > 0) {
try {
simpleMessage = msgBundle.getString(errCode);
} catch(Exception e) {
//get the default authn failed message
simpleMessage = msgBundle.getString("OAM-8");
}
%>
<div class="message-row">
<p class="loginFailed"> <%=simpleMessage%> </p>
</div>
ユーザー向けのページでは、パスワード・ポリシーの結果コンテキストにアクセスでき、該当するメッセージを取得できます。各メッセージには、場合によって追加情報が含まれていることがあります。次のコードの抜粋は、ページでパスワード・ポリシーの結果コンテキストからメッセージと追加情報を取得する方法を示しています。
String simpleMessage = "";
String result = request.getParameter("rejectedRuleDesc");
if(result.indexOf('~') != -1) {
String[] results = result.split("~");
for(String eachResult : results) {
if(eachResult.indexOf(":") != -1) {
String messageKey = eachResult.substring(0, eachResult.indexOf(":"));
String resourceBundleKey = UrlSubstitutionMessages.ERRORCODEMAP.get(messageKey);
String placeHolderValue = eachResult.substring(eachResult.indexOf(":") + 1, eachResult.length());
String displayValue = Localizer.localize(resourceBundleKey, placeHolderValue, myLocale);
simpleMessage += displayValue + "<br>";
}
else {
String resourceBundleKey = UrlSubstitutionMessages.ERRORCODEMAP.get(eachResult);
String displayValue = Localizer.localize(resourceBundleKey, null, myLocale);
simpleMessage += displayValue + "<br>";
}
}
}
たとえば、パスワードの文字数が足りない場合、コンテキストの結果は次のようになります。
PasswordRuleDescription.getResourceBundleKey()が"passwordPolicy.error.minLength"を返します。
PasswordRuleDescription.getPlaceHolderValue()が最小文字数を返します。
PassswordRuleDescription.eachDesc.getDisplayValue()が完全に翻訳されたメッセージを返します。
ユーザー向けのページでは、ユーザーに適用されるパスワード・ポリシー・ルールにアクセスできます。各メッセージには、場合によって追加情報が含まれていることがあります。次のコードの抜粋は、ページでパスワード・ポリシーの結果コンテキストからルールと追加情報を取得する方法を示しています。
String simpleMessage = "";
String result = request.getParameter("ruleDesc");
if(result.indexOf('~') != -1) {
String[] results = result.split("~");
for(String eachResult : results) {
if(eachResult.indexOf(":") != -1) {
String messageKey = eachResult.substring(0, eachResult.indexOf(":"));
String resourceBundleKey = UrlSubstitutionMessages.ERRORCODEMAP.get(messageKey);
String placeHolderValue = eachResult.substring(eachResult.indexOf(":") + 1, eachResult.length());
String displayValue = Localizer.localize(resourceBundleKey, placeHolderValue, myLocale);
simpleMessage += displayValue + "<br>";
}
else {
String resourceBundleKey = UrlSubstitutionMessages.ERRORCODEMAP.get(eachResult);
String displayValue = Localizer.localize(resourceBundleKey, null, myLocale);
simpleMessage += displayValue + "<br>";
}
}
}
たとえば、パスワードの文字数が足りない場合、コンテキストの結果は次のようになります。
PasswordRuleDescription.getResourceBundleKey()が"passwordPolicy.error.minLength"を返します。
PasswordRuleDescription.getPlaceHolderValue()が最小文字数を返します。
PassswordRuleDescription.eachDesc.getDisplayValue()が完全に翻訳されたメッセージを返します。
表4-5は、認証プラグインで使用できるエラー・データ・ソースをまとめたものです。
表4-5 認証プラグインのエラー・データ・ソース
| ソース | パラメータ |
|---|---|
|
エラー・コード |
HTTPリクエスト・パラメータ: |
|
プライマリ・エラー・メッセージ |
リソース・バンドルからエラー・コードを使用して取得されます。 |
|
セカンダリ・エラー・メッセージ(内部エラー・モードの場合のみ送信) |
HTTPリクエスト・パラメータ: |
|
サーバー・エラー・コードを連結したリスト |
HTTPリクエスト・パラメータ: |
|
パスワード・プラグインのエラー・メッセージ |
HTTPリクエスト・パラメータ: |
|
プラグイン・クライアント・レスポンス |
HTTPリクエスト・パラメータ: PLUGIN_CLIENT_RESPONSE |
|
プラグイン・エラー・レスポンス |
HTTPリクエスト・パラメータ: PLUGIN_ERROR_RESPONSE |
この項には次のトピックが含まれます。
外部資格証明コレクタ(DCC)を使用してカスタム・ページを開発する場合の主な相違点は次のとおりです。
次のWebgate Oracleホーム(WebgateOH)ディレクトリにあるHTMLテンプレートを使用してPerlスクリプトとして実装されたデフォルト・ページとともに、DCCがインストールされます。
WebgateOH/webgate/ohs/oamsso
WebgateOH/webgate/ohs/oamsso-bin
サポートされている認証メカニズムのログイン・ページの他に、デフォルト・エラー・ページおよびデフォルト・ログアウト・ページをカスタマイズできます。
認証フローの外でエラー状態が発生したときや、認証スキームで失敗リダイレクトURLが指定されていない場合、デフォルト・エラー・ページがトリガーされます。デフォルト・エラー・ページのテンプレートおよび関連付けられたエラー・メッセージは、Webgate Oracleホーム内の言語およびロケールごとのサブディレクトリにあります。たとえば、en-usの正確な場所はWebgateOH/webgate/ohs/lang/en-us/WebGate.xmlです。
デフォルト・ログアウト・ページは、WebgateOH/webgate/ohs/oamsso-bin/logout.plにあります。
DCC自体はカスタム・ページの開発言語を制約しません。カスタム・ページは、DCCをホストしているOracle HTTP Server上にデプロイするか、JSPまたはサーブレットの場合は、それを実行するためのWebコンテナ上にデプロイする必要があります。
収集されたデータをDCCにポストするときに使用するHTMLフォームでは、構成可能なURLを使用してこれをポストできます。認証スキームのactionチャレンジ・パラメータで、資格証明を収集できるURLを指定します。
requestid問合せパラメータの処理は必要ありません。
ユーザー名とパスワードなど、ユーザーの資格証明を送信できるHTMLフォームを作成します。詳細は、第4.2.1項「フォームベース・ログイン・ページの作成」を参照してください。
フォームを、DCCを持つWebサーバー上の、保護されていないディレクトリまたは匿名認証スキームで保護されているディレクトリに置きます。
フォームベース認証スキームを作成し、チャレンジURLとしてログイン・フォームへのパスを指定します。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
HTTP GETまたはPOSTを使用して、フォーム・アクションをコールします。
ログイン・フォームのアクションで、ポリシーを使用してターゲットURLを保護します。
チャレンジ・パラメータを認証スキームで構成します。
資格証明の処理に使用する認証モジュールを指定します。
カスタム・ログイン・ページをWARファイルとして作成し、必要なリソース・バンドル・ファイルと一緒にパッケージ化できます。WARファイルは、DCCの背後にあるアプリケーション上にデプロイできます。DCCが使用されていない場合は、ECCが実行されているサーバーと同じサーバー上にこのページをデプロイできます。ECCを使用している場合は、カスタムWARファイルを使用して認証スキームに次の設定を指定する必要があります。
コンテキスト・タイプ = CustomWar
チャレンジURL = WARファイル内のログイン・ページのURLに対する相対パス
コンテキスト値 = カスタムWARのルート・パスカスタマイズしたエラー・ページをカスタムWARファイルに含める場合は、その絶対URLを認証ポリシーの失敗リダイレクトURIで指定する必要があります。たとえば、http://host:port/SampleLoginWar/pages/MFAError.jspです。
認証スキームとその管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の認証スキーム・ページについての項を参照してください。
この項には次のトピックが含まれます。
HTTPクライアントAPIを使用したプログラムによる認証は、OSSO 10gおよび11g OAMサーバーの両方でサポートされています。
通常、OSSO 10gプログラムによるクライアントは、URLリダイレクトを検索して認証フローを識別します。デフォルトの認証スキームは、埋込みログイン・ページを使用するよう構成されています。OAMサーバーは、リダイレクションを使用するかわりにログイン・ページにフォワードします。OSSO 10g形式のプログラムによるクライアントを動作させるには、資格証明コレクタを外部モードで構成する必要があります。
10gリリースからのアップグレードの場合は、新規のカスタム・ログイン・ページを使用するよう認証スキームSSOCoexistMigrateSchemeを構成します。新規に11gリリースをインストールした場合は、リソースの認証に使用するスキーム、つまりLDAPSchemeを編集します。
チャレンジURLが完全修飾カスタムURLを指すように設定します。たとえば、http://host:port/sample-web/login.jspとなります。また、コンテキスト・タイプをexternalに設定します。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の認証スキームの管理に関する項を参照してください。
11gリリースのOAMサーバーでは、JavaScriptを使用して資格証明入力用のログイン・フォームをクライアントに送信します。クライアントまたはデバイスがスクリプトベースのリダイレクトに対応していない場合は、クライアントが使用するユーザー・エージェントをプログラムによるクライアントとして構成する必要があります。すると、OAMサーバーは、そのクライアントをブラウザ・ベースのクライアントではなくプログラムによるクライアントとして認識します。この場合、OAMサーバーはJavaScriptベースのリダイレクトを使用します。
次に、oam-config.xmlでの構成設定の例を示します。 userAgentType設定の下には複数のエントリを追加できます。
<Setting Name="userAgentType" Type="htf:map"> <Setting Name="Mozilla/4.0 (compatible; Windows NT 5.1) OracleEMAgentURLTiming/3.0" Type="xsd:string">PROGRAMATIC</Setting> </Setting>
OSSO 10gとAccess Manager 11gの、どちらのプログラムによるクライアントを開発する場合も次のプロセスを使用します。
アプリケーションからクライアントAPIを使用して、保護されているリソースをHTTPチャネル経由で呼び出します。
アクセスされたリソースを保護するmod_ossoパートナがsite2pstoretokenを生成し、認証のためにOAMサーバーへリダイレクトします。
OAMサーバーが、リクエスト・パラメータsite2pstoretokenとp_submit_urlを持つログイン・ページへリダイレクトします。
p_submit_urlには、プログラムによる認証エンドポイントが格納されています。たとえば、http(s)://host:port/sso/authとなります。デフォルトのブラウザ・アクションURLはサーバー側にセッションを作成しますが、プログラムによる認証エンドポイントにはこのURLがありません。プログラムによる認証エンドポイントは、認証ごとにセッションを作成するのではなく、1ユーザーに1個のグローバル・セッションを使用します。このセッションは、特定の1ユーザーに対してプログラムによって実行されるすべての認証に共通です。
プログラムによるクライアントからプログラムによるエンドポイントへ資格証明が送信されます。
クライアントは、手順3で取得したssousername、password、s2pstoretokenの情報をp_submit_urlへ送信する必要があります。
OAMサーバーが資格証明を検証し、有効ならば、最初の保護されたアプリケーションへリクエストをリダイレクトします。
資格証明の検証がエラーの場合は、p_error_codeが返されます。
11gリリースの場合、要求していないPOSTを使用したプログラムによる認証には、次のプロセスを使用してください。
直接認証を有効化します。
oam-config.xmlで、DirectAuthenticationServiceDescriptorの下のServiceStatusがtrueに設定されていることを確認します。(DirectAuthenticationServiceDescriptorはOAMServicesDescriptorの下にあります)。
次の情報をエンドポイントhttps://oam_host:oam_port/oam/server/authenticationに送信します。
ユーザー名
パスワード
成功URL。例: http://machinename.mycompany.com:7778/sample-web/headers.jsp
資格証明が認証されると、OAMサーバーはHTTPリダイレクト(HTTPレスポンス・コード302)の一部としてOAM_ID Cookieを設定してから、成功URLにリダイレクトします。
直接認証をPOSTでのみ許可する(またはその逆の)手順は次のとおりです。
Oracle Access Management管理コンソールにログインし、「ポリシー構成」→「アプリケーション・ドメイン」に移動します。
「IAMSuite」を選択します。「リソース」に移動し、リソース/oamDirectAuthenticationを検索して編集します。
「操作」で、POSTを除く、サポートしないすべての操作の選択を解除します。たとえば、GET、DELETEなどです。
ユーザー名とパスワードの資格証明の認証方法を成功URLごとに変える手順は次のとおりです。
直接認証リクエスト時にusername、passwordおよびsuccessurlとともに、パラメータtypeと認証メカニズムを指定する値を渡します。
「IAMSuite」アプリケーション・ドメインに移動します。リソースURL /oamDirectAuthentication、およびtypeという名前の問合せ文字列と手順1で指定した値を使用して、新規のリソースを作成します。
このリソースを、選択したtypeをサポートする認証スキームに関連付けます。
URL /oamDirectAuthenticationと問合せ文字列typeの様々な値(例: type=FORM、type=CREDS)を使用して複数のリソースを作成し、対応する認証スキームに関連付けます。
mod_ossoエージェントについて、11gリリースではカスタムCookieの設定をサポートしています。10gおよび11g Webgateの場合、これは認証および認可レスポンス型Cookieによって実現されます。
OSSOカスタムCookieを構成する手順は次のとおりです。
Oracle Access Management管理コンソールにログインします。
OSSOエージェントのアプリケーション・ドメインに移動します。
保護されているリソースの認証ポリシーを選択します。
「レスポンス」タブをクリックします。
Cookieレスポンスを追加します。デプロイメントのCookieは、Access Manager 11g認証レスポンス・フォーマットに準拠した名前と値を使用して作成する必要があります。次に例を示します。
名前: ORASSO_AUTH_HINT、タイプ: Cookie、値: v1.0~${session.expiration}
名前: ORASSO_UCM_COOKIE1、タイプ: Cookie、値: v2.0~${user.attr.displayname}~${user.attr.given}
名前: ORASSO_UCM_COOKIE2、タイプ: Cookie、値: v3.0~${user.attr.uid}~${user.attr.mail}
変更内容を保存します。
mod_ossoで保護されたアプリケーションにアクセスして、認証後にCookieが作成されていることを確認します。
OSSO Cookieは、デフォルトでは.example.comドメインで設定され、1年後に有効期限が切れるように設定されます。この設定は、次のWLSTコマンドを使用して変更できます。
updateOSSOResponseCookieConfig
deleteOSSOResponseCookieConfig
updateOSSOResponseCookieConfigを使用した例を次に示します。
help('updateOSSOResponseCookieConfig')
Description:
Updates OSSO Proxy response cookie settings in system configuration.
Syntax:
updateOSSOResponseCookieConfig(cookieName = "<cookieName>",cookieMaxAge = "<cookie age in minutes>", isSecureCookie = "true | false",cookieDomain="<domain of the cookie>", domainHome = "<wls_domain_home_path>")
cookieName = Name of the cookie for which settings are updated. This is optional parameter. If parameter is not specified global setting is updated.
cookieMaxAge = Max age of cookie in minutes. A negative value will set a session cookie.
isSecureCookie = Boolean flag specifies if cookie should be secure which wouldbe sent only in SSL channel.
cookieDomain = The domain of the cookie.
domainHome = location of domain home <mandatory for offline commands,not required for online>
Example:
updateOSSOResponseCookieConfig(cookieName = "ORASSO_AUTH_HINT",cookieMaxAge = "525600", isSecureCookie = "false", cookieDomain=".example.com",domainHome = "<wls_domain_home_path>")
deleteOSSOResponseCookieConfigを使用した例を次に示します。
help('deleteOSSOResponseCookieConfig')
Description:
Deletes OSSO Proxy response cookie settings in system configuration.
Syntax:
deleteOSSOResponseCookieConfig(cookieName = "<cookieName>",domainHome = "<wls_domain_home_path>")
cookieName = Name of the cookie for which settings are updated. This is mandatoryparameter. The global cookie setting cannot be deleted.
domainHome = location of domain home <mandatory for offline commands,not required for online>
Example:
deleteOSSOResponseCookieConfig(cookieName = "ORASSO_AUTH_HINT",domainHome = "<wls_domain_home_path>")
updateコマンドでCookie名を指定しないと、すべてのCookieのグローバル設定が更新されます。Cookie名を指定すると、特定のCookieのパラメータがオーバーライドされます。次に例を示します。
updateOSSOResponseCookieConfig(cookieMaxAge = "525600", isSecureCookie = "false", cookieDomain=".mycompany.com") updateOSSOResponseCookieConfig(cookieName="ORASSO_AUTH_HINT", cookieMaxAge = "-1", isSecureCookie = "false", cookieDomain=".mycompany.com") updateOSSOResponseCookieConfig(cookieName="ORASSO_UCM_COOKIE2", isSecureCookie = "true", cookieDomain=".us.mycompany.com") deleteOSSOResponseCookieConfig(cookieName = "ORASSO_UCM_COOKIE2")
