| Oracle® Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.0 E56275-01 |
|
 前 |
 次 |
| Oracle® Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.0 E56275-01 |
|
前 |
次 |
この章では、Oracle Mobile Application Framework内のセキュリティ・フレームワークの概要およびセキュリティが適用されるようにモバイル・アプリケーションを構成する方法について説明します。
この章には次の項が含まれます:
MAFは、保護されているアプリケーション機能がアクティブ化されたときに、ユーザーにログイン・ページを表示します。たとえば、アプリケーション機能がWebビュー内に表示されようとしているときやオペレーティング・システムがアプリケーションをフォアグラウンドに戻したときに、ユーザーにログイン・ページを表示します。MAFは、アプリケーション機能が認証サーバーによって保護されているときや、アプリケーション機能にユーザー・ロールまたはユーザー権限に基づいた制約が含まれているときに、アプリケーション機能へのアクセスにユーザー認証を必要とするかどうかを決定します。MAFは、ユーザーが有効な資格証明を入力した場合のみ、目的のWebビュー、UIコンポーネントまたはアプリケーション・ページをレンダリングします。
いずれかのアプリケーション機能にこれらの条件を設定すると、ユーザーがログインに成功しないとモバイル・アプリケーションにアクセスできないようにできる一方、保護されておらず、またアクセスに関連する制約も含んでいないデフォルトのアプリケーション機能を含めることで、保護されているアプリケーション機能と保護されていないアプリケーション機能の両方を含むモバイル・アプリケーションに、ユーザーがアクセスできるようにすることもできます。この状況では、ユーザーは認証せずにMAFアプリケーションにアクセスできます。デフォルトのアプリケーション機能は、保護されていないデータを表示することも、保護されているアプリケーション機能にアクセスする際にリモート・サーバーに対して認証することもできるこのような匿名ユーザーに対して、モバイル・アプリケーションの入口として機能します。次の方法により、保護されていないデフォルトのアプリケーション機能を指定できます。
デフォルトのアプリケーション機能を通じて公共の情報にアクセスすることを匿名ユーザーに許可する一方、認可されたユーザーのみが保護された情報にアクセスできるようにする。
ユーザーが、保護されているアプリケーション機能にアクセスする必要がある場合にのみ、ユーザーに認証を許可する。これ以外の場合、ユーザーは匿名ユーザーとしてモバイル・アプリケーションにアクセスするか、ログインして保護されている機能に移動できます。
アクセスを保護する必要がない場合に、保護されているアプリケーション機能からログアウトすることをユーザーに許可し、それにより権限のないユーザーが保護されているアプリケーション機能にアクセスすることを明示的に禁止する。
|
注意: アプリケーション・ログイン・プロセスはアプリケーションの初期化フローから切り離されるため、MAFは匿名ユーザーを有効化し、ユーザーは、認証資格証明を入力しなくても、匿名ユーザーとしてモバイル・アプリケーションを起動し、保護されていないアプリケーション機能にアクセスできます。このような場合、MAFは、権限が必要なUIコンポーネントを無効化して、ユーザーの操作を制限します。 |
詳細は、第21.5.1項「認証を要求するようにアプリケーション機能を設定する方法」および第15.2.4項「ユーザー制約とアクセス制御について」を参照してください。
IDM Mobile SDKは、認証、暗号化、ユーザーとロール管理およびセキュアな保存のためのAPIを提供します。SDKは、Mobile and Socialサーバーが公開するBasic認証およびREST Webサービスを使用した認証をサポートしています。Mobile and Socialサーバーは、リライイング・パーティ認証(つまりサード・パーティのOpenIdおよびOAuthサービス・プロバイダに対する認証)を使用した厳密な認証機能を持つ(または持たない)Oracle Access Manager (OAM)サーバーに対する認証および厳密な認証機能を持つ(または持たない)ディレクトリ・サーバーに対する認証をサポートしています。
モバイル・アプリケーションでは、デフォルト・ページまたはHTMLで記述されたカスタマイズ済のログイン・ページのいずれかが使用されます。ナレッジベース認証がOAMMサーバーで構成されている場合、ログイン・ページの認証で、ナレッジベース認証ページを有効化できます。「ナレッジベース認証」画面には、ユーザーに対して、「母親の旧姓」などの追加情報を求める追加のチャレンジが表示されます。「ナレッジベース認証」画面は、ログイン・ページと同様にカスタマイズできます。
特定のロールおよび権限を付与されたユーザーのみが、user.rolesまたはuser.privileges制約で定義されるアプリケーション機能にアクセスできます。ユーザーがこのようなアプリケーション機能にログインすると、アクセス制御サービス(ACS)として知られるWebサービスは、アプリケーション機能へのアクセス権を付与するユーザー・オブジェクトをユーザーに返します。ACSの詳細は、第21.4.16項「アクセス制御サービスに関する必知事項」を参照してください。
エンド・ユーザーの視点からは、ログイン・プロセスは次のようなものになります。
ユーザーが保護されているアプリケーション機能にアクセスしようとすると、MAFは、図21-1に示すとおり、ログイン・ページのWebビューを表示します。保護されているアプリケーション機能がデフォルトである場合、ユーザーがモバイル・アプリケーションを起動すると、MAFによってユーザーにログイン・ページが表示されます。
|
注意: 第21.5.3.2項「カスタム・ログイン・ページ」で説明されているとおり、MAFでは、ログイン・ページが表示されるだけでなく、カスタム・ログイン・ページの使用もサポートし、またオプションでカスタム・ナレッジベース認証画面も表示されます。 |
ユーザーがユーザー名とパスワードを入力し、「OK」をクリックします。
|
注意: MAFでは、同じアプリケーションに対して複数のユーザーを許可します。ユーザーは、前のユーザーがログアウトした後、アプリケーションに自由にログインできます。 |
ユーザー名とパスワードが検証されると、MAFによって、目的のWebビュー、ページまたはユーザー・インタフェース・コンポーネントが表示されます。
MAFは、ユーザーが正常にログインするまで、ユーザー名とパスワードの入力を求めます。ユーザーがログインできない場合、別のアプリケーション機能に移動することのみが可能です。
ユーザー名およびパスワードを認証すると、ユーザーに資格証明と追加の質問にチャレンジするナレッジベース認証画面が表示される場合があります。ナレッジベース認証が構成されている場合、ユーザーは質問に正しく回答して、ログイン・プロセスを完了する必要があります。ナレッジベース認証はオプションの構成で、OAMMサーバーで適切に構成する必要があります。
|
注意: アプリケーション機能が最後にアクティブ化されて以降、事前定義された時間が経過すると、認証はタイムアウトになります。MAFでは、認証サーバーへの接続を使用するアプリケーション機能のいずれかがアクティブ化されたときのみ、アイドル・タイムアウトのタイマーの期限が更新されます。 |
モバイル・アプリケーションでは、リモート・ログイン・サーバー(Oracle ADF Fusion Webアプリケーションが使用するOracle Access Managerアイデンティティ・サーバーなど)またはユーザーのデバイス上にあるローカル資格証明ストアに対してユーザー資格証明の検証を必要とする場合があります。ローカルおよびリモートの接続モードをサポートするために、MAFは次の認証プロトコルをサポートしています。
HTTP基本
Mobile-Social
OAuth
Web SSO
デフォルトでは、モバイル・アプリケーション・ユーザーの認証は、設計時に選択されている認証プロトコルに関係なく、リモート・ログイン・サーバーに対して行われます。Oracle Access Management Mobile and Social (OAMMS)およびローカル認証を可能にする基本認証の場合、開発者はアプリケーションを構成できます。ただし、最初はローカル資格証明ストアに資格証明が伝播されていないため、保護されているアプリケーション機能にアクセスするためのログインでは、リモート・ログイン・サーバーに対する認証が必要です。リモート認証に成功すると、その後、認証サーバーのユーザーのログイン資格証明をデバイス上に格納するローカル資格証明ストアを使用できるようになります。そのため、ユーザーが同じアプリケーション・セッション内(つまり、アプリケーション実行のライフサイクル内)でサーバーに対して認証されると、MAFは認証コンテキストをローカルに格納し、以降の認証の試行でそれを使用できるようになります。この場合、ローカルの認証コンテキストで問題なくユーザーを認証できる場合、MAFでは、ログイン・サーバーに接続されません。最初の認証では認証サーバーへの接続が必要ですが、ローカル認証を使用したアプリケーションのためにこのサーバーに頻繁にアクセスする必要はありません。
|
ヒント: ローカル資格証明ストアに対する認証は、リモート・ログイン・サーバーに対する認証よりも高速に実行できますが、リモート接続のみをサポートしているOAuthまたはWeb SSO認証プロトコルを使用した認証をお薦めします。 |
表21-1は、MAFアプリケーションのログイン構成オプションのサマリーです。接続モードは、選択した認証プロトコルによって異なります。
表21-1 MAF接続モードおよびサポートされている認証プロトコル
| 接続モード | サポートされているプロトコル | モードの説明 |
|---|---|---|
|
「ローカル」 |
|
ローカルに格納されている資格証明がデバイスで利用できない場合にのみ、アプリケーションでは、リモート・ログイン・サーバーに対する認証が必要です。初回ログインは、常にリモート・ログイン・サーバーに対して行われます。初回ログインに成功すると、MAFは、資格証明をデバイスの資格証明ストア内にローカルに保持します。アプリケーション機能への以降のアクセスでは、それらの資格証明が使用されます。第21.4.14項「Webサービス・セキュリティに関する必知事項」も参照してください。 |
|
「リモート」 |
|
アプリケーションでは、Oracle Access Manager (OAM) Identity Serverなどのリモート・ログイン・サーバーまたは保護されているWebアプリケーションでの認証が必要です。ユーザーがログインするたびに、リモート・サーバーに対する認証が求められます。デバイスがサーバーに接続できない場合、ユーザーは、前回は正常に認証されていても、アプリケーションにログインすることはできません。 |
|
「ハイブリッド」 |
|
デバイスでローカル資格証明が利用可能でも、ネットワーク接続が利用できる場合は、アプリケーションでは、リモート・ログイン・サーバーに対する認証が必要です。ネットワーク接続がないためにログイン・サーバーにアクセスできない場合にのみ、デバイスのローカル資格証明が使用されます。 |
モバイル・アプリケーションが認証サーバーに対してユーザー資格証明を検証するときのセキュリティのフローは、次のとおりです。
MAFで、ユーザーにログイン・ページ(図21-1に示したものと同様)またはナレッジベース認証画面が表示されます。
Oracle Access Management Mobile and Social (OAMMS)クライアントSDKのAPIが、保存されたユーザー・オブジェクトを格納できるデバイスの認証サーバーおよび資格証明ストアの両方に対する資格証明認証を処理します。認証が成功すると、APIはMAFに有効なユーザー・オブジェクトを返します。失敗した場合は、エラーを返します。
|
注意: OAMMSにログインすると、ロールおよび権限コレクションが |
ログインに成功すると、MAFは、Cookieで使用されるOAMトークンを受け取ります。各ログイン接続にCookieが設定されます。
OAMMSクライアントSDK APIは、デバイスの資格証明ストアに資格証明を保存します。
ログインに失敗した場合、ログイン・ページまたはナレッジ・ベース認証画面が表示されたままになり、ユーザーは先に進むことができません。
セキュリティが適用されるアプリケーション機能のアプリケーション・ログイン・サーバーに1つ以上の接続を定義する必要があります。アプリケーション・ログイン・サーバーへの定義済の接続が存在しないと、無効な構成になります。その結果、アプリケーションは正しく機能しません。
図21-2に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードを使用して接続タイプを選択できますが、接続タイプによっては、ローカルおよびリモート認証(ハイブリッド)の両方を有効化できます。アプリケーション要件によっては、次の認証プロトコルをサポートするサーバーへの接続を構成できます。
HTTP基本
Mobile-Social
OAuth
Web SSO
|
注意: OAuthまたはWeb SSO接続タイプを使用したログイン・サーバーへの接続を構成することをお薦めします。OAuthおよびWeb SSOは、リモート・ログイン・サーバーに対する認証を要求し、ユーザーがローカル資格証明ストアからデバイスで認証することを許可しません。 |
ログイン・サーバー接続を作成するには:
プロジェクト・エクスプローラで、アセンブリ・プロジェクトを展開してMAFを展開し、MAFアプリケーション・エディタをダブルクリックします。
|
注意: MAFアプリケーション・エディタを使用すると、アプリケーション・ログイン・サーバー接続を定義し、それをデフォルトのアプリケーション機能に割り当てることができます(デフォルトのアプリケーション機能が保護されている場合)。この場合、アプリケーション・ログイン・サーバーに指定されている資格証明は、アクセス制御サービス(ACS)を介してユーザー、ロールおよびサービスを検索するためにも使用されます。第21.4.16項「アクセス制御サービスに関する必知事項」も参照してください。 |
エディタで、アウトラインの「セキュリティ」を選択し、次のいずれかの隣にある「作成」をクリックします。
デフォルト・ログイン・サーバー
「ログイン・ページ」
「ナレッジベース認証ページ」
図21-2に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードで、「新規接続の作成」を選択し、認証サーバー・タイプを選択します。接続タイプについては、次の項で説明します。
図21-3に示すとおり、「モバイル・ログイン・サーバー」ウィザードで、「HTTP基本」認証サーバー・タイプを選択すると、基本認証の接続を構成できます。
基本認証を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、認証サーバー・タイプとして「HTTP基本」を選択します。「次へ」をクリックします。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第21.4.1項「MAFログイン接続の作成方法」を参照してください。
「一般オプション」ページで、次の項目を定義します。
「名前」: 接続の名前を入力します。
「認証モード」: 表21-1の説明に従って、認証のタイプを選択します。
「アイドル・タイムアウト」: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。
|
注意: MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を行いますが、セッション・タイムアウト後にこの認証を行うことはありません。 |
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
「RESTコールにログイン・サーバーを含める」: リモート認証を使用したアプリケーション機能では、このオプションを選択すると、ログイン・サーバー生成ユーザー・セッション・コードを通じてログイン・サーバーに格納される、認可されたユーザー・データを取得するためにREST Webサービスを有効化できます。詳細は、第21.4.11項「CookieをREST Webサービス・コールに追加することに関する必知事項」を参照してください。
|
注意: CookieをREST Webサービス・コールに挿入できるようにするには、アプリケーション機能にリモート認証が使用されている必要があり(MAFは、ユーザー資格証明をローカルに保存するアプリケーション機能に対するCookieの挿入をサポートしていません)、また「ログインURL」に入力されたドメインが、REST Webサービス・エンド・ポイントと一致する必要があります。 |
「HTTPリクエストに基本認証ヘッダーを含めます」: このオプションを選択すると、MAFでは、Webビューから作成したHTTPリクエストに基本認証ヘッダーを追加できます。基本認証は、MAFが使用するデフォルトのリクエスト・メソッドです。基本認証ヘッダーは、ログイン接続タイプがHTTP基本である場合にのみ挿入されます。第21.4.13項「基本認証ヘッダーの挿入に関する必知事項」も参照してください。
「レルム」:
「次へ」をクリックします。
図21-4に示すとおり、「HTTP基本オプション」ページで、次の項目を構成します。
ログインURL: 認証サーバーのログインURLを入力します。
ログアウトURL: 認証サーバーのログアウトURLを入力します。
「マルチテナント対応」: MAFでは、モバイル・アプリケーションは、様々な組織(テナント)が共有するホスト・アプリケーション機能を含みますが、その機能は特定のテナントによって所有されているかのように見えるマルチテナントの概念をサポートしています。このオプションを選択すると、モバイル・アプリケーション接続にマルチテナント対応を定義できます。第21.4.18項「マルチテナント接続を定義する場合の処理」も参照してください。
「テスト」をクリックして、認証サーバーへの接続をテストします。結果はウィザードに表示されます。
第21.4.8項「ログイン資格証明の格納方法」に示すとおり、「次へ」をクリックして、「ログイン・オプション」ページを開いて、パラメータを構成します。
第21.4.15項「アクセス制御の構成方法」に示すとおり、「次へ」をクリックして、「認可オプション」ページを開いて、パラメータを構成します。
「終了」をクリックして、接続を作成します。
図21-5に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードを使用して、クロスドメイン・シングル・サインオンを構成できます。
Web SSOサーバーで認証を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、認証サーバー・タイプとして「Webシングル・サインオン」を選択し、「次へ」をクリックします。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第21.4.1項「MAFログイン接続の作成方法」を参照してください。
「一般オプション」ページで、図21-6に示すとおり、次の項目を構成します。
「接続名」: 接続の名前を入力します。
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
「RESTコールにログイン・サーバーを含める」: リモート認証を使用したアプリケーション機能では、このオプションを選択すると、ログイン・サーバー生成ユーザー・セッション・コードを通じてログイン・サーバーに格納される、認可されたユーザー・データを取得するためにREST Webサービスを有効化できます。詳細は、第21.4.11項「CookieをREST Webサービス・コールに追加することに関する必知事項」を参照してください。
「次へ」をクリックします。
「Webシングル・サインオン・オプション」ページで、次に示すように、成功したログインと失敗したログインを有効化するURLを構成します。
第21.4.15項「アクセス制御の構成方法」に示すとおり、「次へ」をクリックして、「認可オプション」ページで、パラメータを構成します。
図21-8に示すとおり「モバイル・ログイン・サーバー接続」でOracle Access Management Mobile and Social (OAMMS)認証サーバー・タイプを選択すると、Oracle Access Manager (OAM)サーバーを使用して認証できるようにモバイル・アプリケーションの接続を構成できます。この接続タイプのOAMバックエンドは、Oracle Mobile and Socialサーバーおよび10g WebGate(リソースに対するHTTPリクエストを捕捉して、それらを認証と認可のためにOAMサーバーに転送するWebサーバー・プラグイン)を実行している必要があります。
始める前に:
OAMバックエンドがOracle Mobile and Socialサーバーおよび10g Webgateを実行していることを確認します。
OM_PROP_OAMMS_URLプロパティ・キーを使用するようにサーバーを構成します。Mobile and Socialサーバーにアクセスするには、このURL(プロトコル、ホスト名およびポート番号を含む)が必要です。HTTPおよびHTTPSプロトコルのみがサポートされています。また、OAM_ID CookieをWebサーバー・リクエスト・ヘッダーに挿入するようにサーバーを構成する必要もあります。
Oracle Mobile and Socialサーバーを使用してOracle Access Managementで認証を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、認証サーバー・タイプとして「Oracle Access Management Mobile and Social (OAMMS)」を選択し、「次へ」をクリックします。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第21.4.1項「MAFログイン接続の作成方法」を参照してください。
「一般オプション」ページで、次の項目を定義します。
「接続名」: 接続の名前を入力します。
「認証モード」: 表21-1の説明に従って、認証のタイプを選択します。
「アイドル・タイムアウト」: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。
|
注意: MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を行いますが、セッション・タイムアウト後にこの認証を行うことはありません。 |
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
「RESTコールにログイン・サーバーを含める」: リモート認証を使用したアプリケーション機能では、このオプションを選択すると、ログイン・サーバー生成ユーザー・セッション・コードを通じてログイン・サーバーに格納される、認可されたユーザー・データを取得するためにREST Webサービスを有効化できます。詳細は、第21.4.11項「CookieをREST Webサービス・コールに追加することに関する必知事項」を参照してください。
|
注意: CookieをREST Webサービス・コールに挿入できるようにするには、アプリケーション機能にリモート認証が使用されている必要があり(MAFは、ユーザー資格証明をローカルに保存するアプリケーション機能に対するCookieの挿入をサポートしていません)、また「ログインURL」に入力されたドメインが、REST Webサービス・エンド・ポイントと一致する必要があります。 |
「HTTPリクエストに基本認証ヘッダーを含めます」: このオプションを選択すると、MAFでは、Webビューから作成したHTTPリクエストに基本認証ヘッダーを追加できます。基本認証は、MAFが使用するデフォルトのリクエスト・メソッドです。基本認証ヘッダーは、ログイン接続タイプがHTTP基本である場合にのみ挿入されます。第21.4.13項「基本認証ヘッダーの挿入に関する必知事項」も参照してください。
「レルム」:
「次へ」をクリックします。
「OAMMS」ページで、Oracle Access Management Mobile and SocialサーバーのURLを入力し、モバイル・アプリケーション・サービス・ドメインを入力します。
また、図21-9に示すとおり、サーバーがデバイス上で場所を更新できるように接続を構成することもできます。
第21.4.8項「ログイン資格証明の格納方法」に示すとおり、「次へ」をクリックして、パラメータを構成できる「ログイン・オプション」ページを開きます。
第21.4.15項「アクセス制御の構成方法」に示すとおり、「次へ」をクリックして、パラメータを構成できる「認可オプション」ページを開きます。
図21-10に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードを使用して、サード・パーティ・アプリケーション(クライアント)が、保護されているデータまたはリモート・サーバー上に格納されているサービスへの制限付きアクセスを取得する方法を構成できます。Oracle Mobile and Socialサーバーが提供するリライイング・パーティ認証を使用すると、アプリケーションで、サードパーティOAuthプロバイダに対する認証を行うことができます。Oracle Web Services Manager (OWSM) Lite MobileのADFアプリケーション・エージェントは、Webサービス・コールのセキュリティ・ヘッダーにCookieを挿入します。
始める前に:
OM_PROP_OAUTH_OAUTH20_SERVERプロパティ・キーを使用するようにサーバーを構成します。
OAuthサーバーで認証を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、「認証サーバー・タイプ」として「OAuth2」を選択し、「次へ」をクリックします。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第21.4.1項「MAFログイン接続の作成方法」を参照してください。
「一般」ページで、次の項目を構成し、「次へ」をクリックします。
「接続名」: 接続の名前を入力します。
「RESTコールにログイン・サーバーを含める」: リモート認証を使用したアプリケーション機能では、このオプションを選択すると、ログイン・サーバー生成ユーザー・セッション・コードを通じてログイン・サーバーに格納される、認可されたユーザー・データを取得するためにREST Webサービスを有効化できます。詳細は、第21.4.11項「CookieをREST Webサービス・コールに追加することに関する必知事項」を参照してください。
|
注意: CookieをREST Webサービス・コールに挿入できるようにするには、アプリケーション機能にリモート認証が使用されている必要があり(MAFは、ユーザー資格証明をローカルに保存するアプリケーション機能に対するCookieの挿入をサポートしていません)、また「ログインURL」に入力されたドメインが、REST Webサービス・エンド・ポイントと一致する必要があります。 |
「OAuth2」ページで、図21-11に示すとおり、次の項目を構成し、「次へ」をクリックします。
「権限タイプ」を選択し、アプリケーションがログイン・ページを取得する場所を決めます。サーバー・ログイン・ページを表示する場合は、「コード」を選択します。MAFアプリケーションで、デフォルト・ログイン・ページまたは構成済のカスタム・ログイン・ページを表示する場合は、「リソース所有者」を選択します。
「クライアントID」を入力し、オプションで、「クライアント・シークレット」フィールドに接続パスワードの値を入力します。
「認可エンドポイント」自体のエンドポイントのURI、「トークン・エンドポイント」および認証サーバーの「リダイレクト・エンドポイント」を入力します。
「ログアウトURL」を入力します。
ログイン・ページをアプリケーション内の埋込みブラウザ内に表示する場合は、「埋込みブラウザの使用」を選択します。外部ブラウザでログイン・ページを表示するには選択解除します。シングル・サインオン(SSO)を使用する場合、このオプションを選択解除して、アプリケーションに外部ブラウザを使用させる必要があることに注意してください。
「スコープ」に1つ以上入力します。
第21.4.15項「アクセス制御の構成方法」の説明に従って、「認可」ページでパラメータを構成します。
図21-12に示すとおり、開発時に「モバイル・ログイン・サーバー接続」ウィザードを使用して名前付き接続を作成し、実行時に接続が完全に定義されるようにログイン属性を移入できます。この接続タイプは、設計時に一部の接続属性がわかっていない場合に特に便利です。
アプリケーション開発者は、第21.4.7項「実行時の名前付き接続の接続属性の更新方法」の説明に従って、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIを使用して、設計時に作成されるプレースホルダ接続を完全に定義する必要があります。
設計時にプレースホルダ接続の定義を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、「認証サーバー・タイプ」として「実行時に値を指定」を選択します。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第21.4.1項「MAFログイン接続の作成方法」を参照してください。
「一般」タブで、次の項目を構成します。
「接続名」: 接続の名前を入力します。アプリケーション開発者は、第21.4.7項「実行時の名前付き接続の接続属性の更新方法」の説明に従って、この識別子を使用して、更新する接続を特定します。
「RESTコールにログイン・サーバーを含める」: リモート認証を使用したアプリケーション機能では、このオプションを選択すると、ログイン・サーバー生成ユーザー・セッション・コードを通じてログイン・サーバーに格納される、認可されたユーザー・データを取得するためにREST Webサービスを有効化できます。詳細は、第21.4.11項「CookieをREST Webサービス・コールに追加することに関する必知事項」を参照してください。
|
注意: CookieをREST Webサービス・コールに挿入できるようにするには、アプリケーション機能にリモート認証が使用されている必要があり(MAFは、ユーザー資格証明をローカルに保存するアプリケーション機能に対するCookieの挿入をサポートしていません)、また「ログインURL」に入力されたドメインが、REST Webサービス・エンド・ポイントと一致する必要があります。 |
「HTTPリクエストに基本認証ヘッダーを含めます」: 接続タイプに基本認証を使用して、MAFで、Webビューから作成したHTTPリクエストに基本認証ヘッダーを追加できるようにする場合は、このオプションを選択します。基本認証は、MAFが使用するデフォルトのリクエスト・メソッドです。基本認証ヘッダーは、ログイン接続タイプがHTTP基本である場合にのみ挿入されます。第21.4.13項「基本認証ヘッダーの挿入に関する必知事項」も参照してください。
第21.4.15項「アクセス制御の構成方法」に示すとおり、「認可」タブをクリックして、パラメータを構成します。
アプリケーションの開発者は、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIを使用して、プレースホルダ(図21-12に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードで「実行時に値を指定」を選択した場合)または完全に移入された接続定義のいずれかで、すでに存在する接続の接続属性を定義または再定義できます。
|
注意: 一般的なタイミングは、アプリケーション・ライフサイクル・リスナー内で |
configUrlParamパラメータに関連付けられた接続属性を更新するには、updatedSecurityConfigWithURLParametersメソッドを次のようにコールします。
import oracle.adfmf.framework.api.AdfmfJavaUtilities;
...
AdfmfJavaUtilities.updateSecurityConfigWithURLParameters(configUrlParam,
key, message, showConfirmation);
keyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして設定されます。MAFが接続の既存の属性に対する接続構成の変更を検出すると、trueに設定されたshowConfirmationパラメータでメソッドを呼び出して、MAFで確認プロンプトをエンドユーザーに表示できます。
AdfmfJavaUtiltiesクラスおよびconfigUrlParamパラメータの使用の詳細は、Oracle Fusion Middleware Oracle Mobile Application FrameworkのJava APIリファレンスを参照してください。
セキュリティが重要でない場合、MAFはユーザー資格証明の格納をサポートしますが、これは、ログイン・サーバーにリプレイできるか、またはユーザーをローカルで認証するために使用できます(ログイン接続に定義されているモードによって異なります)。資格証明を格納すると、ユーザーはログインせずにモバイル・アプリケーションにアクセスできるため、ユーザーの操作性が向上します。IDM Mobile SDKを使用すると、MAFは次のモードをサポートできます。
自動ログイン - MAFはユーザー資格証明をキャッシュし、以降の認証時にそれらを認証サーバーにリプレイします。このモードでは、ユーザーは、MAFによってユーザーに資格証明を入力または確認するよう求められずにアプリケーションを起動できます。ただし、MAFは、新しいアプリケーション・セッションが開始されたことをユーザーに通知できます。
資格証明を記憶 - MAFは、ユーザー資格証明をキャッシュし、ログイン・ページのユーザー名およびパスワード・フィールドを移入します。ユーザーがログイン・ボタンをタップして、これらの資格証明を確認すると、MAFはそれらを認証サーバーにリプレイします。
ユーザー名を記憶 - MAFは、ユーザー名をキャッシュし、ログイン・ページの「ユーザー名」フィールドを移入します。ユーザーがパスワードを入力し、ログイン・ボタンをタップして確認すると、MAFはそれらの資格証明を認証サーバーにリプレイします。
|
注意: ユーザーは、MAFが資格証明を格納するかどうかを決定できます。 |
図21-13に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードの「ログイン・オプション」ページを使用して、資格証明の格納オプションを選択できます。資格証明オプションを使用すると、オプションを使用したログイン・ページが移入され、ユーザー名とパスワードが記憶されるため、オプションデバイスが複数のエンド・ユーザーによって共有されている場合は選択しないでください。
ローカルおよびハイブリッド・ログイン接続モードでは、リモート接続と同様、ユーザーはアプリケーション・ライフサイクル内で任意の数のIDを使用して、ログインおよびログアウトできます。ログイン接続を定義してこれらの接続モードを使用するとき、現在のセッション・タイムアウト期間内に、保護されているアプリケーション機能にすでにログイン済である場合は、ユーザーは、ローカル資格証明ストアを使用して保護されているアプリケーション機能に再びログインできます。この場合、明示的にログアウトしたユーザーまたはアイドル・タイムアウトが期限切れになっているためにログアウトされたユーザーは、保護されているアプリケーション機能(またはアプリケーション機能を保護するログイン・サーバーによって保護されているその他のアプリケーション機能)に再びログインできます。
|
注意: 基本認証およびOracle Access Management Mobile and Social (OAMMS)への認証では、ローカルおよびハイブリッド接続のみを利用できます。OAuthおよびFederate SSOはリモート認証を使用するため、認証が成功しない場合、アプリケーション・ユーザーはアプリケーションに再びログインできません。 |
図21-15に示すとおり、「モバイル・ログイン・サーバー接続」ダイアログで「RESTコールにログイン・サーバーのCookieを含める」オプションを選択すると、MAFは、ログイン・サーバーによって送信されたこのユーザー・セッションCookieを取得し、それをモバイル・アプリケーションから開始されたREST Webサービス・コールのHTTPヘッダーに挿入します。
モバイル・アプリケーションがREST Webサービスを要求するたびに、MAFのセキュリティ・フレームワークは、REST Webサービスのトランスポート・レイヤーが、REST WebサービスのURLエンドポイントに関連付けられているログイン接続に対してCookieの挿入が可能かどうかをチェックできるようにします。(つまり、例21-4に示されているように、connections.xmlファイルに<injectCookiesToRESTHttpHeader value="true"/>が含まれている必要があります。)
接続でCookieの挿入が許可されていて、ログイン・サーバーとREST Webサービス・エンドポイントのドメインが一致している場合、セキュリティ・フレームワークによって、ユーザーがアプリケーション機能にログインしたときに格納されたCookieが取得されます。MAFは、REST Webサービス・リクエストのドメインのために格納されているすべてのCookieを伝播します。MAFは、Rest Webサービス・レスポンスの各「設定-Cookie」ヘッダーのCookieを格納します。「設定-Cookie」ヘッダーは、Cookieをストアに追加したり、既存のCookieを新しいCookieと置き換えることができます(名前が同じ場合)。REST Webサービス・レスポンスによって返されるCookieおよび認証プロセスによって返されるCookieは、以降のREST Webサービス・リクエストに挿入されます。
|
注意: MAFは、Oracle Access Management Mobile and Social (OAMMS) APIをコールすることで、Cookie文字列を作成し、Oracle Access Management Mobile and Social (OAMMS) APIは、プラットフォーム固有のCookieストアから名前でCookieを戻します。IDM Mobile SDKは、認証サーバーによって戻されたCookieを管理します。それらの名前は、 |
ユーザーがモバイル・アプリケーションによって正常に認証されると、ログイン・サーバーは、そのユーザーのセキュリティ・コンテキストを作成し、ユーザー・セッションを追跡するCookieを生成します。図21-15に示すとおり、「モバイル・ログイン・サーバー接続」ダイアログで「RESTコールにログイン・サーバーのCookieを含める」オプションを選択すると、MAFは、ログイン・サーバーによって送信されたこのユーザー・セッションCookieを取得し、それをモバイル・アプリケーションから開始されたREST Webサービス・コールのHTTPヘッダーに挿入します。
CookieをWebサービス・コールに伝播することで、ログイン・サーバーに格納されているユーザーのセキュリティ・コンテキストを取得し、モバイル・アプリケーションがREST Webサービスを使用して、そのユーザーに対して認可されているアプリケーション・データにアクセスできるようになります。ユーザー・セッションCookieが期限切れになると、MAFは、ユーザーに資格証明を要求し、ユーザーを再認証します。再認証されたユーザーは、引き続き、REST Webサービス・コールを介して認可済のアプリケーション・データにアクセスできます。
ユーザーがローカルで認証されると、MAFは、モバイル・アプリケーションがREST Webサービスをコールするときに、ログイン・サーバーに対してユーザーをサイレントに認証します。ユーザーの資格証明が認証されると、MAFは、REST Webサービスに対してアプリケーションのリクエストを実行します。REST Webサービスが401ステータス・コードを返した場合(未許可)、MAFは、ユーザーにもう一度認証するよう求めます。REST Webサービスが302コードを返した場合(見つかったか一時的に移動されている)、MAFは、ログイン・サーバーをチェックして、ユーザーが認証されているか確認します。その場合は、コードが302リダイレクトとして処理されます。
ユーザーがログイン・サーバーに対して認証されていない場合、MAFは、ユーザーにもう一度認証するよう求めます。302ステータス・コードを返した場合、ログイン・サーバーは、ユーザーに独自のWebページを使用して認証するよう求めることもあります。このような場合、MAFはリダイレクションをサポートしていないため、かわりにユーザーにもう一度MAFログイン・ページを使用してログインするよう求めます。
サーバーがCookieを受け付けない場合、MAFでは、Webビューから発行されたHTTPリクエストに基本認証ヘッダーを挿入することで、アプリケーション機能がセキュア・リソースにアクセスできます。デフォルトでは、MAFは基本認証を使用します。デフォルトでは「HTTPリクエストに基本認証ヘッダーを含めます」オプションが選択されているため、MAFでは、Webビューから発行されたHTTPリクエストに基本認証ヘッダーを挿入することによって、アプリケーション機能はセキュア・リソースにアクセスできます。
|
注意: MAFによって基本認証ヘッダーが挿入されないようにするには、 |
ユーザー名とパスワードの認証レルムを定義すると、定義された<realm>要素を使用したconnections.xmlファイルが移入されます。例21-1に示すとおり、MAFは、connections.xmlファイルがそれらの定義を含むか含まないかにかかわらず、ヘッダーを追加します。
例21-1 接続.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属性によって示されます(例21-4ではadfCredentialStoreKey="Connection_1")。Webサービスがこの資格証明ストアを使用できるようにするには、SOAPまたはREST Webサービス接続のadfCredentialStoreKey属性に対して定義されている名前が、ログイン・サーバーのadfCredentialStoreKey属性に対して定義されている名前と一致する必要があります。
|
注意: エディション |
詳細は、第8.5.2項「資格証明の挿入に関する必知事項」を参照してください。
図21-14に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードの「認可」ページを使用して、アクセス制御を構成できます。アプリケーション機能にセキュリティ保護されているコンポーネントが含まれている場合は、このページを使用します。たとえば、disabledとして定義されたsecurityContextオブジェクトを含むEL式を使用して、送信ボタンがある経費レポート・アプリケーションを構成すると、manager権限でこのアプリケーションにログインするユーザーのみに送信ボタンが表示されます。この「認可」ページのフィールドを完了すると、アクセス制御サービス(アプリケーション機能がチェックする特定のユーザー・ロールの取得を可能にするRESTful Webサービス)が構成されます。
アプリケーション・ログイン・サーバーによって付与されるアクセス制御は、第15.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は、取得されたユーザー・ロールと権限に照らして各アプリケーション用に構成されている制約を評価し、関連付けられているすべての制約を満たすユーザーのみがアプリケーション機能を使用できるようにします。
アクセス制御を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、「認可」ページに移動します。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第21.4.1項「MAFログイン接続の作成方法」を参照してください。
図21-14に示すとおり、「認可」ページで、認可要件を完了します。
アクセス制御サービスURL: アクセス制御サービス(ACS)のエンドポイントであるURLを入力します。
|
注意: MAFは、ACSを呼び出すときに、認証サーバー(つまりログイン・サーバー)によって発行されたすべてのCookieをHTTPリクエスト・ヘッダーに挿入します。Cookieの挿入は、「RESTコールにログイン・サーバーを含める」を選択し、「アクセス制御URL」パラメータと「ログインURL」パラメータに同じドメインを入力した場合に発生します。MAFは、Cookieを挿入する前に、ACS URLおよびログインURLのドメインが同一であるかを検証します。同一でない場合、ログイン・サーバーのCookieはACSリクエストに挿入されないため、ACSに対する認証は失敗します。原則として、セキュア・アクセスのためにユーザー認証が必要となるよう、ACS URLを保護する必要があります。第21.4.11項「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: ユーザー情報をフィルタ処理するために使用される権限のリスト。
|
注意: すべてのロールを戻す必要がある場合は、 すべての権限を戻す必要がある場合は、 |
例21-2は、HTTP POSTメッセージを示しています。この例では、JSONオブジェクトをペイロードとして識別し、John Smithというユーザーに割り当てられているすべてのフィルタとロールをリクエストします。
例21-2 ユーザー・ロールおよび権限の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配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられている権限のリスト全体が戻されます。
例21-3は、戻されたJSONオブジェクトを示しています。これには、ユーザー名およびJohn Smithというユーザーに割り当てられているロールと権限が含まれています。
例21-3 戻されたJSONオブジェクト
Content-Type: application/json
{
"userId": "johnsmith",
"roles": [ "role1" ],
"privileges": ["priv1", "priv3"]
}
|
注意: Webサービスでは、ログイン・ページはなく、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービスのヘッダーに自動的に資格証明が追加されます。詳細は、第8.5.2項「資格証明の挿入に関する必知事項」を参照してください。 |
|
注意: ACSサービスを実装してホストする必要があり、MAFでは、このサービスは提供されません。 |
MAFは、ユーザーが、図21-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リクエストに追加のペイロードを挿入できます。例21-1に示すとおり、keyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして戻されます。appLoginパラメータをtrueに設定すると、ACSでフィーチャ・アクセスが再評価できます。OptionalExtraPayLoadパラメータは、今後の使用のために予約済であるため使用されません。
invokeACSメソッドまたはisAcsCalledAutomaticallyパラメータのいずれかを使用してACSを起動すると、アプリケーションにロール・ベースの制約が取得されます。
|
注意:
|
保護されているアプリケーション機能がinvokeACSメソッドをコールすると、MAFは、保護されているアプリケーション機能に構成されている制約を含む、アプリケーション・ログイン接続に関連付けられたすべてのアプリケーション機能のユーザー制約をフェッチします。保護されていないアプリケーション機能がこのメソッドをコールすると、MAFは、ログイン接続に関連付けられた制約を取得するのみです。
|
注意:
詳細は、Oracle Fusion Middleware Oracle Mobile Application FrameworkのJava APIリファレンスを参照してください。 |
「モバイル・ログイン・サーバー接続」ウィザードを完了すると、MAFは、connections.xmlファイルに、trueに設定された<isMultiTenantAware>要素を移入します。マルチテナント接続では、ユーザー名は、テナント名とユーザー名を集約したものです。
接続がマルチテナント対応である場合、ログイン・ページは、JavaScriptユーティリティを使用して認識します。ログイン・ページがそのような接続を検出すると、追加フィールドが表示され、ユーザーは、モバイル・ログイン・サーバー接続に構成されているテナント名をそのフィールドに入力する必要があります。ログイン(正しいテナントIDの入力を含む)が成功すると、MAFは、ローカル資格証明ストアにテナントIDを格納します。
MAFでは、connections.xmlファイル内のすべての接続情報が集約されます(このファイルは、「プロジェクト・エクスプローラ」の「アプリケーション・リソース」パネルの「ディスクリプタ」および「ADF META-INF」ノードの下にあります)。このファイル(例21-4を参照)は、アプリケーションにバンドルすることも、構成サービス用にホスティングすることもできます。後者の場合、MAFは、アプリケーションが起動されるたびに、更新済の構成情報があるかどうかをチェックします。
例21-4 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.jsf"/>
<logout url="http://10.0.0.0/SecuredWebServicelogout/logout.jsf"/>
<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機能エディタ、MAFアプリケーション・エディタおよび「モバイル・ログイン・サーバー接続」ウィザードを使用してセキュリティを構成します。エディタを使用すると、認証を必要とするアプリケーション機能をユーザーが選択したときにMAFによって表示されるログイン・ページのタイプ(デフォルトまたはカスタム)を指定したり、ユーザー・ロールまたはユーザー権限ベースの制約を含めることができます。また、これらによって、セキュリティが必要な埋込みアプリケーション機能を選択することもできます。
セキュリティが適用されるように各アプリケーション機能を定義できます。残りのセキュリティ構成は、MAFアプリケーション・エディタの「セキュリティ」のセクションを使用して行います。アプリケーション機能のコンテンツがリモートURLから提供される場合に、このエディタを使用すると、リモートURLのコンテンツをMAFのWebビューに表示できるように、ドメインをホワイトリストできます。詳細は、第13章「リモートURLを使用したアプリケーション機能コンテンツの実装」を参照してください。
図21-15に示すとおり、セキュリティが適用されるアプリケーション機能およびMAF機能エディタの「機能」セクションで必要な認証タイプを指定できます。
始める前に:
機能のセキュリティを有効化すると、アプリケーションは、ネットワークにアクセスしてユーザーを認証する必要があります。ネットワーク・ソケットへのアプリケーション・アクセスの付与の詳細は、第21.6.1項「デバイス機能へのアクセスを有効化する方法」を参照してください。
アプリケーション機能に対するユーザー・アクセスを指定するには:
プロジェクト・エクスプローラのユーザー・インタフェース・プロジェクトで、MAFを展開し、「MAF機能エディタ」をダブルクリックします。
MAF機能エディタで、「機能」の下にリストされているアプリケーション機能を選択するか、または「機能」を右クリックし、「新」を選択してアプリケーション機能を追加します。
ログインが必要なアプリケーション機能に「セキュリティの有効化」を選択します。
|
ヒント: このオプションをデフォルトのアプリケーションに適用しない場合、ユーザーは匿名で(つまり、ログイン資格証明を入力せずに)ログインできます。ユーザーは、保護されていないデータおよび機能にアクセスでき、要求があった場合にはログインします(認証されたユーザーは、保護されているデータと保護されていないデータの両方にアクセスできます)。モバイル・アプリケーション内の保護されていないアプリケーション機能を指定すると、ユーザーは、保護されているアプリケーション機能からログアウトできますが、モバイル・アプリケーション自体ではログイン状態が維持され、保護されていないアプリケーション機能とデータの両方へのアクセスを継続します。 |
アプリケーション機能のセキュリティを指定したら、図21-16に示されているMAFアプリケーション・エディタの「セキュリティ」ページを使用して、セキュリティが適用される各アプリケーション機能に対して、ログイン・ページの構成およびログイン・サーバーへの接続の作成とその割当てを行います。このページにリストされているすべてのアプリケーション機能は、MAF機能エディタで、セキュリティが必要なものとして指定されています。通常、アプリケーション機能のグループは、同じログイン・サーバー接続で保護され、ユーザーは、MAFから再度ログインを求められることなく、これらのアプリケーションをどれでも開くことが可能です。ただし、場合によっては、あるアプリケーション機能のセットを保護しているログイン・サーバーと、別のアプリケーション機能のセットを保護しているログイン・サーバーが異なるため、アプリケーション機能で要求される資格証明がそれぞれ異なる可能性があります。このような状況に対応するために、モバイル・アプリケーション用のログイン・サーバーへの接続をいくつも定義できます。maf-application.xmlファイルでは、機能参照に関連付けられている認証サーバー接続は、次のようにloginConnRefId属性を使用して指定されます。
<adfmf:featureReference id="feature1" loginConnRefId="Connection_1"/> <adfmf:featureReference id="feature2" loginConnRefId="Connection2"/>
モバイル・アプリケーションは、HTTPまたはHTTPS経由の基本認証をサポートしている標準のログイン・サーバーなら、どのログイン・サーバーに対しても認証を受けることが可能です。MAFはまた、Oracle Identity Managementに対する認証もサポートしています。特定のアプリケーション機能用のカスタム・ログイン・ページを選択することもできます。詳細は、第21.5.3項「ログイン・ページに関する必知事項」を参照してください。
|
注意: デフォルトでは、保護されているすべてのアプリケーション機能が同じ接続を共有し、この接続は、図21-16に示すとおり、<application login server>と表示されます。「機能参照」の「プロパティ・インスペクタ」では、このデフォルト・オプションが「ログイン・サーバー接続」ドロップダウン・メニューに |
始める前に:
モバイル・アプリケーションでカスタム・ログイン・ページを使用する場合は、アプリケーション・コントローラ・プロジェクトのpublic_htmlディレクトリ(users\workspaces\Application\ApplicationController\public_html)にファイルを追加して、図21-17に示すとおり、プロジェクト・エクスプローラの「Webコンテンツ」ノードからそれを使用できるようにします。第21.5.3.3項「カスタム・ログインHTMLページの作成」および第4.11.2項「外部リソースの選択に関する必知事項」も参照してください。
第15.2.4項「ユーザー制約とアクセス制御について」の説明に従って、ユーザー権限とロール用の制約を追加します。
アクセス制御サービス(ACS)・サーバーをプロビジョニングします。詳細は、第21.4.16項「アクセス制御サービスに関する必知事項」を参照してください。
ログイン・ページおよびナレッジベース認証を指定するには:
プロジェクト・エクスプローラで、アセンブリ・プロジェクトおよびMAFの順に展開し、「MAFアプリケーション・エディタ」をダブルクリックします。
アウトラインで、「セキュリティ」をクリックします。
「セキュリティ」ページで、ログイン・ページのタイプを指定します。
ユーザー名およびパスワードを受け入れるビューとして、「ログイン・ページ」を選択します。
ユーザーにユーザーの資格証明のチャレンジを表示し、またそれらの答えを受け入れるナレッジベース・ビューとして、「ナレッジベース認証ページ」を選択します。ナレッジベース認証をOAAMサーバー上に構成でき、またユーザーに、「母親の旧姓」などの追加の質問を尋ねる別のページを表示できます。この機能は、Mobile-Social認証タイプのみで利用できます。
選択したログイン・ページおよびナレッジベース認証ページ(オプション)のコンテンツ(またはユーザー・インタフェース)を選択します。
「デフォルト」: すべての選択した埋込みアプリケーション機能に使用されるデフォルト・ログイン・ページまたはナレッジベース認証画面。詳細は、第21.5.3.1項「デフォルト・ログイン・ページ」を参照してください。デフォルトのログイン・ページおよびデフォルト・ナレッジベース認証は、MAFによって提供されているものです。
「カスタム」: 「参照」をクリックして、アプリケーション・コントローラ・プロジェクト内のファイルのパスの場所を検索します。または、「新」をクリックして、ログイン・ページまたはナレッジベース認証ページのいずれかのアプリケーション・コントローラ・プロジェクト内にカスタムHTMLページを作成します。詳細は、第21.5.3.2項「カスタム・ログイン・ページ」および第21.5.3.3項「カスタム・ログインHTMLページの作成」を参照してください。
|
ヒント: 「参照」機能を使用してログイン・ページの場所を検索するのではなく、「プロジェクト・エクスプローラ」からログイン・ページをフィールドにドラッグできます。 |
アプリケーション機能への認証プロセスのエントリ・ポイントは、activateライフサイクル・イベントです(第4.8.2項「モバイル・アプリケーション・イベントのタイミング」を参照)。アプリケーション機能がアクティブ化される(つまり、アプリケーション機能のactivateイベント・ハンドラがコールされる)たびに、アプリケーション機能のログイン・プロセスが実行されます。このプロセスは、ログイン・ページ(デフォルトまたはカスタムのログイン・ページのいずれか)に移動し、そこでユーザー認証が必要かどうかを判断します。ただし、プロセスがログイン・ページに移動する前に、本来意図されていたアプリケーション機能をMAFに登録する必要があります。認証が成功すると、ログイン・ページは、MAFから本来意図されていた宛先を取得し、そこに移動します。
MAFによって提供されるデフォルト・ログイン・ページ(図21-1「ログイン・ページ」を参照)は、ログイン・ボタンと、ユーザー名、パスワード、マルチテナント名およびエラー・メッセージ・セクション用の入力テキスト・フィールドから構成されます。これは、HTMLで記述されたクロス・プラットフォーム・ページです。
MAF機能エディタを使用して、選択したアプリケーション機能用のカスタム・ログイン・ページを追加すると、Oracle Enterprise Pack for Eclipseは、例21-5に示すとおり、<adfmf:login>要素を追加し、その子要素<adfmf:LocalHTML>を移入します。すべての<adfmf:LocalHTML>要素と同様に、そのurl属性は、public_htmlディレクトリ内の場所を参照します。ユーザー認証メカニズムとナビゲーション・コントロールは、デフォルトのログイン・ページと同じものになります。
例21-5 ログイン要素
<adfmf:login defaultConnRefId="Connection_1">
<adfmf:localHTML url="newlogin.html"/>
</adfmf:login>
カスタム・ログイン・ページはHTMLで記述されています。デフォルトのログイン・ページおよびナレッジベース認証ページの両方のフィールドには、特別に定義された<input>および<label>要素が含まれている必要があります。
|
ヒント: MAFアプリケーションをカスタム・ログイン・ページを作成するためのガイドとしてデプロイしたときに生成されるデフォルトのログイン・ページを使用します。 Androidデプロイメントの場合、このページは、アプリケーション・ワークスペース・ディレクトリ |
例21-6は、デフォルト・ログイン・ページに必要な<input>および<label>要素を示しています。
例21-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"/>
例21-7は、「ナレッジベース認証」ログイン・ページに必要な要素を示しています。
例21-7 「ナレッジベース認証」ログイン・ページに必要な要素
<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"/>
MAFのデプロイメントによってwwwディレクトリ内に生成されるアーティファクトである、デフォルトのログイン・ページ(adf.login.htmlまたはadf.kba.html)を使用して、カスタム・ログイン・ページを作成できます。
始める前に:
wwwディレクトリ内のログイン・ページにアクセスするには、モバイル・アプリケーションをデプロイした後、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 profiile name.apk/assets/www/adf.login.html
および
application workspace directory/application name/deploy/deployment profile name/deployment profiile name.apk/assets/www/adf.kba.html
カスタム・ログイン・ページを作成するには:
デフォルト・ログイン・ページを、ユーザー・インタフェース・プロジェクトのpublic_htmlディレクトリ内の場所(users\workspace\アプリケーション名\ApplicationController\public_htmlなど)にコピーします。
ログイン・ページの名前を変更します。
ページを更新します。
MAFアプリケーション・エディタの「セキュリティ」のセクションで、「カスタム」を選択し、「参照」をクリックしてログイン・ページの場所を検索します。詳細は、第4.6項「Springboardとナビゲーション・バーの動作の構成」を参照してください。
各HTMLログイン・ページには、表21-2にリストされているユーザー・インタフェース要素が含まれている必要があります。
表21-2 ログイン・ページ・フィールドおよびその関連ID
| ページの要素 | ID |
|---|---|
|
「ユーザー名」フィールド |
|
|
「パスワード」フィールド |
|
|
「ログイン」ボタン |
|
|
「取消」ボタン |
|
|
「Identityドメイン」/「テナント名」フィールド |
|
|
「ナレッジベース認証」の質問フィールド(読取り専用/ラベル) |
|
|
「ナレッジベース認証」の回答フィールド |
|
|
「エラー」フィールド |
|
|
自動ログイン・チェック・ボックス |
|
|
「資格証明を記憶」チェック・ボックス |
|
|
「ユーザー名を記憶」チェック・ボックス |
|
表21-3は、OnClickイベントで使用される推奨のJavaScriptコードをリストしています。
セキュリティが適用されるようにアプリケーション機能が指定されると、Oracle Enterprise Pack for Eclipseは、図21-16に示すとおり、対応する機能参照で「登録されている機能」を更新します。参照される各アプリケーション機能が、connections.xmlファイル内に定義されている同じログイン・サーバー接続に対して認証を行うと、Oracle Enterprise Pack for Eclipseは、defaultConnRefId属性を使用して定義されている単一の<adfmf:login>要素(<adfmf:login defaultConnRefId="Connection_1">など)でmaf-application.xmlファイルを更新します。
connections.xmlファイル内に定義されている別のログイン・サーバー接続を使用するように構成されているアプリケーション機能の場合は、Oracle Enterprise Pack for Eclipseは、参照される各アプリケーション機能をloginConnReference属性(<adfmf:featureReference id="feature2" loginConnRefId="Connection2"/)で更新します。詳細は、第21.5.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照してください。また、Oracle Fusion Middleware Oracle Mobile Application Frameworkのタグ・リファレンスも参照してください。
デフォルトでは、モバイル・アプリケーションの一部のApache Cordova対応デバイス機能へのアクセスは有効化されていません。かわりに、MAFは特定の機能へのアクセスを許可することで、セキュリティを保証します。モバイル・アプリケーションのセキュリティおよびプライバシー要件を評価する際、アプリケーションに必要なアクセスの種類を選択できます。デフォルトでは、モバイル・アプリケーションの次の機能は使用できません。
「ネットワーク」: アプリケーションがネットワーク・ソケットをオープンすることを許可します。1つ以上のデバイス機能でセキュリティを有効化する場合、この機能をアプリケーションに付与する必要があります。
「位置」: 細かい位置情報サービス(GPS)と大まかな位置情報サービス(ネットワーク・ベース)の両方に対応します
「カメラ」: アプリケーションがデバイスのカメラを使用することを許可します。
「連絡先」: アプリケーションがデバイス上の連絡先にアクセスすることを許可します。
「電子メール」: アプリケーションが電子メールにアクセスし送信することを許可します。
「SMS」: アプリケーションがSMSメッセージにアクセスし送信することを許可します。
「電話」: アプリケーションが音声サービスにアクセスし通話することを許可します。
「プッシュ通知」: アプリケーションによるプッシュ通知の受信を許可します。第17.2項「モバイル・アプリケーションのプッシュ通知の有効化」も参照してください。
「ファイル」: アプリケーションがデバイスのSDカード上のファイルにアクセスすることを許可します。
ユーザーは、アクセス権限を付与または制限できるため、デプロイメント・フレームワークによって更新される様々なプラットフォーム固有の構成ファイルおよびマニフェスト・ファイルは、使用中のサービス(つまり、モバイル・アプリケーションで使用を許可されているデバイス・サービス)のみをリストしますこれらのファイルにより、MAFは、他のアプリケーションでこれらのサービスを使用することに関する情報を共有できます。たとえば、モバイル・アプリケーションは、(モバイル・アプリケーションに搭載されている場合でも)モバイル・アプリケーションがロケーションベースのサービスを使用しないことをAppStoreまたはGoogle Playに報告できます。
モバイル・アプリケーションのデバイス・アクセスは、アプリケーション・レベルおよび優先されるアプリケーション・レベルで設定された構成を含むアプリケーション機能レベルの両方で構成されていて、またアプリケーション機能の構成は、そのデバイス要件を表す一方、それらの機能を使用する権限はアプリケーション構成を通じて付与されています。
MAF機能エディタおよびMAFアプリケーション・エディタを使用すると、<adfmf:deviceFeatureAccess>要素を作成することで、デバイス機能を指定および管理できます。いずれの構成ファイルも、この要素およびそのデバイス固有の子要素を共有しますが、maf-feature.xmlファイルの要素はrequestAccess属性を使用して定義され、maf-application.xmlファイルの要素はallowAccess属性を使用して定義されます。
アプリケーション機能に必要なデバイス機能を指定するには:
プロジェクト・エクスプローラで、ビュー・プロジェクトおよびMAFの順に展開し、「MAF機能エディタ」をダブルクリックします。
図21-18に示すとおり、MAF機能エディタで、機能のノードを展開し、「デバイス・アクセス」を選択して、アプリケーションに必要なデバイス機能を有効化します。
機能を選択すると、黄色い通知アイコンが表示されます。マウスをアイコンの上に置くと、メッセージ「オブジェクト'Emil Access'のプロパティ'Device Access'。'Email Access'へのアクセスはアプリケーションによって付与されていません。」が表示されます。
MAFアプリケーション・エディタで権限を付与すると、アイコンは消えます。
第21.5.1項「認証を要求するようにアプリケーション機能を設定する方法」に示すとおり、1つ以上のデバイス機能のセキュリティを有効化する場合、ネットワークへのアクセスも有効化する必要があることに注意してください。この場合、次で説明するとおり、MAFアプリケーション・エディタでネットワーク機能に権限を付与できます。
デバイス機能に権限を付与するには:
プロジェクト・エクスプローラで、アセンブリ・プロジェクトおよびMAFの順に展開し、「MAFアプリケーション・エディタ」をダブルクリックします。
図21-19に示すとおり、MAFアプリケーション・エディタで、アウトラインの「デバイス・アクセス」をクリックし、アプリケーションに必要なデバイス機能に権限を付与します。
権限が必要な1つ以上の機能を持つデバイスが、黄色い通知アイコンで示されます。マウスをアイコンの上に置くと、デバイスをリクエストしている機能を確認できます。デバイスを選択すると表示される青いアイコンの上にマウスを置くと、デバイスを使用している機能をチェックできます。
例21-8に示すとおり、MAFは、<adfmf:deviceFeatureAccess>を使用して<adfmf:feature>要素を移入します。
例21-8 maf-feature.xmlファイルにおけるデバイス機能の定義
<adfmf:feature id="feature3" name="feature3">
<adfmf:content id="feature3.1">
<adfmf:amx file="feature3/datapage.amx"/>
</adfmf:content>
<adfmf:deviceFeatureAccess>
<adfmf:deviceEmails id="de1" requestAccess="true"/>
</adfmf:deviceFeatureAccess>
</adfmf:feature>
maf-application.xmlファイルでは、例21-9に示すとおり、MAFによって、<adfmf:deviceFeatureAccess>要素が移入されます。
例21-9 maf-application.xmlファイルにおけるデバイス機能権限の追加
<adfmf:deviceFeatureAccess>
<adfmf:deviceCamera id="dc1" access="true"/>
<adfmf:deviceContacts id="dc2" access="true"/>
<adfmf:deviceEmails id="de1" access="true"/>
<adfmf:deviceFiles id="df1" access="true"/>
<adfmf:deviceLocation id="dl1"/>
<adfmf:deviceNetwork id="dn1"/>
<adfmf:devicePhone id="dp1"/>
<adfmf:deviceSMS id="dsms1" access="true"/>
</adfmf:deviceFeatureAccess>
詳細は、Oracle Fusion Middleware Oracle Mobile Application Frameworkのタグ・リファレンスを参照してください。
関連するデバイス・アクセス権限がmaf-application.xmlファイルに構成されていないDeviceFeaturesデータ・コントロール・メソッドからコンポーネントを作成する場合、図21-20に示すとおり、MAFは、このメソッドに対するダイアログを表示します。ダイアログのデフォルト・オプションでは、権限を使用してmaf-application.xmlファイルを更新するか、または「デバイス・アクセス権限の編集」オプションを使用してファイルを開いて、手動で更新できます。
デバイス関連のmethodActionバインドが存在するが、適用可能なデバイス・アクセス権限が削除されている(または定義されていない)場合、MAFは、「MAF AMXページ」内で、次の形式の(および図21-21のアラートで示すような)エラーを発行します。適切なデバイス・アクセスがmaf:application.xmlファイルで付与されていない場合、メソッドは機能せず、ランタイム・エラーが発生します。
Application is not allowed to access device <deviceFeatureName>. Enable Device <deviceFeatureName> access in maf-application.xml for <bindingId> to work
各デプロイメント時に、MAFは、モバイル・アプリケーションが許可するデバイス機能を含むiOS cordova.plistファイル、Android config.xml、AndroidManifest.xmlおよびAndroidManifest.template.xmlファイルを更新します。具体的には、MAFデプロイメント・プロセスは、これらのファイルからデフォルトのCordovaプラグイン情報を省略し、maf-application.xmlファイルの<adfmf:deviceFeatureAccess>要素で定義されている子要素をiOSおよびAndroidファイルで定義されている権限にマップします。表21-4は、<adfmf:deviceSMS>要素がプラットフォーム固有のファイルの要素にマップする例を示しています。MAFは、各デプロイメントでこれらのファイルを再生成します。
表21-4 プラットフォーム固有のファイルへの<adfmf:deviceSMS>のマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<key>Plugins</key> <dict> <key>AdfmfSMS</key> <string>AdfmfSMSAdaptor</string> </dict> |
|
|
一部のプラグインは、表21-5に示すとおり、AndroidManifest.xmlファイルで権限を共有します。これらの権限がすでに存在しない場合、または即時利用可能なデバイス機能で権限が必要な場合、デプロイメント・プロセスは、それらの権限をファイルに追加します。
表21-5 共有権限
| デバイス・アクセス | 権限 |
|---|---|
|
|
|
|
|
|
|
注意: 指定されたデプロイメント・プロファイルの最初のデプロイメント時に、MAFは、 |
表21-4に示されている<adfmf:deviceSMS>要素のマッピングと同様に、MAFはデプロイメント時に、次の要素をiOSおよびAndroid構成ファイルにマップします。
<adfmf:deviceCamera>
表21-6は、MAFによるプラットフォーム固有のファイルへの<adfmf:deviceCamera allowAccess="true" />のマッピングを示しています。
表21-6 <adfmf:deviceCamera>のプラットフォーム固有のファイルへのマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<key>Plugins</key>
<dict>
<key>Camera</key>
<string>CDVCamera</string>
<key>Capture</key>
<string>CDVCapture</string>
</dict>
|
<plugin name="Camera" value="org.apache.cordova.CameraLauncher"/> <plugin name="Capture" value="org.apache.cordova.Capture"/> |
<uses-permission android:name="android.permission.RECORD_AUDIO"/> <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> |
<adfmf:deviceContacts>
表21-7は、MAFによるプラットフォーム固有のファイルへの<adfmf:deviceContacts allowAccess="true" />のマッピングを示しています。
表21-7 プラットフォーム固有のファイルへの<adfmf:deviceContacts>のマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<key>Plugins</key>
<dict>
<key>Contacts</key>
<string>CDVContacts</string>
</dict>
|
<uses-permission android:name="android.permission.READ_CONTACTS"/> <uses-permission android:name="android.permission.WRITE_CONTACTS"/> <uses-permission android:name="android.permission.GET_ACCOUNTS"/> |
<uses-permission android:name="android.permission.READ_CONTACTS"/> <uses-permission android:name="android.permission.WRITE_CONTACTS"/> <uses-permission android:name="android.permission.GET_ACCOUNTS"/> |
<adfmf:deviceEmails>
表21-8は、MAFによるプラットフォーム固有のファイルへの<adfmf:deviceEmails allowAccess="true" />のマッピングを示しています。
表21-8 プラットフォーム固有のファイルへの<adfmf:deviceEmails>のマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<key>Plugins</key>
<dict>
<key>AdfmfEmail</key>
|
<plugin name="AdfmfEmail" value="oracle.adfmf.phonegap.AdfmfEmail"/> |
|
<adfmf:deviceNetwork>
表21-9は、MAFによるプラットフォーム固有のファイルへの<adfmf:deviceNetwork allowAccess="true" />のマッピングを示しています。
表21-9 プラットフォーム固有のファイルへの<adfmf:deviceNetwork>のマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<key>Plugins</key> <dict> <key>NetworkStatus</key> <string>CDVConnection</string> </dict> |
<plugin name="NetworkStatus" value="org.apache.cordova.NetworkManager"/> |
<uses-permission android:name="android.permission.INTERNET"/> <uses-permission android:name="android.permission.READ_PHONE_STATE"/> <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/> |
<adfmf:deviceFiles>
表21-10は、MAFによるプラットフォーム固有のファイルへの<adfmf:deviceFiles allowAccess="true" />のマッピングを示しています。
表21-10 プラットフォーム固有のファイルへの<adfmf:deviceFiles>のマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<key>Plugins</key>
<dict>
<key>File</key>
<string>CDVFile</string>
</dict>
<key>Plugins</key>
<dict>
<key>FileTransfer</key>
<string>CDVFileTransfer</string>
</dict>
|
<plugin name="File" value="org.apache.cordova.FileUtils"/> <plugin name="FileTransfer" value="org.apache.cordova.FileTransfer"/> <plugin name="Storage" value="org.apache.cordova.Storage"/> |
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/> |
<adfmf:deviceLocation>
表21-11は、MAFによるプラットフォーム固有のファイルへの<adfmf:deviceLocation allowAccess="true" />のマッピングを示しています。
表21-11 プラットフォーム固有のファイルへの<adfmf:deviceLocation>のマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<dict>
<key>Plugins</key>
<dict>
<key>Geolocation</key>
<string>CDVLocation</string>
<key>Compass</key>
<string>CDVLocation</string>
</dict>
</dict>
|
<plugin name="Geolocation" value="org.apache.cordova.GeoBroker"/> <plugin name="Compass" value="org.apache.cordova.CompassListener"/> |
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION"/> <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"/> <uses-permission android:name="android.permission.ACCESS_LOCATION_EXTRA_COMMANDS"/> |
<adfmf:devicePushNotifications>
表21-12は、MAFによるプラットフォーム固有のファイルへの<adfmf:deviceSMS allowAccess="true" />のマッピングを示しています。
表21-12 プラットフォーム固有のファイルへの<adfmf:devicePushNotifications>のマッピング
| cordova.plistファイルでの<key>へのマップ | config.xmlファイルでの<plugin name>へのマップ | AndroidManifest.xmlファイルでの権限へのマップ |
|---|---|---|
<key>Plugins</key>
<dict>
<key>PushPlugin</key>
<string>PushPlugin</string>
</dict>
|
<plugin name="PushPlugin" value="com.plugin.gcm.PushPlugin"/> |
該当するものはありません。 |
ユーザーが、保護されているコンテンツを含むアプリケーション機能からログアウトするとき、または制約によって制限されているときは、MAFはアプリケーション機能を終了せず、またユーザーはアプリケーション内でログイン状態を維持し、セキュアでないコンテンツおよび機能に匿名ユーザーとしてアクセスできます。MAFでは、制約を再初期化できるため、ユーザーは、同じアイデンティティを使用して、アプリケーションに繰り返しログインできます。また、MAFは、ユーザーに別のアイデンティティを使用したログインを許可することで、複数のアイデンティティでアクセスを共有できます。
Oracle Fusion Middleware Oracle Mobile Application FrameworkのJava APIリファレンスに示すとおり、AdfmfJavaUtilitiesのlogoutFeatureおよびlogoutメソッドにより、ユーザーはアプリケーションを起動した後、認証サーバーから明示的にログインおよびログアウトできます。さらに、ユーザーは、保護されているアプリケーション機能を呼び出した後、認証サーバーにログインできます。ユーザーは個々のアプリケーション機能からログアウトできますが、同じ接続で保護されているアプリケーション機能から同時にログアウトできます。
これらのメソッドでは、次のような操作を実行できます。
アプリケーション機能からログアウトするが、保護されていないコンテンツへのアクセスを継続する(つまり、MAFはアプリケーションを終了しない)。
ログイン・サーバーで認証する一方、アプリケーションで、保護されているそのコンテンツおよびUIコンポーネントを有効化する。
モバイル・アプリケーションまたはアプリケーション機能からログアウトし、別のアイデンティティを使用して再度ログインする。
モバイル・アプリケーションまたはアプリケーション機能からログアウトし、更新されたロールおよび権限を持つ同じアイデンティティを使用して再度ログインする。
現在の認証サーバーからログアウトできるようにするには、次のように、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メカニズム)を提供します。第3.2.2項「MAFアプリケーションを作成する場合の処理」に示すとおり、Oracle Enterprise Pack for Eclipseは、アプリケーション・リソースの「セキュリティ」フォルダ(users\workspaces\application name\resources\Security\cacertsにある)内にこのファイルを作成します。MAF cacertsファイルにより、既知の信頼できるソースからの一連の証明書がJVM 1.4に対して識別され、デプロイメントが可能になります。カスタム証明書を必要とするアプリケーションでは(RSA暗号化が使用されていない場合など)、アプリケーションをデプロイする前にプライベート証明書を追加する必要があります。
始める前に:
cacertsファイルおよびkeytoolユーティリティの使用方法については、Java SEテクニカル・ドキュメント(http://download.oracle.com/javase/index.html)を参照してください。
プライベート証明書を追加するには:
プライベート証明書を作成します。たとえば、new_certという証明書ファイルを作成します。
次のようにして、プライベート証明書をアプリケーションに追加します。
シードされたcacertsファイル(cp cacerts cacerts.org)のコピーを作成します。
Java SE keytoolユーティリティを使用して、cacertsファイルに証明書を追加します。例21-10は、new_certというcacertsファイルへの証明書の追加を示しています。
例21-10 keytoolユーティリティを使用した証明書の追加
keytool -importcert
-keystore cacerts
-file new_cert
-storepass changeit
-noprompt
例21-10は、単一の証明書の追加方法を示しています。各証明書に対して同じ手順を繰り返します。表21-13は、keytoolのオプションを示しています。
新しいcacertsファイルの内容を目で見て調べて、すべてのフィールドが正しいことを確認します。次のコマンドを使用します。
keytool -list -v -keystore cacerts | more
証明書が指定のホスト名に対するものであることを確認します。
|
注意: 証明書の共通名(CN)は、ホスト名と正確に一致している必要があります。 |
JVM 1.4が読み取れるようにするために、カスタマイズされた証明書ファイルはSecurityディレクトリ(users\workspaces\assembly project\lib\Security)に確実に配置してください。
アプリケーションをデプロイします。
|
注意: デプロイメント時、証明書ファイルが |
保護されているリソースにSSL経由でアクセスできることを確認します。
