| Oracle® Mobile Application Framework Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発 2.1.0 E60836-01 |
|
 前 |
 次 |
| Oracle® Mobile Application Framework Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発 2.1.0 E60836-01 |
|
前 |
次 |
この章では、MAF内のセキュリティ・フレームワークの概要と、セキュリティが適用されるようにMAFアプリケーションを構成する方法について説明します。
この章の内容は次のとおりです。
保護されているアプリケーション機能がアクティブ化されているとき、MAFによってログイン・ページがユーザーに対して表示されます。たとえば、アプリケーション機能がWebビュー内に表示されようとしているときやオペレーティング・システムがアプリケーションをフォアグラウンドに戻したときなどに、ログイン・ページがユーザーに表示されます。MAFは、アプリケーション機能が認証サーバーによって保護されている場合や、アプリケーション機能にユーザー・ロールまたは権限に基づく制約が含まれる場合に、アプリケーション機能へのアクセスで認証が必要かどうかを判断します。MAFは、ユーザーが有効な資格証明を入力した場合にのみ、目的のWebビュー、UIコンポーネントまたはアプリケーション・ページをレンダリングします。
アプリケーション機能のいずれかにこれらの条件がある場合、ユーザーはログインに成功しないとMAFアプリケーションにアクセスできないことがありますが、保護されておらず、かつアクセス関連の制約がないデフォルトのアプリケーション機能を含めることによって、保護されているアプリケーション機能と保護されていないアプリケーション機能の両方を含むMAFアプリケーションに、ユーザーがアクセスできるようにできます。この状況では、ユーザーは認証なしでMAFアプリケーションにアクセスできます。デフォルトのアプリケーション機能によって、これらの匿名ユーザーに、MAFアプリケーションへのエントランス・ポイントが提供され、これらのユーザーは保護されていないデータを表示でき、保護されたアプリケーション機能にアクセスするときには、リモート・サーバーに対して認証されます。保護されていないデフォルトのアプリケーション機能は、次のように指定できます。
デフォルトのアプリケーション機能を介して公開情報にアクセスすることを匿名ユーザーに許可するが、保護された情報には権限のあるユーザーのみがアクセスできるようにします。
保護されたアプリケーション機能にアクセスする必要がある場合にのみユーザーを認証するようにします。そうでない場合、ユーザーは匿名ユーザーとしてMAFアプリケーションにアクセスでき、保護された機能に移動するにはログインします。
保護されたアクセスが必要でない場合は保護されたアプリケーション機能からログアウトすることをユーザーに許可することで、権限のないユーザーが保護されたアプリケーション機能にアクセスすることを明示的に禁止します。
|
注意: MAFでは、アプリケーション・ログイン・プロセスがアプリケーションの初期化フローから切り離されているため、匿名ユーザーが可能となり、ユーザーは認証資格証明を提供する必要なく、匿名ユーザーとしてMAFアプリケーションを起動し、保護されていないアプリケーション機能にアクセスできます。このような場合、MAFは権限を持つUIコンポーネントを無効化することによって、ユーザーのアクションを制限します。 |
詳細は、第29.5.1項「認証を要求するようにアプリケーション機能を設定する方法」および第22.2.4項「ユーザー制約とアクセス制御について」を参照してください。
IDM Mobile SDKは、認証、暗号化、ユーザーとロールの管理、および安全な保管のためのAPIを提供します。SDKでは、Mobile and Socialサーバーによって公開されるBasic認証とREST Webサービスを介した認証がサポートされています。Mobile and Socialサーバーでは、Oracle Access Manager (OAM)サーバーに対するリライイング・パーティ認証(つまり、サードパーティのOpenIdおよびOAuthサービス・プロバイダに対する認証)による厳密認証を使用した(または使用しない)認証、およびディレクトリ・サーバーに対する厳密認証を使用した(または使用しない)認証がサポートされています。
MAFアプリケーションでは、デフォルト・ページまたはHTMLで記述されたカスタマイズ済のログイン・ページが使用されます。ログイン・ページ以外での認証が必要な場合、ナレッジベース認証(KBA)がOAMサーバー上に構成されていると、ナレッジベース認証ページを有効にできます。KBA画面では、母の旧姓などの追加情報を要求することで、追加のチャレンジがユーザーに表示されます。ログイン・ページと同様、KBA画面はカスタマイズできます。
user.rolesまたはuser.privileges制約を使用して定義されたアプリケーション機能には、特定のロールおよび権限が付与されたユーザーのみがアクセスできます。ユーザーがそのようなアプリケーション機能にログインする場合、アクセス制御サービス(ACS)と呼ばれるWebサービスが、このアプリケーション機能へのアクセスをユーザーに許可するユーザー・オブジェクトを戻します。ACSの詳細は、第29.4.19項「アクセス制御サービスに関する必知事項」を参照してください。
エンド・ユーザーの視点からは、ログイン・プロセスは次のようなものになります。
ユーザーが保護されたアプリケーション機能にアクセスしようとすると、常に、図29-1に示すログイン・ページのWebビューがMAFによって表示されます。保護されたアプリケーション機能がデフォルトである場合は、ユーザーがアプリケーションを起動すると、MAFによってログイン・ページが表示されます。
|
注意: 第29.5.4.2項「カスタム・ログイン・ページ」で説明されているとおり、MAFでは、デフォルト・ログイン・ページを表示するだけでなく、カスタム・ログイン・ページおよびオプションのカスタム・ナレッジベース認証(KBA)画面の使用もサポートされています。 |
ユーザーがユーザー名とパスワードを入力し、「OK」をクリックします。
|
注意: MAFでは、複数のユーザーが同じアプリケーションを使用できます。ユーザーは、前のユーザーのログアウト後、自由にアプリケーションにログインできます。 |
ユーザー名とパスワードが検証されると、MAFによって、目的のWebビュー、ページまたはユーザー・インタフェース・コンポーネントが表示されます。
MAFは、ユーザーが正常にログインするまで、ユーザー名とパスワードの入力を求めます。ユーザーがログインできない場合、別のアプリケーション機能に移動することのみが可能です。
ユーザー名とパスワードの認証後、追加の質問による資格証明をチャレンジするナレッジベース認証(KBA)画面がユーザーに表示される場合があります。KBAが構成されている場合、ログイン・プロセスを完了するには、ユーザーが質問に正しく答える必要があります。KBAはオプションの構成で、OAMサーバー上での適切な構成が必要となります。
|
注意: アプリケーション機能が最後にアクティブ化されて以降、事前定義された時間が経過すると、認証はタイムアウトになります。MAFでは、認証サーバーへの接続を使用するアプリケーション機能のいずれかがアクティブ化されたときのみ、アイドル・タイムアウトのタイマーの期限が更新されます。 |
MAFアプリケーションでは、リモート・ログイン・サーバー(Oracle ADF Fusion Webアプリケーションによって使用されるOracle Access Managerアイデンティティ・サーバーなど)、またはユーザーのデバイス上に存在するローカル資格証明ストアに対するユーザー資格証明の検証が必要になる場合があります。ローカルおよびリモート接続モードをサポートするため、MAFでは次の認証プロトコルがサポートされています。
HTTP Basic
Mobile-Social
OAuth
Web SSO
デフォルトでは、MAFアプリケーション・ユーザーの認証は、デザインタイムに選択された認証プロトコルに関係なく、リモート・ログイン・サーバーに対して行われます。開発者は、Oracle Access Management Mobile and Social (OAMMS)およびBasic認証の場合に、ローカル認証を有効化するようアプリケーションを構成できます。ただし、最初は、ローカル資格証明ストアに資格証明が移入されていないため、ログインして保護されたアプリケーション機能にアクセスする場合、リモート・ログイン・サーバーに対する認証が必要となります。リモート認証に成功すると、以降は(デバイス上の認証サーバーからのユーザーのログイン資格証明が格納されている)ローカル資格証明ストアを使用できるようになります。このように、ユーザーが同じアプリケーション・セッション内(つまり、アプリケーション実行のライフサイクル内)でサーバーに対して認証されると、MAFはこの認証コンテキストをローカルに格納し、以降の認証試行に使用できるようにします。この場合、ローカルの認証コンテキストで問題なくユーザーを認証できるときには、MAFはサーバーに接続しません。最初の認証では認証サーバーへの接続が必要ですが、ローカル認証を使用するアプリケーションの場合はそのサーバーに頻繁にアクセスする必要はありません。
|
ヒント: ローカル資格証明ストアに対する認証は、リモート・ログイン・サーバーに対する認証よりも高速で実行できますが、リモート接続のみをサポートするOAuthやWeb SSO認証プロトコルを使用した認証をお薦めします。 |
表29-1に、MAFアプリケーションのログイン構成オプションをまとめます。接続モードは、選択した認証プロトコルによって異なります。
表29-1 MAFの接続モードおよびサポートされている認証プロトコル
| 接続モード | サポートされているプロトコル | モードの説明 |
|---|---|---|
|
ローカル |
|
ローカルに格納されている資格証明がデバイスで使用不可能な場合にのみ、アプリケーションでリモート・ログイン・サーバーに対する認証を行う必要があります。最初のログインは、常にリモート・ログイン・サーバーに対して行われます。最初のログインが成功すると、MAFは、資格証明をデバイスの資格証明ストア内にローカルに保持します。アプリケーション機能への以降のアクセスでは、それらの資格証明が使用されます。第29.4.17項「Webサービス・セキュリティに関する必知事項」も参照してください。 |
|
リモート |
|
アプリケーションで、Oracle Access Manager (OAM)アイデンティティ・サーバーなどのリモート・ログイン・サーバーまたは保護されているWebアプリケーションに対する認証が必要です。ユーザーがログインするたびに、リモート・サーバーに対する認証が求められます。デバイスがサーバーに接続できない場合、ユーザーは、前回は正常に認証されていても、保護されたMAF機能にアクセスできません。 |
|
ハイブリッド |
|
ネットワーク接続が使用可能である場合は、デバイス上のローカル資格証明がで使用可能でも、アプリケーションでリモート・ログイン・サーバーに対する認証を行う必要があります。ネットワーク接続が切断されてログイン・サーバーにアクセスできない場合にのみ、デバイス上のローカル資格証明が使用されます。 |
例として、次のプロセスは、Mobile-Social認証プロトコルがリモート認証サーバーに対してユーザー資格証明を確認するようにMAFアプリケーションが構成されている場合に、セキュリティのフローを表しています。
MAFは、(図29-1のような)ログイン・ページ、またはナレッジベース認証画面をユーザーに表示します。
Oracle Access Management Mobile and Social (OAMMS)クライアントSDKのAPIは、認証サーバーと、デバイス上の資格証明ストア(保存済のユーザー・オブジェクトが格納されている場合があります)の両方に対する資格証明認証を処理します。認証に成功すると、APIは有効なユーザー・オブジェクトをMAFに戻します。それ以外の場合は、失敗を戻します。
|
注意: OAMMSにログインすると、ロールおよび権限コレクションがuserオブジェクトに移入されます。 |
ログインに成功すると、MAFは、Cookieで使用されるOAMトークンを受け取ります。各ログイン接続にCookieが設定されます。
OAMMSクライアントSDK APIは、デバイスのローカル資格証明キーストアに資格証明をキャッシュします。アプリケーション・セッション・タイムアウトまたはアイドル・タイムアウトのしきい値を超えると、MAFはローカル資格証明キーストアを消去します。
ログインに失敗した場合、ログイン・ページまたはKBA画面が表示されたままになり、ユーザーは先に進むことができません。
セキュリティが適用されるアプリケーション機能用に、アプリケーション・ログイン・サーバーへの接続を少なくとも1つ定義する必要があります。アプリケーション・ログイン・サーバーへの定義済の接続が存在しないと、無効な構成になります。その結果、アプリケーションは正しく機能しません。
図29-2に示すように、MAF接続の作成ダイアログを使用して接続タイプを選択し、接続タイプに応じて、ローカルおよびリモート認証の両方を有効化します(ハイブリッド)。アプリケーション要件に応じて、次の認証プロトコルをサポートするサーバーへの接続を構成できます。
HTTP Basic
Mobile-Social
OAuth
Web SSO
|
注意: OAuthまたはWeb SSO接続タイプを使用したログイン・サーバーへの接続を構成することをお薦めします。OAuthおよびWeb SSOでは、リモート・ログイン・サーバーに対する認証が必要となり、デバイス上でのローカル資格証明ストアからの認証をユーザーに許可しません。 |
ログイン・サーバー接続を作成するには:
次のアクションのいずれかを実行します。
ナビゲータで、「ディスクリプタ」ノード、「ADF META-INF」と開き、maf-application.xmlをダブルクリックします。次に、maf-application.xmlファイルの概要エディタで、「セキュリティ - 認証とアクセス制御」セクションを展開し、「作成」をクリックします(図29-3を参照)。
または、「新規ギャラリ」で「接続」を選択し、「MAFログイン・サーバー接続」を選択します。
「MAFログイン接続の作成」ダイアログで、目的の「認証サーバー・タイプ」を選択します。
次の項の説明に従って接続タイプを構成します。
ダイアログに表示される、アスタリスクが付いたオプションは必須フィールドであることに注意してください。このダイアログでは、すべての必須フィールドが入力された後にのみ「接続のテスト」ボタンが有効になります。このボタンは、Basic認証がダイアログで選択されている場合にのみ表示されます。
図29-4に示すように、「MAFログイン接続の作成」ダイアログで「HTTP基本」認証サーバー・タイプを選択して、Basic認証の接続を構成できます。
Basic認証を構成するには:
「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」で「HTTP基本」を選択します。
「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.4.1項「MAFログイン接続の構成方法」を参照してください。
「一般」タブで、次を定義します。
接続モード: 表29-1に示すように、認証のタイプを選択します。
接続名: 接続の名前を入力します。
アイドル・タイムアウト: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。
|
注意: MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を実行しますが、セッション・タイムアウト後にこの認証を実行することはありません。 |
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
ログイン最大試行回数: ローカル資格証明がクリアされるまでにユーザーに許可する最大ログイン試行失敗回数を設定します。デフォルトで、MAFは、ユーザーに3回のログイン試行の失敗を許可しており、それを超えると、ローカルに格納されているそのユーザーの資格証明をクリアし、以降のログイン試行では、リモート・ログイン・サーバーに接続します。リモート・サーバーに接続した後は、そのユーザーに許可されるログイン試行回数は無制限になります。
ユーザーがログイン試行を指定した回数失敗すると、ローカル資格証明がクリアされるため、MAFはサーバーに対して認証を実行します。これにより、ユーザーは、管理者がユーザーのパスワードを変更した後、パスワードがデバイス上にまだ格納されていない状態で、この新しいパスワードを使用してログインできるようになります。ローカル認証が許可されている場合、ユーザーがサーバー接続へのログインに成功するとパスワードはデバイス上に安全に格納されます。
|
注意: アプリケーション機能がローカル認証を使用するように構成されている場合でも、MAFは、ローカルに格納されているユーザー資格証明をクリアします。 |
図29-5に示すように、「HTTP基本」タブをクリックして、次を構成します。
マルチテナント対応: MAFでは、1つのアプリケーションに異なる組織(テナント)で共有可能な1つのホスト・アプリケーション機能が含まれ、それが特定のテナントによって所有されているように見える、マルチテナントの概念がサポートされています。このオプションを選択して、MAFアプリケーション接続にマルチテナント対応を定義できます。第29.4.21項「マルチテナント接続の定義時に行われる処理」も参照してください。
ログインURL: ログイン・ページのログインURLを入力します。
ログインURLには、リモート・サーバー上のログイン・ページではなく、HTTP基本認証のユーザー名/パスワードのチャレンジを表示する、保護されたページを指定します。ログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。
ログアウトURL: 認証サーバーのログアウトURLを入力します。
ログアウトURLはログインURLと同じ場合もあれば、セッションで追加アクション(無効化など)を実行するリモート・サーバーへのURLの場合もあります。ログアウトURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。
「自動ログイン」タブをクリックし、第29.4.8項「ログイン資格証明の格納方法」の説明に従って、パラメータを構成します。
「認可」タブをクリックし、第29.4.18項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。
「一般」タブをクリックし、「接続のテスト」をクリックします。
「OK」をクリックします。
図29-6に示すように、「MAFログイン接続の作成」ダイアログで「Mobile-Social」認証サーバー・タイプを選択して、Oracle Access Manager (OAM)サーバーで認証を行うようにMAFアプリケーションの接続を構成できます。この接続タイプのOAMバックエンドでは、Oracle Mobile and Socialサーバーおよび10g WebGate (リソースに対するHTTPリクエストを捕捉して、認証と認可のためにOAMサーバーに転送するWebサーバー・プラグイン)を実行している必要があります。
始める前に
OAMバックエンドがOracle Mobile and Socialサーバーおよび10g Webgateを実行していることを確認します。
OM_PROP_OAMMS_URLプロパティ・キーを使用するようにサーバーを構成します。このURL (プロトコル、ホスト名およびポート番号を含む)は、Mobile and Socialサーバーにアクセスするために必要です。HTTPおよびHTTPSプロトコルのみがサポートされています。OAM_ID CookieをWebサーバー・リクエスト・ヘッダーに挿入するようにサーバーを構成する必要もあります。
Oracle Mobile and Socialサーバーを介したOracle Access Managementでの認証を構成するには:
「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」で「Mobile-Social」を選択します。
「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.4.1項「MAFログイン接続の構成方法」を参照してください。
「一般」タブで、次を定義します。
接続モード: 表29-1に示すように、認証のタイプを選択します。
接続名: 接続の名前を入力します。
アイドル・タイムアウト: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。
|
注意: MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を実行しますが、セッション・タイムアウト後にこの認証を実行することはありません。 |
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
ログイン最大試行回数: ローカル資格証明がクリアされるまでにユーザーに許可する最大ログイン試行失敗回数を設定します。デフォルトで、MAFは、ユーザーに3回のログイン試行の失敗を許可しており、それを超えると、ローカルに格納されているそのユーザーの資格証明をクリアし、以降のログイン試行では、リモート・ログイン・サーバーに接続します。リモート・サーバーに接続した後は、そのユーザーに許可されるログイン試行回数は無制限になります。
ユーザーがログイン試行を指定した回数失敗すると、ローカル資格証明がクリアされるため、MAFはサーバーに対して認証を実行します。これにより、ユーザーは、管理者がユーザーのパスワードを変更した後、パスワードがデバイス上にまだ格納されていない状態で、この新しいパスワードを使用してログインできるようになります。ローカル認証が許可されている場合、ユーザーがサーバー接続へのログインに成功するとパスワードはデバイス上に安全に格納されます。
|
注意: アプリケーション機能がローカル認証を使用するように構成されている場合でも、MAFは、ローカルに格納されているユーザー資格証明をクリアします。 |
「Mobile-Social」タブをクリックし、Oracle Access Management Mobile and SocialサーバーへのURLを入力し、MAFアプリケーション・サービス・ドメインを入力します。
また、図29-7に示すように、デバイスでの位置の更新をサーバーで有効化するように接続を構成することもできます。
「自動ログイン」タブをクリックし、第29.4.8項「ログイン資格証明の格納方法」の説明に従って、パラメータを構成します。
「認可」タブをクリックし、第29.4.18項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。
図29-8に示すように、「MAFログイン接続の作成」ダイアログを使用して、サードパーティ・アプリケーション(クライアント)がリモート・サーバーに格納されている保護されたデータまたはサービスへの制限付きアクセスを取得する方法を構成できます。Oracle Mobile and Socialサーバーが提供するリライイング・パーティ認証では、アプリケーションがサードパーティOAuthプロバイダに対する認証を実行できます。Oracle Web Services Manager (OWSM) Lite MobileのADFアプリケーション・エージェントは、Webサービス・コールのセキュリティ・ヘッダーにCookieを挿入します。
始める前に
OM_PROP_OAUTH_OAUTH20_SERVERプロパティ・キーを使用するようにサーバーを構成します。
OAuthサーバーでの認証を構成するには:
「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」で「OAuth」を選択します。
「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.4.1項「MAFログイン接続の構成方法」を参照してください。
「一般」タブで、次を構成します。
接続名: 接続の名前を入力します。
「OAuth」タブをクリックし、図29-9に示すように、次を構成します。
「権限タイプ」を選択し、アプリケーションがログイン・ページを取得する場所を決定します。サーバー・ログイン・ページを表示する場合は、「認可コード」を選択します。MAFアプリケーションでデフォルト・ログイン・ページまたはカスタム・ログイン・ページ(構成されている場合)を表示する場合は、「リソース所有者の資格証明」を選択します。
「クライアント識別子」を入力し、オプションで、「クライアント・シークレット」フィールドに接続パスワード値を入力します。
認可サーバーの「リダイレクト・エンドポイント」およびそのエンドポイントのURIを認可サーバー・エンドポイント自体および「トークン・エンドポイント」に入力します。
ユーザーのログアウト時にリダイレクトされる「ログアウトURL」を入力します。このフィールドは必須入力で、URLパラメータは特定の認証プロバイダによって決まります。
アプリケーション内の組込みブラウザにログイン・ページを表示する場合は、「埋込みブラウザ・モードの有効化」を選択します。外部ブラウザにログイン・ページを表示する場合は選択を解除します。シングル・サインオン(SSO)が必要となる場合は、このオプションを選択解除して、アプリケーションによって外部ブラウザが使用されるようにします。
「認可」タブをクリックし、第29.4.18項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。
図29-10に示すように、「MAFログイン接続の作成」ダイアログを使用して、クロスドメイン・シングル・サインオンを構成できます。
Web SSOサーバーでの認証を構成するには:
「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」で「Web SSO」を選択します。
「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.4.1項「MAFログイン接続の構成方法」を参照してください。
「一般」タブで、次を構成します。
接続名: 接続の名前を入力します。
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
「Web SSO」タブをクリックし、図29-11に示すように、成功したログインおよび失敗したログインを有効化する次のURLを構成します。
ログインURL: 訪問時にユーザーに対して資格証明の入力を要求するURLを入力します。ログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。
ログアウトURL: サーバー・セッションを終了してユーザーをログアウトする、サーバー側URLを入力します。ログアウトURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。
ログイン成功URL: ユーザーが認証成功後にリダイレクトされるターゲットURLを入力します。
ログイン成功URLはログインURLと同じにできます。たとえば、ログインURLとログイン成功URLがhttp://www.mysite.comの場合、ユーザーがブラウザでhttp://www.mysite.comを指定すると、ブラウザはまずサイトのログイン・ページにリダイレクトされ、そこで認証に成功するとhttp://www.mysite.comに再びリダイレクトされます。その後、MAFでは、ログイン成功URLによって指定されたページを検出すると、ログイン・プロセスを完了してリクエストされた機能をアクティブにします。このようにして、ログイン成功URLページの内容がユーザーに表示されることなく、ユーザーはMAF機能にアクセスできるようになります。
ログイン失敗URL: ユーザーが認証失敗後にリダイレクトされるURLを入力します。失敗用のURLがない場合は、任意のURLを入力します。
ブラウザにログイン失敗URLがロードされると、MAFはまずエラーを検出してから、アプリケーションに制御を戻します。これは、MAFアプリケーションによってユーザーの最大ログイン試行回数が制限されている場合に有用です。この場合、ユーザーが許容回数の最後の試行で認証に失敗すると、MAFによってログイン失敗URLにリダイレクトされます。
失敗用のURLがない場合は、任意のURLを入力しても構いません。この場合、ユーザーがログイン・ページのキャンセル・ボタンをクリックするか、所定の期間内にユーザーアクションが行われなかったためにログインがタイム・アウトすると(非アクティブのタイムアウトは2分)、認証が終了します。
「認可」タブをクリックし、第29.4.18項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。
図29-12に示すように、「MAFログイン接続の作成」ダイアログを使用して、開発時に名前付き接続を作成し、実行時にログイン属性を移入してこの接続の定義を完成させることができます。この接続タイプは、デザインタイムに接続属性の一部がわからない場合に特に便利です。
アプリケーション開発者は、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIを使用して、第29.4.7項「実行時に名前付き接続の接続属性を更新する方法」の説明に従って、デザインタイムに作成されたプレースホルダ接続を完全に定義する必要があります。
実行時に定義するためのプレースホルダ接続を構成するには:
「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」で「実行時に値を指定」を選択します。
「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.4.1項「MAFログイン接続の構成方法」を参照してください。
「一般」タブで接続名を入力します。
アプリケーション開発者はこの識別子を使用して、第29.4.7項「実行時に名前付き接続の接続属性を更新する方法」の説明に従って、更新する接続を識別します。
「認可」タブをクリックし、第29.4.18項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。
アプリケーション開発者は、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIを使用して、プレースホルダ(図29-12に示すように「MAFログイン接続の作成」ダイアログで「実行時に値を指定」を選択した場合)、または完全に設定された接続定義のいずれかによって、すでに存在する接続の接続属性を定義または再定義できます。
|
注意: 通常のタイミングでは、アプリケーション・ライフサイクル・リスナー内のstart()メソッド実装でAdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIをコールします。このメソッドを機能ライフサイクル・リスナー内からコールしないでください。 |
configUrlParamパラメータに関連付けられた接続属性を更新するには、updatedSecurityConfigWithURLParametersメソッドを次のようにコールします。
import oracle.adfmf.framework.api.AdfmfJavaUtilities;
...
AdfmfJavaUtilities.updateSecurityConfigWithURLParameters(configUrlParam,
key, message, showConfirmation);
keyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして設定されます。このメソッドをshowConfirmationパラメータをtrueに設定して呼び出すと、MAFが既存の接続の属性に対する接続構成の変更を検出した場合にエンド・ユーザーに確認のプロンプトを表示できるようになります。
AdfmfJavaUtiltiesクラスおよびconfigUrlParamパラメータの使用の詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスを参照してください。
セキュリティが重要でない場合、MAFではユーザー資格証明を格納することがサポートされており、これを(ログイン接続で定義したモードに応じて)ログイン・サーバーに対してリプレイしたり、ユーザーのローカル認証に使用することができます。資格証明を格納すると、ユーザーはログインしないでMAFアプリケーションにアクセスできるようになるため、ユーザーの操作性が向上します。IDM Mobile SDKにより、MAFは次のモードをサポートできるようになります。
自動ログイン: MAFは、ユーザー資格証明をキャッシュし、これらを以降の認証で認証サーバーに対してリプレイします。このモードでは、ユーザーは、MAFによって資格証明の入力や確認を求められることなくアプリケーションを起動できます。ただし、MAFは新しいアプリケーション・セッションが開始されたことをユーザーに知らせることができます。
資格証明を記憶: MAFはユーザー資格証明をキャッシュし、ログイン・ページのユーザー名フィールドとパスワード・フィールドに移入します。ユーザーがログイン・ボタンをタップしてこれらの資格証明を確認すると、MAFはそれらを認証サーバーに対してリプレイします。
ユーザー名を記憶: MAFはユーザー名をキャッシュし、ログイン・ページのユーザー名フィールドに移入します。ユーザーがパスワードを入力し、ログイン・ボタンをタップして確認すると、MAFはこれらの資格証明を認証サーバーに対してリプレイします。
|
注意: ユーザーは、これらの資格証明をMAFが格納するかどうかを決定できます。 |
図29-13に示すように、「MAFログイン接続の作成」ダイアログの「自動ログイン」ページを使用して、資格証明格納オプションを選択できます。資格証明オプションを選択すると、ユーザー名とパスワードを記憶するオプションによってログイン・ページが設定されるため、デバイスを複数のエンド・ユーザーが共有する場合は選択しないでください。
MAFでは、connections.xmlファイル内のすべての接続情報が集約されます(このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」および「ADF META-INF」ノードの下にあります)。このファイル(例29-1を参照)は、アプリケーションにバンドルすることも、構成サービス用にホスティングすることもできます。後者の場合、MAFは、アプリケーションが起動されるたびに、更新済の構成情報があるかどうかをチェックします。
例29-1 connections.xmlファイル内に定義されているMAF接続
<?xml version = '1.0' encoding = 'UTF-8'?>
<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="Connection_1"
className="oracle.adf.model.connection.adfmf.LoginConnection"
adfCredentialStoreKey="Connection_1"
partial="false"
manageInOracleEnterpriseManager="true"
deployable="true"
xmlns="">
<Factory className="oracle.adf.model.connection.adfmf.LoginConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="adfmfLogin">
<Contents>
<login url="http://10.0.0.0/SecuredWebServicelogin/login"/>
<logout url="http://10.0.0.0/SecuredWebServicelogout/logout"/>
<accessControl url="http://10.0.0.0/Identity/Authorize"/>
<isAcsCalledAutomatically value="false"/>
<idleTimeout value="300"/>
<sessionTimeout value="28800"/>
<isMultiTenantAware value="true"/>
<multiTenantHeaderName value="Oracle_Multi_Tenant"/>
<injectCookiesToRESTHttpHeader value="true"/>
<userObjectFilter>
<role name="manager"/>
<privilege name="account manager"/>
<privilege name="supervisor"/>
<privilege name=""/>
</userObjectFilter>
<rememberCredentials>
<enableRememberUserName value="true"/>
<rememberUserNameDefault value="true"/>
<enableRememberPassword value="true"/>
<rememberPasswordDefault value="true"/>
<enableStayLoggedIn value="true"/>
<stayLoggedInDefault value="true"/>
</rememberCredentials>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
</References>
詳細は、Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発のconnections.xmlファイルで定義されている参照に関する項を参照してください。
保護されたMAF機能へのアクセス権を付与するためのログインURLをconnections.xmlファイルまたはプログラムを使用して定義する場合、ログインURLはmydocument.txtのようなファイル・リソースを指すことはできません。このログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースが使用されていると、MAFアプリケーションがハングするかログインに失敗して、ユーザーが保護されたMAF機能にアクセスできない場合があります。
リモート接続と同様、ローカルおよびハイブリッド・ログイン接続モードでは、ユーザーは、アプリケーション・ライフサイクル内で、任意の数のアイデンティティを使用してログインおよびログアウトできます。これらの接続モードを使用するようにログイン接続を定義すると、現在のセッションのタイムアウト期間内に、保護されているアプリケーション機能に前にログインしたユーザーは、ローカル資格証明ストアを使用して、保護されているアプリケーション機能に再びログインできます。この場合、明示的にログアウトしたユーザー、またはアイドル・タイムアウトが経過したためにログアウトしたユーザーは、保護されているアプリケーション機能(またはそのアプリケーション機能を保護しているログイン・サーバーにより保護されている他のアプリケーション機能)に再びログインできます。
|
注意: ローカルおよびハイブリッド接続は、Basic認証、およびOracle Access Management Mobile and Social (OAMMS)への認証にのみ使用できます。OAuthおよびフェデレーテッドSSOは、リモート認証を使用するため、アプリケーション・ユーザーは、認証に成功しないかぎり、再びログインすることはできません。 |
MAFアプリケーションを移行する場合、maf-feature.xmlで定義されている認証モード(<adfmf:feature id="feature1" name="feature1" credentials="remote">など)が、connections.xmlファイルのauthenticationMode属性で定義されていることを確認する必要があります。credentials属性の存在を検出するJDeveloperの監査ルールを使用すると、その属性をmaf-feature.xmlから削除するのに役立ちます。
connections.xmlファイルのauthenticationMode属性は、remoteまたはlocalとしてのみ定義できるため、none (<adfmf:feature id="feature1" name="feature1" credentials="none">)の値を移行しないでください(移行すると、デプロイメントが失敗します)。
図29-15に示されているように、「MAFログイン接続の作成」ダイアログで「RESTコールにログイン・サーバーのCookieを含める」オプションを選択すると、MAFは、ログイン・サーバーによって送信されたこのユーザー・セッションCookieを取得し、それをMAFアプリケーションから開始されたREST Webサービス・コールのHTTPヘッダーに挿入します。
MAFアプリケーションがREST Webサービスを要求するたびに、MAFのセキュリティ・フレームワークは、REST Webサービスのトランスポート・レイヤーが、REST WebサービスのURLエンド・ポイントに関連付けられているログイン接続に対してCookieの挿入が可能かどうかをチェックできるようにします。つまり、例29-1に示されているように、connections.xmlファイルに<injectCookiesToRESTHttpHeader value="true"/>が含まれている必要があります。
接続でCookieの挿入が許可されており、ログイン・サーバーとREST Webサービス・エンド・ポイントのドメインが一致している場合、セキュリティ・フレームワークによって、ユーザーがアプリケーション機能にログインしたときに格納されたCookieが取得されます。MAFは、REST Webサービス・リクエストのドメインに格納されているすべてのCookieを伝播します。MAFは、Rest Webサービス・レスポンス内のSet-CookieヘッダーごとにCookieを格納します。Set-Cookieヘッダーでは、Cookieをストアに追加するか、または名前が同じである場合は既存のCookieを新しいCookieに置き換えます。REST Webサービス・レスポンスによって戻されたCookie、および認証プロセスで戻されたCookieは、以降のREST Webサービス・リクエストに挿入されます。
|
注意: MAFは、(プラットフォーム固有のCookieストアから名前でCookieを戻す) Oracle Access Management Mobile and Social (OAMMS) APIをコールすることで、Cookie文字列を作成します。IDM Mobile SDKは、認証サーバーによって戻されたCookieを管理します。それらの名前は、connections.xmlファイルで定義されます。 |
ユーザーがMAFアプリケーションによって正常に認証されると、ログイン・サーバーは、そのユーザーのセキュリティ・コンテキストを作成し、ユーザー・セッションを追跡するCookieを生成します。図29-15に示されているように、「MAFログイン接続の作成」ダイアログで「RESTコールにログイン・サーバーのCookieを含める」オプションを選択すると、MAFは、ログイン・サーバーによって送信されたこのユーザー・セッションCookieを取得し、それをMAFアプリケーションから開始されたREST Webサービス・コールのHTTPヘッダーに挿入します。
CookieをWebサービス・コールに伝播することで、ログイン・サーバーに格納されているユーザーのセキュリティ・コンテキストを取得し、MAFアプリケーションがREST Webサービスを使用して、そのユーザーに対して認可されているアプリケーション・データにアクセスできるようになります。ユーザー・セッションCookieが期限切れになると、MAFは、ユーザーに資格証明を要求し、ユーザーを再認証します。再認証されたユーザーは、引き続き、REST Webサービス・コールを介して認可済のアプリケーション・データにアクセスできます。
ユーザーがローカルに認証されると、MAFはMAFアプリケーションがREST Webサービスをコールしたときにログイン・サーバーに対してユーザーをサイレントに認証します。ユーザーの資格証明が認証されると、MAFはREST Webサービスに対するアプリケーションのリクエストを実行します。REST Webサービスが401ステータス・コード(未許可)を戻した場合、MAFはユーザーに再度の認証を指示します。REST Webサービスが302コード(検出または一時的に移動されました)を戻した場合、MAFはログイン・サーバーをチェックして、ユーザーが認証されているかどうかを確認します。そうである場合、コードは302リダイレクトとして処理されます。
ユーザーがログイン・サーバーに対して認証されていない場合、MAFはユーザーに再度の認証を指示します。場合によっては、ログイン・サーバーが、302ステータス・コードを戻したときに、サーバー独自のWebページを使用した認証をユーザーに指示する場合があります。MAFでは、このような場合のリダイレクションをサポートしておらず、かわりにMAFログイン・ページを使用して再度ログインすることをユーザーに指示します。
サーバーがCookieを受け付けない場合、Webビューから発行されたHTTPリクエスト内に基本認証ヘッダーを挿入することによって、アプリケーション機能がセキュア・リソースにアクセスすることを可能にします。デフォルトでは、MAFはBasic認証を使用します。「HTTPリクエストに基本認証ヘッダーを含めます」オプションがデフォルトで選択されているため、Webビューから発行されたHTTPリクエスト内に基本認証ヘッダーを挿入することによって、MAFはアプリケーション機能がセキュア・リソースにアクセスすることを可能にします。
|
注意: MAFによって基本認証ヘッダーが挿入されないようにするには、<injectBasicAuthHeader>要素のvalue属性をfalseに設定します。 |
ユーザー名とパスワードの認証レルムを定義すると、connections.xmlファイルに定義した<realm>要素が移入されます。例29-2に示すように、MAFは、connections.xmlファイルにこれらの定義が含まれているかどうかに関係なく、ヘッダーを追加します。
例29-2 connections.xmlファイルを使用した、基本認証ヘッダーの挿入
<?xml version = '1.0' encoding = 'UTF-8'?>
<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="connection1"
className="oracle.adf.model.connection.adfmf.LoginConnection"
adfCredentialStoreKey="connection1"
partial="false" manageInOracleEnterpriseManager="true"
deployable="true" xmlns="">
<Factory className=
"oracle.adf.model.connection.adfmf.LoginConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="adfmfLogin">
<Contents>
<login url="http://www.us.example.com/userInfo"/>
<logout url="http://www.us.example.com/userInfo"/>
<accessControl url="http://10.0.0.0/identity/authorize"/>
<idleTimeout value="300"/>
<sessionTimeout value="28800"/>
<cookieNames/>
<realm value="Secure Area"/>
<injectBasicAuthHeader value="true"/>
<userObjectFilter/>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
</References>
Webサービス用のログイン・ページはなく、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービス・コールのヘッダーに資格証明が挿入されます。Webサービスは、ローカルに格納されている資格証明(ユーザーによる認証サーバーへの最初のログインの成功後、MAFによって保持されている資格証明)を使用してアプリケーション・データにアクセスします。ローカル資格証明ストアの名前は、ログイン・サーバー接続のadfCredentialStoreKey属性によって示されます(例29-1ではadfCredentialStoreKey="Connection_1")。Webサービスがこの資格証明ストアを使用できるようにするには、SOAPまたはREST Webサービス接続のadfCredentialStoreKey属性に対して定義されている名前が、ログイン・サーバーのadfCredentialStoreKey属性に対して定義されている名前と一致する必要があります。
|
注意: connections.xmlファイルの概要エディタはないため、「プロパティ」ウィンドウを使用して、<Reference>要素のadfcredentialStoreKey属性をログイン・サーバー接続のadfCredentialStoreKey属性用に構成されている名前で更新できます。または、「ソース」エディタを使用して属性を追加または更新できます。 |
詳細は、第15.7.3項「資格証明の挿入に関する必知事項」を参照してください。
アクセス制御サービス(ACS)は、JSONを使用したRESTful Webサービスであり、オプションでMAFアプリケーションとは別の外部サーバー上にデプロイすることができます。通常は、アプリケーション機能に保護されたコンポーネントが含まれている場合に、ユーザーが単一のHTTP POSTメッセージを介して自身のユーザー・ロールと権限をダウンロードできるよう、MAFアプリケーションにACSサービスを提供します。このサービスをアプリケーションに提供する場合は、ACSサービスを実装してホストする必要があります(MAでは、このサービスは提供されません)。図29-14は、「MAFログイン接続の作成」ダイアログの「認可」ページを示したもので、このページを使用してMAFアプリケーションのアクセス制御を構成します。
アプリケーション・ログイン・サーバーによって付与されるアクセス制御は、第22.2.4項「ユーザー制約とアクセス制御について」で説明されているとおり、そのアプリケーション機能用に構成されているuser.rolesおよびuser.privileges制約の評価に基づきます。たとえば、manager_roleロールを持つユーザーにのみアプリケーション機能へのアクセスを許可するには、maf-feature.xmlファイル内の<adfmf:constraints>要素を次のように定義する必要があります。
<adfmf:constraint property="user.roles"
operator="contains"
value="manager_role"/>
</adfmf:constraints>
アプリケーションの起動時、アプリケーション・ログイン・サーバー接続のために、アクセス制御サービス(ACS)として知られているRESTful Webサービスが呼び出され、そのユーザーに割り当てられているロールと権限がフェッチされます。その後、MAFは、アプリケーション・ログイン・サーバー接続に対してログインするようにユーザーに要求します。
MAFは、取得されたユーザー・ロールと権限に照らして各アプリケーション用に構成されている制約を評価し、関連付けられているすべての制約を満たすユーザーのみがアプリケーション機能を使用できるようにします。
アクセス制御を構成するには:
「MAFログイン接続の作成」ダイアログで、「認可」タブをクリックします。
「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.4.1項「MAFログイン接続の構成方法」を参照してください。
「認可」ページで、図29-14に示すように、認可要件を入力します。
RESTコールにログイン・サーバーのCookieを含める: リモート認証を使用するアプリケーション機能の場合、ログイン・サーバーが生成したユーザー・セッションCookieを使用してログイン・サーバーに格納されている認可済のユーザーのデータを取得するために、このオプションを選択してREST Webサービスを有効にします。詳細は、第29.4.14項「REST Webサービス・コールへのCookieの追加に関する必知事項」を参照してください。
|
注意: REST Webサービス・コールへのCookieの挿入を可能にするには、アプリケーション機能でリモート認証を使用する必要があり(MAFでは、ユーザー資格証明をローカルに格納するアプリケーション機能の場合はCookieの挿入がサポートされていません)、「ログインURL」に入力されたドメインはREST Webサービス・エンド・ポイントのドメインと同じである必要があります。 |
HTTPリクエストに基本認証ヘッダーを含めます: 接続タイプがBasic認証またはMobile-Social認証を使用して、Webビューから発行されたHTTPリクエスト内に基本認証ヘッダーをMAFが追加できるようにする場合、このオプションを選択します。Basic認証は、MAFで使用されるデフォルトのリクエスト・メソッドです。基本認証ヘッダーは、ログイン接続タイプがHTTP基本である場合にのみ挿入されます。第29.4.16項「基本認証ヘッダーの挿入に関する必知事項」も参照してください。
アクセス制御サービスURL: アクセス制御サービス(ACS)のエンド・ポイントであるURLを入力します。
|
注意: MAFは、ACSを呼び出すときに、認証サーバー(つまりログイン・サーバー)によって発行されたすべてのCookieをHTTPリクエスト・ヘッダーに挿入します。Cookieの挿入は、「RESTコールにログイン・サーバーのCookieを含める」を選択し、「アクセス制御URL」パラメータと「ログインURL」パラメータに同じドメインを入力した場合に発生します。MAFは、Cookieを挿入する前に、ACS URLとログインURLのドメインが同じであることを確認します。そうでない場合、ログイン・サーバーからのCookieがACSリクエストに挿入されないため、ACSに対する認証は失敗します。セキュアなアクセスのために、ユーザー認証を必須とし、ACS URLを保護することが理想的です。第29.4.14項「CookieをREST Webサービス・コールに追加することに関する必知事項」も参照してください。 |
ユーザー・ロールのフィルタ・リスト: アプリケーション機能によってチェックされるユーザー・ロールを入力します。セキュリティ・システムには、数千もの定義済のユーザー・ロールおよび権限が存在する可能性があるため、アプリケーション機能に固有のロールが記載されているマニフェスト(これは、アプリケーション機能の開発者によって提供されます)を使用して、このリストを作成します。
権限のフィルタ・リスト: アプリケーション機能によってチェックされる権限を入力します。
アクセス制御サービス(ACS)は、ユーザーが単一のHTTP POSTメッセージを介して自身のユーザー・ロールと権限をダウンロードできるようにする、JSONを使用したRESTful Webサービスです。これは、特定のユーザーのロールまたは権限(あるいはその両方)を戻すリクエスト・メッセージです。必要なロールと権限のリストを提供することで、特定のロールと権限を戻すこともできます。リクエスト・メッセージは、次のもので構成されています。
リクエスト・ヘッダー・フィールド: If-Match、Accept-Language、User-Agent、Authorization、Content-Type、Content Length。
リクエスト・メッセージ本文: ユーザー情報のリクエスト。
次のものが含まれている、リクエストされたJSONオブジェクト:
userId: ユーザーID。
filterMask: ユーザー・ロールと権限のいずれのフィルタを使用する必要があるのかを判断するために使用される"role"要素と"privilege"要素の組合せ。
roleFilter: ユーザー情報をフィルタ処理するために使用されるロールのリスト。
privilegeFilter: ユーザー情報をフィルタ処理するために使用される権限のリスト。
|
注意: すべてのロールを戻す必要がある場合は、filterMask配列に"role"要素を含めないでください。
すべての権限を戻す必要がある場合は、 |
例29-3は、HTTP POSTメッセージを示しています。この例では、JSONオブジェクトをペイロードとして識別し、John Smithというユーザーに割り当てられているすべてのフィルタとロールをリクエストします。
例29-3 ユーザー・ロールおよび権限のACSリクエスト
Protocol: POST
Authoization: Basic xxxxxxxxxxxx
Content-Type: application/json
{
"userId": "johnsmith",
"filterMask": ["role", "privilege"],
"roleFilter": [ "role1", "role2" ],
"privilegeFilter": ["priv1", "priv2", "priv3"]
}
レスポンスは、次のもので構成されています。
次のフィールドを持つレスポンス・ヘッダー: Last-Modified、Content-TypeおよびContent-Length。
ユーザー情報の詳細を含むレスポンス・メッセージ本文。
戻されるJSONオブジェクト。これには次のものが含まれます。
userId: ユーザーのID。
roles: ユーザー・ロールのリスト。これは、リクエスト内のroleFilter配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられているロールのリスト全体が戻されます。
privileges: ユーザーの権限のリスト。これは、リクエスト内のprivilegeFilter配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられている権限のリスト全体が戻されます。
例29-4は、戻されたJSONオブジェクトを示しています。これには、ユーザー名およびJohn Smithというユーザーに割り当てられているロールと権限が含まれています。
例29-4 戻されたJSONオブジェクト
Content-Type: application/json
{
"userId": "johnsmith",
"roles": [ "role1" ],
"privileges": ["priv1", "priv3"]
}
|
注意: Webサービスでは、ログイン・ページはありませんが、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービスのヘッダーに自動的に資格証明が追加されます。詳細は、第15.7.3項「資格証明の挿入に関する必知事項」を参照してください。 |
|
注意: ACSサービスを実装してホストする必要があります(MAFモバイルでは、このサービスは提供されません)。 |
MAFは、図29-14に示すように、http://10.0.0.0/Identity/AuthorizeなどのACSエンド・ポイントを定義するログイン接続に対する認証にユーザーが成功した後にアクセス制御サービス(ACS)を呼び出します。この動作を変更して、ログインの成功後すぐにACSが呼び出されないようにすることで、ログインとACSの起動との間にカスタム・プロセスを挿入できます。この追加ロジックは、アプリケーションの詳細に基づく、またはユーザーの職責、組織またはセキュリティ・グループに関連する、MAFによってコールされるセキュリティ・コンテキストです。
connections.xmlファイルを<isAcsCalledAutomatically value = "false"/>で更新し、AdfmfJavaUtilitiesクラスの次のメソッド(MAFアプリケーション機能がACSを必要に応じていつでも呼び出すことができるようにする)を使用して、シーケンスを変更できます。
invokeACS(String key, String OptionalExtraPayLoad, boolean appLogin)
invokeACSメソッドにより、追加のペイロードをACSリクエストに挿入できます。keyパラメータは、例29-2に示されているように、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして戻されます。appLoginパラメータをtrueに設定すると、ACSが機能アクセスを再評価できるようになります。OptionalExtraPayLoadパラメータは今後使用するために予約されており、使用されていません。
invokeACSメソッドまたはisAcsCalledAutomaticallyパラメータを使用してACSを呼び出すと、アプリケーションのロールベース制約が取得されます。
|
注意: MAFは、<isAcsCalledAutomatically value = "false"/>がconnections.xmlファイルに含まれていない場合、ログインの成功後、ACSを自動的に呼び出します。 |
保護されているアプリケーション機能がinvokeACSメソッドをコールすると、MAFは、アプリケーション・ログイン接続に関連付けられたすべてのアプリケーション機能のユーザー制約(保護されているアプリケーション機能に構成されている制約を含む)をフェッチします。保護されていないアプリケーション機能がこのメソッドをコールすると、MAFはログイン接続に関連付けられた制約のみを取得します。
|
注意: invokeACSメソッドに加え、AdfmfJavaUtilitiesクラスには次のライフサイクル・メソッドが含まれます。
詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスを参照してください。 |
「MAFログイン接続の作成」ダイアログへの入力が完了すると、MAFはtrueに設定された<isMultiTenantAware>要素をconnections.xmlファイルに移入します。マルチテナント接続では、ユーザー名はテナント名とユーザー名の組合せです。
ログイン・ページでは、JavaScriptユーティリティを使用して、接続がマルチテナント対応であるかどうかを識別します。ログイン・ページでそのような接続が検出されると、「MAFログイン接続の作成」で構成したテナント名をユーザーが入力する必要がある追加フィールドが表示されます。(正しいテナントIDの入力を含む)ログインに成功すると、MAFはテナントIDをローカル資格認証ストアに格納します。
maf-feature.xmlとmaf-application.xmlファイルの概要エディタ、および「MAFログイン接続の作成」ダイアログを使用して、セキュリティを構成します。概要エディタを使用すると、認証を必要とするアプリケーション機能をユーザーが選択したときにMAFによって表示されるログイン・ページのタイプ(デフォルトまたはカスタム)を指定したり、ユーザー・ロールまたはユーザー権限ベースの制約を含めることができます。また、セキュリティが必要な埋込みアプリケーション機能を選択することもできます。
セキュリティが適用されるように各アプリケーション機能を定義できます。残りのセキュリティ構成は、maf-application.xmlの概要エディタの「セキュリティ」ページを使用して実行します。アプリケーション機能のコンテンツがリモートURLから提供される場合に、この概要エディタを使用すると、リモートURLのコンテンツをMAFのWebビューに表示できるように、ドメインをホワイトリストできます。詳細は、第20章「リモートURLを使用したアプリケーション機能コンテンツの実装」を参照してください。
図29-15に示されているmaf-feature.xml概要エディタでは、セキュリティを適用するアプリケーション機能を指定できます。
始める前に
機能のセキュリティを有効にすると、アプリケーションでは、ユーザーを認証するためにネットワークにアクセスする必要があります。ネットワーク・ソケットへのアプリケーション・アクセス権の付与の詳細は、第9.2項「MAFアプリケーションでのコア・プラグインの有効化」を参照してください。
アプリケーション機能に対するユーザー・アクセスを指定するには:
ナビゲータのユーザー・インタフェース・プロジェクトで、「アプリケーション・ソース」および「META-INF」フォルダ・ノードを開いてから、maf-feature.xmlをダブルクリックします。
maf-feature.xmlファイルの概要エディタで、「機能」表にリストされているアプリケーション機能を選択するか、または「追加」をクリックしてアプリケーション機能を追加します。
ログインが必要なすべてのアプリケーション機能に「セキュリティ有効化」を選択します。
|
ヒント: このオプションをデフォルト・アプリケーションに適用しない場合、ユーザーは匿名でログインできます(つまり、ログイン資格証明を提示する必要がありません)。ユーザーは、保護されていないデータや機能にアクセスでき、必要に応じてログインできます(認証されたユーザーは保護されたデータと保護されていないデータの両方にアクセスできます)。MAFアプリケーション内に保護されていないアプリケーション機能を提供すると、ユーザーは保護されているアプリケーション機能からログアウトするが、アプリケーション自体に残って、保護されていないアプリケーション機能とデータの両方に引き続きアクセスできます。 |
アプリケーション機能のセキュリティを指定したら、図29-16に示されているmaf-application.xml概要エディタの「セキュリティ」ページを使用して、セキュリティが適用される各アプリケーション機能に対して、ログイン・ページの構成およびログイン・サーバーへの接続の作成と割当てを行います。このページにリストされているすべてのアプリケーション機能は、maf-feature.xmlファイルで、セキュリティが必要なものとして指定されています。
通常、アプリケーション機能のグループは、同じログイン・サーバー接続で保護され、ユーザーは、MAFから再度ログインを求められることなく、これらのアプリケーションをどれでも開くことが可能です。ただし、場合によっては、あるアプリケーション機能のセットを保護しているログイン・サーバーと、別のアプリケーション機能のセットを保護しているログイン・サーバーが異なるため、アプリケーション機能で要求される資格証明がそれぞれ異なる可能性があります。このような状況に対応するために、MAFアプリケーション用のログイン・サーバーへの接続をいくつも定義できます。maf-application.xmlファイルでは、機能参照に関連付けられている認証サーバー接続は、次のようにloginConnRefId属性を使用して指定されます。
<adfmf:featureReference refId="feature1" loginConnRefId="BasicAuthentication"/> <adfmf:featureReference refId="feature2" loginConnRefId="OAMMS"/>
MAFアプリケーションは、HTTPまたはHTTPS経由のBasic認証をサポートしている標準のログイン・サーバーなら、どのログイン・サーバーに対しても認証を受けることが可能です。MAFはまた、Oracle Identity Managementに対する認証もサポートしています。特定のアプリケーション機能用のカスタム・ログイン・ページを選択することもできます。詳細は、第29.5.4項「ログイン・ページに関する必知事項」を参照してください。
|
注意: デフォルトでは、保護されているすべてのアプリケーション機能が同じ接続を共有します。この接続は、図29-16に示されているように、<application login server>と表示されます。「機能参照」の「プロパティ」ウィンドウには、このデフォルト・オプションが「ログイン・サーバー接続」ドロップダウン・メニューに<default> (application login server)と表示されます。「MAFログイン接続の作成」ダイアログを使用して、MAFアプリケーション用に定義されている他の接続を選択できます。 |
始める前に
MAFアプリケーションでカスタム・ログイン・ページを使用する場合は、アプリケーション・コントローラ・プロジェクトのpublic_htmlディレクトリ(JDeveloper\mywork\Application\ApplicationController\public_html)にファイルを追加して、図29-17に示されているように「アプリケーション・ナビゲータ」の「Webコンテンツ」ノードからそれを使用できるようにします。第29.5.3項「カスタム・ログインHTMLページまたはカスタムKBAページの作成方法」および第5.4項「外部リソースの選択に関する必知事項」も参照してください。
第22.2.4項「ユーザー制約とアクセス制御について」の説明に従って、ユーザー権限とロール用の制約を追加します。
アクセス制御サービス(ACS)・サーバーをプロビジョニングします。詳細は、第29.4.19項「アクセス制御サービスに関する必知事項」を参照してください。
ログイン・ページおよびKBAページを指定するには:
ナビゲータで、「アプリケーション・リソース」パネルを開き、「ディスクリプタ」および「ADF META-INF」フォルダ・ノードを開いて、maf-application.xmlをダブルクリックします。
maf-application.xmlファイルの概要エディタで、「セキュリティ」ナビゲーション・タブをクリックします。
「セキュリティ」ページで、ログイン・ページのタイプを指定します。
ユーザー名とパスワードを受け入れるビューの「ログイン・ページ」を選択します。
資格証明に対するチャレンジをユーザーに表示し、ユーザーの答えを受け入れるナレッジベース認証(KBA)ビューの場合は、「KBAページ」を選択します。ナレッジベース認証はOAAMサーバー上に構成でき、別のページで、母の旧姓などの追加の質問に対する入力をユーザーに求めることができます。この機能は、Mobile-Social認証タイプでのみ使用できます。
次のように、選択したログイン・ページ、およびオプションで選択したKBAページのコンテンツ(またはユーザー・インタフェース)を選択します。
デフォルト: 選択されたすべての埋込みアプリケーション機能で使用されるデフォルト・ログイン・ページまたはKBA画面。詳細は、第29.5.4.1項「デフォルト・ログイン・ページ」を参照してください。デフォルト・ログイン・ページおよびデフォルトKBAページは、MAFによって提供されているものです。
カスタム: 「参照」をクリックして、アプリケーション・コントローラ・プロジェクト内のファイルのパスの場所を検索します。または、「新規」をクリックして、ログイン・ページまたはKBAページ用のカスタムHTMLページをアプリケーション・コントローラ・プロジェクト内に作成します。詳細は、第29.5.4.2項「カスタム・ログイン・ページ」および第29.5.3項「カスタム・ログインHTMLページまたはカスタムKBAページの作成方法」を参照してください。
|
ヒント: 「参照」機能を使用してログイン・ページの場所を検索するのではなく、「アプリケーション・ナビゲータ」からログイン・ページをフィールドにドラッグできます。 |
ログイン・ページ以外での認証が必要な場合、ナレッジベース認証(KBA)がOAMサーバー上に構成されていると、ナレッジベース認証ページを有効にできます。KBA画面では、母の旧姓などの追加情報を要求することで、追加のチャレンジがユーザーに表示されます。ログイン・ページと同様、KBA画面はカスタマイズできます。
MAFのデプロイメントによってwwwディレクトリ内に生成されるアーティファクトであるデフォルトのログイン・ページ(adf.login.htmlまたはadf.kba.html)を変更すると、カスタム・ログイン・ページを作成できます。
始める前に
wwwディレクトリ内のログイン・ページにアクセスするには、MAFアプリケーションをデプロイした後、deployディレクトリに移動します。iOSデプロイメントの場合、ページは次の場所にあります。
application workspace directory/deploy/deployment profile name/temporary_xcode_project/www/adf.login.html
および
application workspace directory/deploy/deployment profile name/temporary_xcode_project/www/adf.kba.html
Androidデプロイメントの場合、ページは、次の場所にあるAndroidアプリケーション・パッケージ(.apk)ファイル内に配置されます。
application workspace directory/application name/deploy/deployment profile name/deployment profile name.apk/assets/www/adf.login.html
および
application workspace directory/application name/deploy/deployment profile name/deployment profile name.apk/assets/www/adf.kba.html
カスタム・ログイン・ページを作成するには:
デフォルト・ログイン・ページを、ユーザー・インタフェース・プロジェクトのpublic_htmlディレクトリ内の場所(JDeveloper\mywork\application name\ApplicationController\public_htmlなど)にコピーします。
ログイン・ページの名前を変更します。
ページを更新します。
maf-application.xmlファイルの概要エディタの「セキュリティ」ページで、「カスタム」を選択し、「参照」をクリックしてログイン・ページの場所を検索します。
アプリケーション機能の認証プロセスのエントリ・ポイントは、activateライフサイクル・イベントです(第11章「MAFアプリケーションでのライフサイクル・リスナーの使用方法」を参照)。アプリケーション機能がアクティブ化されるたびに(つまり、アプリケーション機能のactivateイベント・ハンドラがコールされるたびに)、アプリケーション機能ログイン・プロセスは実行されます。このプロセスは、ログイン・ページ(デフォルトまたはカスタムのログイン・ページのいずれか)に移動し、そこでユーザー認証が必要かどうかを判断します。ただし、プロセスがログイン・ページに移動する前に、本来意図されていたアプリケーション機能をMAFに登録する必要があります。認証が成功すると、ログイン・ページは、MAFから本来意図されていた宛先を取得し、そこに移動します。
MAFによって提供されるデフォルトのログイン・ページ(図29-1を参照)は、ログイン・ボタンと、ユーザー名とパスワード用の入力テキスト・フィールド、マルチテナント名、およびエラー・メッセージ・セクションから構成されます。これは、HTMLで記述されたクロス・プラットフォーム・ページです。
maf-application.xmlファイルの概要エディタを使用して、選択したアプリケーション機能用のカスタム・ログイン・ページを追加すると、JDeveloperは、例29-5に示されているように、<adfmf:login>要素を追加し、その子要素<adfmf:LocalHTML>を設定します。すべての<adfmf:LocalHTML>要素と同様に、そのurl属性は、public_htmlディレクトリ内の場所を参照します。ユーザー認証メカニズムとナビゲーション・コントロールは、デフォルトのログイン・ページと同じものになります。
例29-5 ログイン要素
<adfmf:login defaultConnRefId="Connection_1">
<adfmf:localHTML url="newlogin.html"/>
</adfmf:login>
カスタム・ログイン・ページはHTMLで記述されています。ログイン・ページとナレッジベース(KBA)・ページの両方のフィールドには、具体的に定義された<input>要素および<label>要素を含める必要があります。
|
ヒント: カスタム・ログイン・ページを作成するためのガイドとしてMAFアプリケーションのデプロイ時に生成されたデフォルトのログイン・ページを使用します。wwwディレクトリ内のログイン・ページにアクセスするには、MAFアプリケーションをデプロイした後、deployディレクトリに移動します(第29.5.3項「カスタム・ログインHTMLページまたはカスタムKBAページの作成方法」を参照)。 |
例29-6は、デフォルト・ログイン・ページに必要な<input>および<label>要素を示しています。
例29-6 デフォルト・ログイン・ページの必須要素
<input type="text"
autocorrect="off"
autocapitalize="none"
name="oracle_access_user_id"
id="oracle_access_user_id" value="">
</input>
<input type="text"
autocorrect="off"'
autocapitalize="none"
name="oracle_access_iddomain_id"
id="oracle_access_iddomain_id" value="">
</input>
<input type="password"
name="oracle_access_pwd_id"
id="oracle_access_pwd_id" value="">
</input>
<input type="checkbox"
class="message-text"
name="oracle_access_auto_login_id"
id="oracle_access_auto_login_id">
</input>Keep me logged in
<input type="checkbox"
class="message-text"
name="oracle_access_remember_username_id"
id="oracle_access_remember_username_id">
</input>Remember my username
<input type="checkbox"
class="message-text"
name="oracle_access_remember_credentials_id"
id="oracle_access_remember_credentials_id">
</input>Remember my password
<label id="oracle_access_error_id"
class="error-text">
</label>
<input class="commandButton"
type="button"
onclick="oracle_access_sendParams(this.id)"
value="Login" id="oracle_access_submit_id"/>
例29-7は、KBAログイン・ページの必須要素を示しています。
例29-7 KBAログイン・ページの必須要素
<input type="text"
<label id="oracle_access_kba_ques_id" >Question</label><br>
<input class="field-value"
name="oracle_access_kba_ans_id"
id="oracle_access_kba_ans_id">
</input>
<label id="oracle_access_error_id"
class="error-text">
</label>
<label id="message_id"
class="message-text">
</label>
<input type="button"
onclick="oracle_access_sendParams(this.id)"
value="Login"
id="oracle_access_submit_id"/>
各HTMLログイン・ページに、表29-2にリストされたユーザー・インタフェース要素が含まれている必要があります。
表29-2 ログイン・ページのフィールドおよび関連するID
| ページ要素 | ID |
|---|---|
|
ユーザー名フィールド |
|
|
パスワード・フィールド |
|
|
ログイン・ボタン |
|
|
取消ボタン |
|
|
アイデンティティ・ドメイン/テナント名フィールド |
|
|
KBA質問フィールド(読取り専用/ラベル) |
|
|
KBA回答フィールド |
|
|
エラー・フィールド |
|
|
自動ログイン・チェックボックス |
|
|
資格証明を記憶チェックボックス |
|
|
ユーザー名を記憶チェックボックス |
|
表29-3には、OnClickイベントで使用される、推奨のJavaScriptコードがリストされています。
セキュリティが適用されるようにアプリケーション機能が指定されると、JDeveloperは、図29-16に示されているように、対応する機能参照で「セキュリティが有効な機能」の表を更新します。参照される各アプリケーション機能が、connections.xmlファイル内に定義されている同じログイン・サーバー接続に対して認証を行うと、JDeveloperは、defaultConnRefId属性を使用して定義されている単一の<adfmf:login>要素(<adfmf:login defaultConnRefId="Connection_1">など)でmaf-application.xmlファイルを更新します。
connections.xmlファイル内に定義されている別のログイン・サーバー接続を使用するように構成されているアプリケーション機能の場合は、JDeveloperは、参照される各アプリケーション機能をloginConnReference属性(<adfmf:featureReference refId="feature2" loginConnRefId="Connection2"/)で更新します。詳細は、第29.5.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照してください。また、Oracle Fusion Middleware Oracle Mobile Application Frameworkのタグ・リファレンスも参照してください。
デバイス機能へのアクセスは、MAFアプリケーションに組み込まれているCordovaプラグインによって定義されます。コア・プラグインのセットはMAFによって提供されます。これらのプラグインの1つを有効にすると、そのプラグインに必要なすべてのデバイス・アクセス権限が有効になります。MAFアプリケーションに組み込まれている他のCordovaプラグインも、必要なデバイス・アクセス権限を有効にします。
MAFアプリケーションの大多数ではネットワーク・アクセスが必要なため、ネットワークにアクセスする権限はデフォルトで有効になっています(デフォルトで有効になっている唯一のデバイス機能)。
ネットワーク情報: アプリケーションによるネットワーク・ソケットのオープンを許可します。少なくとも1つのデバイス機能のセキュリティが有効な場合、ネットワーク・アクセス機能は有効にしておく必要があります。
デバイス機能の有効化または制限が可能なため、デプロイメント・フレームワークによって更新されるプラットフォーム固有の様々な構成ファイルやマニフェスト・ファイルでは、使用中のデバイス機能(または、MAFアプリケーションに使用が登録されているプラグイン)のみがリストされます。これらのファイルにより、MAFはこれらの機能の使用に関する情報を他のアプリケーションと共有できます。たとえば、AppStoreやGoogle Playに対して、MAFアプリケーションで場所ベースの機能が(搭載されていても)使用されていないことを通知できます。
MAFアプリケーションのCordovaプラグインの詳細は、第9章「MAFアプリケーションでのプラグインの使用方法」を参照してください。
MAFでは、保護された内容が含まれるか、制約により制限されているアプリケーション機能からユーザーがログアウトした場合、アプリケーション機能は終了されず、ユーザーはアプリケーション内に残り、匿名ユーザーとして保護されていない内容や機能にアクセスできます。MAFでは制約を再度初期化できるため、ユーザーは同じアイデンティティを使用してアプリケーションに繰り返しログインできます。また、ユーザーが異なるアイデンティティを使用してログインできることにより、複数のアイデンティティでアプリケーションへのアクセスを共有することもできます。
Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスで説明しているAdfmfJavaUtilitiesクラスのlogoutFeatureおよびlogoutメソッドにより、ユーザーはアプリケーションの起動後、認証サーバーに対する明示的なログインおよびログアウトを実行できます。また、これらにより、ユーザーは保護されたアプリケーション機能を呼び出した後に認証サーバーにログインできます。ユーザーは個々のアプリケーション機能からログアウトできますが、同じ接続によって保護されているアプリケーション機能からも同時にログアウトすることになります。
これらのメソッドを使用して、ユーザーは次のことを実行できます。
アプリケーション機能からログアウトするが、保護されていない内容には引き続きアクセスします(つまり、MAFはアプリケーションを終了しません)。
アプリケーション内で、保護されている内容やUIコンポーネントを使用するためにログイン・サーバーで認証します。
MAFアプリケーションまたはアプリケーション機能からログアウトし、別のアイデンティティを使用して再びログインします。
MAFアプリケーションまたはアプリケーション機能からログアウトし、ロールと権限が更新された同じアイデンティティを使用して再びログインします。
現在の認証サーバーからのログアウトを有効にするには、次のようにAdfmfJavaUtilitiesクラスのlogoutメソッドをコールします。次に例を示します。
import oracle.adfmf.framework.api.AdfmfJavaUtilities; ... AdfmfJavaUtilities.logout();
keyパラメータに関連付けられた認証サーバーからのログアウトを有効にするには、次のようにlogoutFeatureメソッドをコールします。
import oracle.adfmf.framework.api.AdfmfJavaUtilities; ... AdfmfJavaUtilities.logoutFeature(adfCrendentialStorykey);
adfCredentialStorykeyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして戻されます。AdfmfJavaUtiltiesクラスおよびkeyパラメータの使用方法の詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスを参照してください。
MAFは、cacerts証明書ファイル(クライアント・アプリケーションとサーバー間のHTTPSハンドシェイクのJavaメカニズム)を提供します。JDeveloperは、アプリケーション・リソースのSecurityフォルダ内にこのファイルを作成します(JDeveloper\mywork\application name\resources\Security\cacertsにあります)。MAFのcacertsファイルにより、信頼できる既知のソースからの一連の証明書がJVMに対して識別され、デプロイメントが可能になります。カスタム証明書を必要とするアプリケーションでは(RSA暗号化が使用されていない場合など)、アプリケーションをデプロイする前にプライベート証明書を追加する必要があります。
始める前に
cacertsファイルの内容を理解しておくと役立ちます。詳細は、『Oracle Mobile Application Frameworkのインストール』のMAFの新しいSSL用cacertsファイルへの移行に関する項を参照してください。
JDeveloperによるcacertsファイルの作成方法についても理解しておくと役立ちます。詳細は、第C.2項「アプリケーション・コントローラ・プロジェクト・レベルのリソースについて」を参照してください。
cacertsファイルおよびkeytoolユーティリティの使用方法については、Java SEテクニカル・ドキュメント(http://download.oracle.com/javase/index.html)を参照してください。
プライベート証明書を追加するには:
プライベート証明書を作成します。たとえば、new_certという証明書ファイルを作成します。
次のようにして、プライベート証明書をアプリケーションに追加します。
シードされたcacertsファイル(cp cacerts cacerts.org)のコピーを作成します。
Java SE keytoolユーティリティを使用して、cacertsファイルに証明書を追加します。例29-8は、new_certというcacertsファイルへの証明書の追加を示しています。
例29-8 keytoolユーティリティを使用した証明書の追加
keytool -importcert
-keystore cacerts
-file new_cert
-storepass changeit
-noprompt
例29-8は、単一の証明書の追加方法を示しています。各証明書に対して同じ手順を繰り返します。表29-4には、keytoolのオプションがリストされています。
新しいcacertsファイルの内容を目で見て調べて、すべてのフィールドが正しいことを確認します。次のコマンドを使用します。
keytool -list -v -keystore cacerts | more
証明書が指定のホスト名に対するものであることを確認します。
|
注意: 証明書の共通名(CN)は、ホスト名と正確に一致している必要があります。 |
JVMが読み取れるようにするために、カスタマイズされた証明書ファイルはSecurityディレクトリ(JDeveloper\mywork\application name\resources\Security)に確実に配置してください。
アプリケーションをデプロイします。
|
注意: デプロイメント時、証明書ファイルがSecurityディレクトリに存在している場合、MAFは、それをAndroidまたはXcodeテンプレート・プロジェクトにコピーし、cacertsファイルのデフォルト・コピーを置き換えます。 |
保護されているリソースにSSL経由でアクセスできることを確認します。
