Oracle® Fusion Middleware Oracle Access Management開発者ガイド 11gリリース2 (11.1.2.3.0) for All Platforms E67354-04 |
|
前 |
次 |
Oracle Access Managerはデフォルトのログイン、ログアウト、エラーおよびパスワード・ページに加え、会社のブランドに合せたルック・アンド・フィールのカスタム・ページを作成できる拡張可能なフレームワークを提供しています。
この章では、カスタム・ページの開発方法および使用している環境へのデプロイ方法について説明します。この章には、次の項が含まれています。
最も簡単な形態として、Access Managerには、ユーザーに表示される静的HTMLページのセットを含むフレームワークが用意されています。これらのデフォルト・ページを自社のルック・アンド・フィールを反映するようにカスタマイズしたり、すべて新しいページに置き換えることができます。ログイン、ログアウトおよびエラー条件処理時の認証で使用する対話型のカスタム・ページを作成できます。
通常、カスタム・ページ・フレームワークは動的であり、必要なロジックを実行できるスクリプトまたはアプリケーションとして実装する必要があります。そのため、たとえばユーザーがモバイル・ブラウザかデスクトップ・ブラウザのどちらからアクセスしているかに応じて異なるバージョンのログイン・フォームを表示するカスタムHTMLページを設計、実装およびデプロイできます。
ログイン、ログアウト、エラーおよびパスワード・ページは、カスタム・ページ・フレームワークの一部としてパッケージ化されます。すぐに使用できるWebアプリケーション・アーカイブ(WAR)ファイルが用意されているので、これを開始ポイントとしてカスタム・ページを開発できます。このWARの名前はoamcustompages.warで、MW_HOME/oam/server/tools/custompages/
ディレクトリにあります。カスタムHTMLページを作成して、WARに追加してください。詳細は、第4.3.1項「フォームベース・ログイン・ページの作成」を参照してください。
注意: カスタム・ページは、既存のAccess Manager認証モジュールまたはカスタム認証プラグインと組み合せて使用できます。プラグインの開発の詳細は、第3章「カスタム認証プラグインの開発」を参照してください。 |
ユーザー向けのカスタム・ページは、OAM_REQトークンおよび認証エンドポイントを返す必要があります。詳細は、次の各項を参照してください。
OAM_REQは、認証リクエスト・コンテキストCookieが有効な場合にAccess Managerによって設定または消去される一時的なCookieです。このCookieは、Access Managerのみが認識しているキーで保護されています。OAM_REQは、問合せ文字列から取得して非表示のフォーム変数として返送する必要があります。
注意: 詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』のSSO Cookieの概要に関する項を参照してください。 |
リソースがリクエストされると、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".
認証プロセスでは、リソースへのアクセスをリクエストしているユーザーに必要な資格証明を確認し、HTTPを介して資格証明を収集し、資格証明の検証結果を反映したHTTPレスポンスを返します。図4-1は、Access Managerで保護されたリソースにアクセスするユーザーを認証するエンドツーエンドのリクエスト・フローで、最終的にエラー・ページが表示されます。
このプロセスでは、認証(AuthN)プラグインを使用する特定の認証スキームによってリソースが保護されています。AuthNプラグインがアイデンティティ・ストアAPIを使用して資格証明を認証します。AuthNプラグインは、サード・パーティAPIもコールできます(図には非表示)。
ユーザーが保護されたリソースをリクエストすると、認証フローがトリガーされ、ログイン・ページが表示されます。ユーザーが入力する必要な資格証明が、認証エンジンに送信されます。
認証を行うために、アイデンティティ・ストアAPIがバックエンド・ストアとの接続を確立します。アイデンティティ・ストアの例としてADとOVDが記載されています。
アイデンティティ・ストア・レイヤーが、結果をプラグインおよび認証エンジン・レイヤーに返します。認証レイヤーで、バックエンドからのエラー・コードが対応するAccess Managerエラー・コードにマップされます。標準エラー・コードの詳細は、表4-2を参照してください。
この結果には、アイデンティティ・ストアから取得した認証エラー・コードおよびネイティブ・エラー・コードが含まれます。ネイティブ・エラー・コードは、マップされていないセカンダリ・エラー・コード(p_sec_error_msg
)としてログイン・ページに返されます。セカンダリ・エラー・コードの詳細は、第4.4.4項「セカンダリ・エラー・メッセージの伝播」を参照してください。
エラー・コードは問合せパラメータとしてエラー・ページおよびログイン・ページに返されます。エラー・コードはHTTPリクエスト・パラメータとしてエラー・ページに送信されます。問合せパラメータはp_error_code
という名前です。
プライマリ・エラー・コード・メッセージとは、エラー・コードの詳細テキストを含むローカライズされた文字列です。これは、該当するリソース・バンドル・ファイルからエラー・コードを使用して取得できます。
次の各項では、詳細を説明します。
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.example.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
)を使用して複数のリソースを作成し、対応する認証スキームに関連付けます。
次の手順は、DCC WebGatesを使用する非請求ログインを構成します。
DCC WebGateを構成します。
『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
直接認証を有効化します。
oam-config.xml
ファイルのDirectAuthenticationServiceDescriptorの下にあるServiceStatusがtrueに設定されていることを確認します。DirectAuthenticationServiceDescriptorパラメータは、OAMServicesDescriptorの下にあります。
DCC WebGateプロファイルのユーザー定義パラメータに、TunneledUrls=/oam/server/authentication
を追加します。
/oam/server/authentication
は直接認証URLです。Tunneled URLの構成に関する情報は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
DCC WebGateを再起動します。
ホスト/ポートのバリエーションがリソースのWebGateに追加されたことを確認します。
たとえば、リソースのWebGateがhttp://<RWG-Host>:<port>/
の場合、ホストのバリエーション<RWG-Host>とポートのバリエーション<port>をHost Identifierに追加します。
注意: DCC WebGatesではHost Identifierの構成は不要なので、リソースのWebGateホスト識別子にのみホストのバリエーションを追加します。リソースWebGateおよびDCC WebGateには、異なるプロファイルとホストの識別子のセットがあります。 |
DCC WebGateアプリケーション・ドメインのパブリック・リソース認可および認証ポリシーを使用して、/pages/login.jsp
と/oam/**
と/oamsso-bin/login.pl
を保護します。
/oam/server/authentication
は、DCCアプリケーション・ドメインのパブリック・リソース認可および認証ポリシー・スキームで保護してください。/oamsso-bin/login.pl
と/pages/login.jsp
はログイン・ページであり、DCCのパブリック・リソースとしてマークしてください。successurl値は保護されている必要があり、ポスト・パラメータとして提供されます。
DCC認証エンドポイントには、http://<dcc-host>:<dcc-port>/oam/server/authentication
でアクセスできます。
特定のアプリケーションにマップできるTYPEパラメータがあります。リソースにアクセスするには、このDCCエンドポイントにユーザー名、パスワードおよびsuccessurlパラメータをポストします。
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=".example.com") updateOSSOResponseCookieConfig(cookieName="ORASSO_AUTH_HINT", cookieMaxAge = "-1", isSecureCookie = "false", cookieDomain=".example.com") updateOSSOResponseCookieConfig(cookieName="ORASSO_UCM_COOKIE2", isSecureCookie = "true", cookieDomain=".us.example.com") deleteOSSOResponseCookieConfig(cookieName = "ORASSO_UCM_COOKIE2")
カスタム・ログイン・ページを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管理者ガイド』の認証スキーム・ページについての項を参照してください。 |
詳細は、次の各項に記載されています。
フォームベース認証では、Access Managerの認証メカニズムを使用してログイン資格証明を処理するカスタムWebフォームを開発できます。これらのフォームはHTMLページであり、ログイン情報を複数言語で表示したり、会社のプレゼンテーション標準に準拠したユーザー・インタフェース・エレメントを表示したり、パスワード管理に必要な機能を追加することができます。
フォームまたはログイン・アプリケーションは、ユーザーからのリダイレクトを処理してHTMLをレンダリングする任意のテクノロジ(JSP、ASP.net、Perl、PHPなど)を使用して記述できます。これによって、会社の標準を反映するようにページのルック・アンド・フィールをカスタマイズしたり、ユーザーの資格証明をOAMサーバーに送信する前にユーザーの送信(POST)を前処理することが、必要に応じてできるようになります。
リクエスト・キャッシュのモードとして、basic
、cookie
、form
の3つがサポートされています。basic
モードで動作する場合、request_id
が必須パラメータであり、返送する必要があります。form
モードでは、OAM_REQトークンが必須であり、存在する場合は返送する必要があります。cookie
モードでは、OAM_REQがCookieとして設定されます。
カスタム・ログイン・フォーム・ページには次のような要件があります。
目的の認証モジュールをサポートするようにページを構築する必要があります。
ページでOAM_REQトークンの取得をサポートする必要があります。第4.1.1項「OAM_REQトークンを返す」を参照してください。
ページでエンド・ポイントを取得する必要があります。第4.1.2項「エンド・ポイントを返す」を参照してください。
Access Managerによる認証に対応したカスタム・ログイン・ページを記述する場合、OAMサーバーの外部でホストされたログイン・ページへユーザーをリダイレクトするのが一般的な方法です。ユーザーは、記述したカスタム・ページまたはアプリケーションにリダイレクトされます。
フォームベース認証スキームが外部チャレンジ・タイプで作成されている場合、OAMエージェントはユーザーをまずobrareq.cgi
URLへリダイレクトし、このURLはこのユーザーを、認証スキームのチャレンジURLとして指定されたログイン・ページへリダイレクトします。チャレンジ・リダイレクトURLは、DCCまたはECCエンドポイントを宣言します。チャレンジURLは、FORMなどのチャレンジ・メソッドに関連付けられたURLです。
リダイレクト・ページで、request_id
とredirect_url
が問合せ文字列に追加されます。次に例を示します。
?request_id=5092769420627701289&redirect_url=http%3A%2F%2Fexample.com%3A7777%2Fscripta%2Fprintenv
x509認証スキームを使用する場合は、透過的に認証が実行されるため、ログイン資格証明専用のページはありません。ただし、ページ・リダイレクションは非フォームベースの認証方式にも適用されます。たとえば、x509認証スキームを使用する場合、保護されているリソースを表示する前に、機密保護に関する免責条項などへユーザーをリダイレクトできます。この場合、免責条項ページへのパスを入力し、そのページを/oam/CredCollectServlet/X509
ページにリダイレクトさせます。オリジナルの問合せスキームを必ず提示してください。
この項では、カスタム・エラー・ページの開発に固有の情報について説明しています。次の情報が含まれます。
使用している環境で、エラー・コード問合せパラメータp_error_code
およびp_sec_error_msg
がどのようにカスタム・エラー・コードにマップされるかについては、第4.4.5項「サンプル・コード: エラー・コードの取得」を参照してください。
カスタム・エラー・ページをパッケージ化し、そのまま使用できるWebアプリケーション・アーカイブ(WAR)ファイルとしてデプロイすると、updateCustomPages
WLSTコマンドを使用して有効化および無効化できます。カスタム・エラー・ページには、カスタムWebアプリケーションをデプロイする際に従う必要がある特定の場所があります。その場所を次に示します。
http(s)://<host>:<port>/<context>/pages/Error.<pageExtension>
updateCustomPages
やその他のWLSTコマンドを使用する方法に関する情報は、『Oracle Fusion Middleware WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンス』と、この章の「カスタム・エラー・ページおよびカスタム・ログアウト・ページのデプロイメント・パスの指定」にあります。
Access Managerでは、失敗の理由を示す標準エラー・コードが提供されています。一般的な理由として、ユーザー名およびパスワードの無効な組合せ、ロック中または無効なユーザー・アカウント、内部処理エラーなどがあります。認証エラーの理由はバックエンド・アイデンティティ・ストアから取得され、Access Managerサーバーで管理されている特定のエラー・コードにマップされます。そして、このエラー・コードがログインまたはエラー・ページに伝播されます。(カスタム・エラー・ページには、内部サーバー・エラーも表示されます。)
表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 |
パスワードの有効期限が切れました。システム管理者に連絡してください。 |
エラー・コードのセキュリティ・レベルによって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の場合、資格証明を再度収集できるので、ユーザーはログイン・ページに戻されます。
認証エンジン・レイヤーで、バックエンド・アイデンティティ・ストアからの例外がOAMサーバー固有のエラー・コードにマップされます。その後、これらのコードが伝播されます。プラグインは、セカンダリ・エラー・コードを取得して伝播することにより、適切なアクションを実行させることができます。
注意: プライマリ・エラー・コードは、どのモードでもエラーまたはログイン・ページに伝播されます。セカンダリ・エラー・メッセージは、セキュリティ・レベルが内部に設定されている場合のみ伝播されます。詳細は、第4.4.3項「セキュリティ・レベルの構成」を参照してください。 |
セカンダリ・エラー・メッセージは、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など)。
カスタム・ログイン・ページをカスタム・リソース・バンドルに関連付けることにより、エラー・コードを意味のあるメッセージに変換してエンド・ユーザーに表示できます。ただし、意味のあるエラー・メッセージや翻訳がカスタム・ログイン・ページで必要なければ、カスタム・リソース・バンドルは必要ありません。
ローカル・リソース・バンドル・ファイルを作成し、表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>
表4-4は、認証プラグインで使用できるエラー・データ・ソースをまとめたものです。
表4-4 認証プラグインのエラー・データ・ソース
ソース | パラメータ |
---|---|
エラー・コード |
HTTPリクエスト・パラメータ: |
プライマリ・エラー・メッセージ |
リソース・バンドルからエラー・コードを使用して取得されます。 |
セカンダリ・エラー・メッセージ(内部エラー・モードの場合のみ送信) |
HTTPリクエスト・パラメータ: |
サーバー・エラー・コードを連結したリスト |
HTTPリクエスト・パラメータ: |
パスワード・プラグインのエラー・メッセージ |
HTTPリクエスト・パラメータ: |
プラグイン・クライアント・レスポンス |
HTTPリクエスト・パラメータ: PLUGIN_CLIENT_RESPONSE |
プラグイン・エラー・レスポンス |
HTTPリクエスト・パラメータ: PLUGIN_ERROR_RESPONSE |
Access Managerは、フォームベースのJava Server Pages (JSP)でユーザーが入力したパスワードおよびパスワードの変更を処理します。このページは、複数の言語でカスタマイズしたり、会社のロゴを表示できます。ユーザー認証用のカスタム・パスワード・ページを記述する一般的な方法は、Access Managerの外部にホストされているパスワード・ページにユーザーをリダイレクトすることです。カスタム・ページは、ユーザーからのリダイレクトを処理してHTMLをレンダリングするように記述します。これは、JSPで保管することも、ASP.net、Perl、PHPおよび他の同様なテクノロジを使用して記述することもできます。このページによって、ユーザーの資格証明をAccess Managerに送信する前に、必要に応じてユーザーの送信(POST)を前処理できるようになります。後続の項で詳細を示します。
ログインおよびパスワード・ページに必要な変換バンドルを含む基本的なWebアーカイブ(WAR)ファイルは、Access Managerをインストールする際に提供されます。このWARはoamcustompages.war
と呼ばれ、パスワード・ページをカスタマイズする際の開始点となります。カスタム・パスワード・サービス・フォーム・ページの要件は、次のとおりです。
「OAM_REQトークンを返す」の説明にあるように、ページはOAM_REQトークンの取得をサポートする必要があります。
「エンド・ポイントを返す」の説明にあるように、ページはエンド・ポイントを取得する必要があります。
このWARは、$IDM_HOME//oam/server/tools/custompages/ディレクトリにあります。このWARを使用すると、基本的な構造がすでに存在しているというメリットを得られます。図4-2にWARの構造を示します。CSSおよび画像は、要件に応じてカスタマイズ可能です。
リクエスト・キャッシュのモードとして、basic、form、cookieの3つがサポートされています。
basicモードでは、request_idが必須パラメータとして定義されており、これを返送する必要があります。
formモードでは、OAM_REQトークンが必須として定義されており、可能な場合はこれを返送する必要があります。
cookieモードでは、OAM_REQをCookieとして設定します。
パスワード・ページの開始点はpswd.jsp
です。このページの場所は、Oracle Access Management管理コンソールを使用して、「パスワード・ポリシー」の下に構成されます。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
管理者としてAccess Manager管理コンソールにログインします。
「Access Manager」の下の「パスワード・ポリシー」リンクをクリックします。
「パスワード・サービスURL」属性の値を定義または変更します。
「適用」をクリックします。
ユーザー向けのページでは、パスワードの有効期限が切れるまでの日数にアクセスできます。次のコード・スニペットで、パスワードの有効期限が切れるまでの日数または時間を取得する方法を示します。
String message = ""; if(errCode != null && errCode.equals("1")) { message = msgBundle.getString("USER_PSWD_WARNING") + errCode + msgBundle.getString("USER_PSWD_DAY"); } else if (errCode != null && errCode.equals("0")) { message = msgBundle.getString("USER_PSWD_WARNING_HOURS"); } else { message = msgBundle.getString("USER_PSWD_WARNING")+ " " + errCode + " " + msgBundle.getString("USER_PSWD_DAYS"); }
ユーザー向けのページでは、パスワード・ポリシーの結果コンテキストにアクセスでき、該当するメッセージを取得できます。各メッセージには、場合によって追加情報が含まれていることがあります。次のコードの抜粋は、ページでパスワード・ポリシーの結果コンテキストからメッセージと追加情報を取得する方法を示しています。
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()
が完全に翻訳されたメッセージを返します。
パスワード・プラグインがパスワード・ページにリダイレクトし、対応するメッセージがパスワード・ポリシーから取得されます。これらのエラー・コードは、HTTPリクエスト・パラメータruleDes
としてパスワード・ポリシー・ページに送信されます。表4-5は、パスワードの検証時に返される可能性のあるエラー・コード、メッセージ・キーおよび対応するメッセージのリストです。
表4-5 パスワード検証エラー・コード
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文字は使用できません。 |
ユーザー向けのページでは、ユーザーに適用されるパスワード・ポリシー・ルールにアクセスできます。各メッセージには、場合によって追加情報が含まれていることがあります。次のコードの抜粋は、ページでパスワード・ポリシーの結果コンテキストからルールと追加情報を取得する方法を示しています。
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()
が完全に翻訳されたメッセージを返します。
2つのAccess Manager資格証明収集コンポーネントのどちらか一方を有効にして、カスタム・ページ向けの通信エンドポイントとして使用したり、カスタマイズしたユーザー・インタフェースとの対話を容易にすることができます。Access Manager資格証明収集コンポーネントには次のものがあります。
組込み資格証明コレクタ(ECC): 追加のインストールや設定なしですぐに使用できます。ECCを使用する場合、デフォルト・ページには以下の場所からアクセスできます。
ログイン・ページ: http(s)://host:port/oam/pages/login.jsp
エラー・ページ: http(s)://host:port/oam/pages/servererror.jsp
外部資格証明コレクタ(DCC): 本番デプロイにおけるスケーラビリティおよびセキュリティ分離を向上させる場合には、これをお薦めします。DCCを使用する場合、デフォルト・ページには次の場所からアクセスできます。
ログイン・ページ: /oamsso-bin/login.pl
ログイン・アクションURL: /oam/server/auth_cred_submit。これは、認証スキーム・パラメータでaction
が構成されていない場合のデフォルトのアクションURLです。デフォルトのURLに対応する物理ページはありません。URLの場所に物理ページが必要になるのは、認証スキームでaction
が構成されており、アクションURLでランタイムaction type
の結果がパス・スルーの場合のみです。
エラー・ページ: /oberr.cgi。これは、DCCによって認識されるURLパターンであり、物理的な場所ではありません。
ユーザーとの対話用にどちらの資格証明収集コンポーネントを有効にした場合も、使用している環境におけるカスタム・ページの設計や実装はほとんど同じです。
注意: Access Managerサーバーの資格証明コレクタの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の11g Webgateの動的資格証明収集のための構成に関する項を参照してください。 |
この項では、DCCの詳細を説明しています。
カスタム・ページから資格証明を収集するために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をホストしているOracle HTTP Server上にデプロイするか、JSPまたはサーブレットの場合は、その前にあるWebコンテナ上にデプロイできます。
HTMLフォームが収集したデータをDCCにポストできるよう、構成可能なURLを使用します。認証スキームのaction
チャレンジ・パラメータで、資格証明を収集できるURLを指定します。
requestid
問合せパラメータの処理は必要ありません。
ユーザーの資格証明(ユーザー名およびパスワード)を送信できるHTMLフォームを作成します。
詳細は、第4.3.1項「フォームベース・ログイン・ページの作成」を参照してください。
フォームを、DCCを持つWebサーバー上の、保護されていないディレクトリまたは匿名認証スキームで保護されているディレクトリに置きます。
フォームベース認証スキームを作成し、チャレンジURLとしてログイン・フォームへのパスを指定します。
詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
HTTP GETまたはPOSTを使用して、フォーム・アクションをコールします。
ログイン・フォームのアクションで、ポリシーを使用してターゲットURLを保護します。
チャレンジ・パラメータを認証スキームで構成します。
資格証明の処理に使用する認証モジュールを指定します。
DCCトンネリングを使用する場合、カスタム・ログインおよびエラー・ページを作成できます。デフォルト・ページには、次の場所からアクセスします。
ログイン・ページ: http(s)://DCChost:DCCport/oam/pages/login.jsp
エラー・ページ: http(s)://DCChost:DCCport/oam/pages/servererror.jsp
これらのカスタム・ページを作成、使用するには、手順(「DCCを使用したフォームベース・ログイン・ページの作成」に類似)に従ってください。資格証明コレクションとDCCトンネリングの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
カスタム・アプリケーションをデプロイする際、カスタム・エラーおよびログアウト・ページは特定のパスにする必要があります。エラー・ページのパスは次のとおりです。
http(s)://<host>:<port>/<context>/pages/Error.<pageExtension>
ログアウト・ページのパスは次のとおりです。
http(s)://<host>:<port>/<context>/pages/Logout.<pageExtension>
contextおよびpageExtensionは、updateCustomPages
WLSTコマンドを使用して構成できる変数です。pageExtensionのデフォルト値はjspですが、コマンドを実行している間、空白のままにしておくこともできます。updateCustomPages
によって、コンテキスト・パスおよびページ拡張子が構成に追加されます。
<Setting Name="ssoengine" Type="htf:map"> <Setting Name="ErrorConfig" Type="htf:map"> <Setting Name="ErrorMode" Type="xsd:string">EXTERNAL</Setting> <Setting Name="CustomPageExtension" Type="xsd:string">html</Setting> <Setting Name="CustomPageContext" Type="xsd:string">SampleApp</Setting> </Setting> </Setting>
注意: 詳細は、Oracle Fusion Middleware WebLogic Scripting Tool Identity and Access Managementコマンド・リファレンスを参照してください。 |