| Oracle Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.3.0 E77213-01 |
|
 前 |
 次 |
| Oracle Enterprise Pack for Eclipse Oracle Mobile Application Framework (OEPE Edition)でのモバイル・アプリケーションの開発 リリース2.3.0 E77213-01 |
|
前 |
次 |
この章では、MAF内のセキュリティ・フレームワークの概要と、セキュリティが適用されるようにMAFアプリケーションを構成する方法について説明します。
この章には次の項が含まれます:
MAFは、保護されているアプリケーション機能がアクティブ化されたときに、ユーザーにログイン・ページを表示します。たとえば、アプリケーション機能がWebビュー内に表示されようとしているときやオペレーティング・システムがアプリケーションをフォアグラウンドに戻したときに、ユーザーにログイン・ページを表示します。MAFは、アプリケーション機能が認証サーバーによって保護されているときや、アプリケーション機能にユーザー・ロールまたはユーザー権限に基づいた制約が含まれているときに、アプリケーション機能へのアクセスにユーザー認証を必要とするかどうかを決定します。MAFは、ユーザーが有効な資格証明を入力した場合のみ、目的のWebビュー、UIコンポーネントまたはアプリケーション・ページをレンダリングします。
いずれかのアプリケーション機能にこれらの条件を設定すると、ユーザーがログインに成功しないとモバイル・アプリケーションにアクセスできないようにできる一方、保護されておらず、またアクセスに関連する制約も含んでいないデフォルトのアプリケーション機能を含めることで、保護されているアプリケーション機能と保護されていないアプリケーション機能の両方を含むモバイル・アプリケーションに、ユーザーがアクセスできるようにすることもできます。この状況では、ユーザーは認証せずにMAFアプリケーションにアクセスできます。デフォルトのアプリケーション機能は、保護されていないデータを表示することも、保護されているアプリケーション機能にアクセスする際にリモート・サーバーに対して認証することもできるこのような匿名ユーザーに対して、モバイル・アプリケーションの入口として機能します。次の方法により、保護されていないデフォルトのアプリケーション機能を指定できます。
デフォルトのアプリケーション機能を通じて公共の情報にアクセスすることを匿名ユーザーに許可する一方、認可されたユーザーのみが保護された情報にアクセスできるようにする。
ユーザーが、保護されているアプリケーション機能にアクセスする必要がある場合にのみ、ユーザーに認証を許可する。これ以外の場合、ユーザーは匿名ユーザーとしてモバイル・アプリケーションにアクセスするか、ログインして保護されている機能に移動できます。
アクセスを保護する必要がない場合に、保護されているアプリケーション機能からログアウトすることをユーザーに許可し、それにより権限のないユーザーが保護されているアプリケーション機能にアクセスすることを明示的に禁止する。
|
注意: アプリケーション・ログイン・プロセスはアプリケーションの初期化フローから切り離されるため、MAFは匿名ユーザーを有効化し、ユーザーは、認証資格証明を入力しなくても、匿名ユーザーとしてモバイル・アプリケーションを起動し、保護されていないアプリケーション機能にアクセスできます。このような場合、MAFは、権限が必要なUIコンポーネントを無効化して、ユーザーの操作を制限します。 |
詳細は、第29.6.1項「認証を要求するようにアプリケーション機能を設定する方法」および第22.2.4項「ユーザー制約とアクセス制御について」を参照してください。
MAFアプリケーションでは、デフォルト・ページまたはHTMLで記述されたカスタマイズ済のログイン・ページが使用されます。
特定のロールおよび権限を付与されたユーザーのみが、user.rolesまたはuser.privileges制約で定義されるアプリケーション機能にアクセスできます。ユーザーがこのようなアプリケーション機能にログインすると、アクセス制御サービス(ACS)として知られるWebサービスは、アプリケーション機能へのアクセス権を付与するユーザー・オブジェクトをユーザーに返します。ACSの詳細は、第29.5.19項「アクセス制御サービスに関する必知事項」を参照してください。
開発者は、デプロイメント時にMAFアプリケーションをコンテナ化するように選択できます。コンテナ化により、Oracle Mobile Security Suite (OMSS)で構成されたエンタープライズ・ネットワーキング・プラットフォームのセキュア・ネットワーキングおよびネットワーク・トンネリング機能をアプリケーションで利用できます。コンテナ化されたアプリケーションの配布は、Oracle Mobile Security Access Server (MSAS)コンポーネントのアプリケーション・カタログおよびSecure Workspaceコンテナ機能を使用して、OMSS管理者によって管理されます。ユーザーの認証は、対象の認証タイプに構成されたMSASによって実行されます。MAFアプリケーションおよびOMSSコンテナ化の開発の詳細は、第2.8項「エンタープライズ配布のためのMAFアプリケーションのコンテナ化」を参照してください。
エンド・ユーザーの視点からは、ログイン・プロセスは次のようなものになります。
ユーザーが保護されたアプリケーション機能にアクセスしようとすると、常に、図29-1に示すログイン・ページのWebビューがMAFによって表示されます。保護されているアプリケーション機能がデフォルトである場合、ユーザーがモバイル・アプリケーションを起動すると、MAFによってユーザーにログイン・ページが表示されます。
|
注意: 第29.6.4.2項「カスタム・ログイン・ページ」で説明されているとおり、MAFでは、デフォルトのログイン・ページが提供されるだけでなく、カスタム・ログイン・ページの使用もサポートされています。 |
ユーザーがユーザー名とパスワードを入力し、「サインイン」をクリックします。
|
注意: MAFでは、同じアプリケーションに対して複数のユーザーを許可します。ユーザーは、前のユーザーがログアウトした後、アプリケーションに自由にログインできます。 |
ユーザー名とパスワードが検証されると、MAFによって、目的のWebビュー、ページまたはユーザー・インタフェース・コンポーネントが表示されます。
MAFは、ユーザーが正常にログインするまで、ユーザー名とパスワードの入力を求めます。ユーザーがログインできない場合、別のアプリケーション機能に移動することのみが可能です。
|
注意: アプリケーション機能が最後にアクティブ化されて以降、事前定義された時間が経過すると、認証はタイムアウトになります。MAFでは、認証サーバーへの接続を使用するアプリケーション機能のいずれかがアクティブ化されたときのみ、アイドル・タイムアウトのタイマーの期限が更新されます。 |
MAFアプリケーションでは、リモート・ログイン・サーバー(Oracle ADF Fusion Webアプリケーションによって使用されるOracle Access Managerアイデンティティ・サーバーなど)、またはユーザーのデバイス上に存在するローカル資格証明ストアに対するユーザー資格証明の検証が必要になる場合があります。ローカルおよびリモートの接続モードをサポートするために、MAFは次の認証プロトコルをサポートしています。
HTTP基本
OAuth
Web SSO
|
注意: 現在、ユニバーサルWindowsプラットフォームにデプロイしたMAFアプリケーションは、HTTP基本のみをサポートしています。 |
デフォルトでは、MAFアプリケーション・ユーザーの認証は、デザインタイムに選択された認証プロトコルに関係なく、リモート・ログイン・サーバーに対して行われます。開発者は、基本認証を使用してローカル認証を有効にする場合にアプリケーションを構成できます。ただし、最初はローカル資格証明ストアに資格証明が伝播されていないため、保護されているアプリケーション機能にアクセスするためのログインでは、リモート・ログイン・サーバーに対する認証が必要です。リモート認証に成功すると、その後、認証サーバーのユーザーのログイン資格証明をデバイス上に格納するローカル資格証明ストアを使用できるようになります。そのため、ユーザーが同じアプリケーション・セッション内(つまり、アプリケーション実行のライフサイクル内)でサーバーに対して認証されると、MAFは認証コンテキストをローカルに格納し、以降の認証の試行でそれを使用できるようになります。この場合、ローカルの認証コンテキストで問題なくユーザーを認証できる場合、MAFでは、ログイン・サーバーに接続されません。最初の認証では認証サーバーへの接続が必要ですが、ローカル認証を使用したアプリケーションのためにこのサーバーに頻繁にアクセスする必要はありません。
|
ヒント: ローカル資格証明ストアに対する認証は、リモート・ログイン・サーバーに対する認証よりも高速に実行できますが、リモート接続のみをサポートしているOAuthまたはWeb SSO認証プロトコルを使用した認証をお薦めします。 |
表29-1に、MAFアプリケーションのログイン構成オプションをまとめます。接続モードは、選択した認証プロトコルによって異なります。
表29-1 MAFの接続モードおよびサポートされている認証プロトコル
| 接続モード | サポートされているプロトコル | モードの説明 |
|---|---|---|
|
|
|
ローカルに格納されている資格証明がデバイスで利用できない場合にのみ、アプリケーションでは、リモート・ログイン・サーバーに対する認証が必要です。初回ログインは、常にリモート・ログイン・サーバーに対して行われます。初回ログインに成功すると、MAFは、資格証明をデバイスの資格証明ストア内にローカルに保持します。アプリケーション機能への以降のアクセスでは、それらの資格証明が使用されます。第29.5.17項「Webサービス・セキュリティに関する必知事項」も参照してください。 |
|
|
|
アプリケーションで、Oracle Access Manager (OAM)アイデンティティ・サーバーなどのリモート・ログイン・サーバーまたは保護されているWebアプリケーションに対する認証が必要です。ユーザーがログインするたびに、リモート・サーバーに対する認証が求められます。デバイスがサーバーに接続できない場合、ユーザーは、前回は正常に認証されていても、保護されたMAF機能にアクセスできません。 |
|
|
|
デバイスでローカル資格証明が利用可能でも、ネットワーク接続が利用できる場合は、アプリケーションでは、リモート・ログイン・サーバーに対する認証が必要です。ネットワーク接続がないためにログイン・サーバーにアクセスできない場合にのみ、デバイスのローカル資格証明が使用されます。 |
MAFアプリケーションのコンテナ化に伴う認証プロセスの変更点の詳細は、第29.4項「コンテナ化されたMAFアプリケーションの認証プロセスの概要」を参照してください。
MAFアプリケーションを開発する場合は、ログイン接続を定義してセキュア機能を開発およびテストする必要があります。テスト中、保護されたリソースにアクセスする前に、MAFログイン・ページが認証に使用されます。デプロイメント時には、MAFアプリケーションをコンテナ化して、Oracle Mobile Security Suite (OMSS)で構成されたエンタープライズ・ネットワーキング・プラットフォームのセキュア・ネットワーキングおよびネットワーク・トンネリング機能を利用できるため、モバイルVPNは不要になります。
コンテナ化されたMAFアプリケーションのデプロイメント後に、企業ファイアウォールの背後にあるバックエンド・リソースへのアクセスでは、OMSSのコンポーネントであるMobile Security Access Server (MSAS)を利用して、モバイル・デバイスから企業リソースへのトラフィックを保護する集中アクセス・ポイントを提供します。この場合、ユーザーの最初の認証で使用するために認証エンドポイントを実行するようにMSASインスタンスが構成されます。
ユーザー認証は、MSASによって登録済MAFアプリケーションに提供されるコンテナのシングル・サインオン(SSO)統合によって処理されます。MAFアプリケーションがMSASと通信できるようにするには、ユーザーは、MSASインスタンスに構成されている認証のタイプのSecure Workspaceアプリケーションをインストールおよび登録する必要があります。次に、保護されたリソースへのアクセスをユーザーが試みると、MAFログイン・ページが非表示になり、ユーザーのモバイル・デバイスのSecure Workspaceアプリケーションから独自のログインがMSASに表示されます。
|
注意: MSASによる認証を有効にし、AppTunnelを利用するには、MAFアプリケーションで定義されるログインURLまたは認証エンドポイントをプロキシするようにMSASインスタンスを構成する必要があります。MAFログイン接続のためのMSASの構成の詳細は、第29.5.11項「ログイン接続およびコンテナ化されたMAFアプリケーションへのアクセスに関する必知事項」を参照してください。 |
MSAS AppTunnelを使用してバックエンド・リソース・リクエストがプロキシされるかどうかは、MAFアプリケーションおよびSecure Workspaceアプリケーションで使用される、MSASで生成されるのプロキシ自動構成ファイルによって決定されます。AppTunnelは、コンテナ化されたMAFアプリケーションへのセキュアなアクセスを提供する各Secure Workspaceアプリケーションから相互認証されたSSLトンネルです。AppTunnelでは、遷移中のすべてのデータを暗号化し、デバイス・レベルのモバイルVPNに接続中のユーザーのモバイル・デバイス上の悪意のあるアプリケーションから保護します。
コンテナ化されたMAFアプリケーションのOMSSサポートの概要は、第2.8項「エンタープライズ配布のためのMAFアプリケーションのコンテナ化」を参照してください。
セキュリティが適用されるアプリケーション機能のアプリケーション・ログイン・サーバーに1つ以上の接続を定義する必要があります。アプリケーション・ログイン・サーバーへの定義済の接続が存在しないと、無効な構成になります。その結果、アプリケーションは正しく機能しません。
図29-2に示すとおり、モバイル・ログイン・サーバー接続ウィザードを使用して接続タイプを選択できますが、接続タイプによっては、ローカルおよびリモート認証(ハイブリッド)の両方を有効化できます。アプリケーション要件によっては、次の認証プロトコルをサポートするサーバーへの接続を構成できます。
HTTP基本
OAuth
Web SSO
|
注意: OAuthまたはWeb SSO接続タイプを使用したログイン・サーバーへの接続を構成することをお薦めします。OAuthおよびWeb SSOは、リモート・ログイン・サーバーに対する認証を要求し、ユーザーがローカル資格証明ストアからデバイスで認証することを許可しません。 |
ログイン・サーバー接続を作成するには:
プロジェクト・エクスプローラで、アセンブリ・プロジェクトを展開してMAFを展開し、MAFアプリケーション・エディタをダブルクリックします。
|
注意: MAFアプリケーション・エディタを使用すると、アプリケーション・ログイン・サーバー接続を定義し、それをデフォルトのアプリケーション機能に割り当てることができます(デフォルトのアプリケーション機能が保護されている場合)。この場合、アプリケーション・ログイン・サーバーに指定されている資格証明は、アクセス制御サービス(ACS)を介してユーザー、ロールおよびサービスを検索するためにも使用されます。第29.5.19項「アクセス制御サービスに関する必知事項」も参照してください。 |
エディタで、アウトラインの「セキュリティ」を選択し、次のいずれかの隣にある「作成」をクリックします。
デフォルト・ログイン・サーバー
「ログイン・ページ」
図29-2に示すとおり、モバイル・ログイン・サーバー接続ウィザードで、新規接続の作成を選択し、認証サーバー・タイプを選択します。接続タイプについては、次の項で説明します。
図29-3に示すように、モバイル・ログイン・サーバー接続ウィザードのオプション・ページを使用して、1つのアプリケーションに異なる組織(テナント)で共有可能な1つのホスト・アプリケーション機能が含まれ、それが特定のテナントによって所有されているように見える、マルチテナントの概念がサポートされるMAFアプリケーション接続を作成できます。HTTP基本認証プロトコルをサポートするサーバーへのマルチテナント対応接続を構成できます。
図29-4に示すように、マルチテナント対応接続が定義されたMAFアプリケーションによって表示されるデフォルトのログイン・ページでは、ユーザーがHTTPリクエストのテナント値を伝播するために、ドメインIDを入力するように求められます。
マルチテナント対応ログイン・サーバーを作成する手順:
モバイル・ログイン・サーバー接続ウィザードで、マルチテナント・ログインをサポートする認証サーバー・タイプを選択します。
オプションのページで、「マルチテナント対応」を選択して、認証サーバーで予想されるテナント・ヘッダー名を入力します。たとえば、ログイン中にエンド・ユーザーにテナントIDを求めるには、マルチテナント・ヘッダー名(X-ID-TENANT-NAME)を入力します。図29-4に示すように、デフォルトのログイン・ページによって、ドメイン名の入力がユーザーに求められます。
オプションで、認証の実行に必要な追加のカスタム・ヘッダーの名前を入力します。これらは、マルチテナント・ヘッダーに加えて構成される場合があります。第29.5.14章「カスタム・ヘッダーに関する必知事項」も参照してください。
カスタム・ヘッダーのヘッダー値がわかっている場合は、値を入力します。指定されたカスタム・ヘッダーの値がログイン中にオーバーライドされる場合は、対応する「値」フィールドを空のままにします。実行時にヘッダー値を指定する場合は、OverrideConnectionHandler APIを使用して値をプログラムで設定する必要があります。APIを使用してヘッダーを構成する方法の詳細は、第29.5.21項「認証前にログイン資格証明をプログラムで構成する方法」を参照してください。
図29-5に示すとおり、「モバイル・ログイン・サーバー」ウィザードで、「HTTP基本」認証サーバー・タイプを選択すると、基本認証の接続を構成できます。
基本認証を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、認証サーバー・タイプとして「HTTP基本」を選択します。「次へ」をクリックします。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第29.5.1項「MAFログイン接続の作成方法」を参照してください。
「一般オプション」ページで、次の項目を定義します。
「名前」: 接続の名前を入力します。
認証モード: 表29-1の説明に従って、認証のタイプを選択します。
「アイドル・タイムアウト」: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。
|
注意: MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を行いますが、セッション・タイムアウト後にこの認証を行うことはありません。 |
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
「HTTPリクエストに基本認証ヘッダーを含めます」: このオプションを選択すると、MAFでは、Webビューから作成したHTTPリクエストに基本認証ヘッダーを追加できます。基本認証は、MAFが使用するデフォルトのリクエスト・メソッドです。基本認証ヘッダーは、ログイン接続タイプがHTTP基本である場合にのみ挿入されます。第29.5.16項「基本認証ヘッダーの挿入に関する必知事項」も参照してください。
レルム: ユーザー名とパスワードの認証レルムを定義すると、OEPEによって、再利用可能な定義済の<realm>要素がconnections.xmlファイルに移入されます。詳細は、第29.5.16項「基本認証ヘッダーの挿入に関する必知事項」を参照してください。同じレルムの複数のページで資格証明を共有します。資格証明がMy Realmというレルムのページで動作する場合、同じユーザー名とパスワードの組合せは、同じレルムの別のページでも動作します。
「次へ」をクリックします。
図29-6に示すとおり、「HTTP基本オプション」ページで、次の項目を構成します。
ログインURL: 認証サーバーのログインURLを入力します。
ログアウトURL: 認証サーバーのログアウトURLを入力します。
「マルチテナント対応」: MAFでは、モバイル・アプリケーションは、様々な組織(テナント)が共有するホスト・アプリケーション機能を含みますが、その機能は特定のテナントによって所有されているかのように見えるマルチテナントの概念をサポートしています。このオプションを選択すると、モバイル・アプリケーション接続にマルチテナント対応を定義できます。第29.5.9項「マルチテナント対応接続を作成する場合の処理」も参照してください。
マルチテナント・ヘッダー名: 「マルチテナント対応」が選択されている場合、ヘッダー名を指定します。
カスタム認可ヘッダー: 認証の実行に必要なカスタム・ヘッダーの名前を入力します。第29.5.14章「カスタム・ヘッダーに関する必知事項」も参照してください。
カスタム・ヘッダーのヘッダー値がわかっている場合は、値を入力します。指定されたカスタム・ヘッダーの値がログイン中にオーバーライドされる場合は、対応する「値」フィールドを空のままにします。実行時にヘッダー値を指定する場合は、OverrideConnectionHandler APIを使用して値をプログラムで設定する必要があります。APIを使用してヘッダーを構成する方法の詳細は、第29.5.21項「認証前にログイン資格証明をプログラムで構成する方法」を参照してください。
「テスト」をクリックして、認証サーバーへの接続をテストします。結果はウィザードに表示されます。
第29.5.7項「ログイン資格証明の格納方法」に示すとおり、「次へ」をクリックして、「ログイン・オプション」ページを開いて、パラメータを構成します。
第29.5.18項「アクセス制御の構成方法」に示すとおり、「次へ」をクリックして、「認可オプション」ページを開いて、パラメータを構成します。
「終了」をクリックして、接続を作成します。
図29-7に示すように、「MAFログイン接続の作成」ダイアログを使用して、サードパーティ・アプリケーション(クライアント)がリモート・サーバーに格納されている保護されたデータまたはサービスへの制限付きアクセスを取得する方法を構成できます。Oracle Mobile and Socialサーバーが提供するリライイング・パーティ認証を使用すると、アプリケーションで、サードパーティOAuthプロバイダに対する認証を行うことができます。Oracle Web Services Manager (OWSM) Lite MobileのADFアプリケーション・エージェントは、Webサービス・コールのセキュリティ・ヘッダーにCookieを挿入します。
始める前に:
OM_PROP_OAUTH_OAUTH20_SERVERプロパティ・キーを使用するようにサーバーを構成します。
OAuthサーバーで認証を構成するには:
モバイル・ログイン・サーバー接続ウィザードで、認証サーバー・タイプとして「OAuth2」を選択し、「次へ」をクリックします。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第29.5.1項「MAFログイン接続の作成方法」を参照してください。
「一般オプション」ページで、次の項目を定義します。
「接続名」: 接続の名前を入力します。
認証モード: 表29-1の説明に従って、認証のタイプを選択します。
「アイドル・タイムアウト」: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。
|
注意: MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を行いますが、セッション・タイムアウト後にこの認証を行うことはありません。 |
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
「RESTコールにログイン・サーバーを含める」: リモート認証を使用したアプリケーション機能では、このオプションを選択すると、ログイン・サーバー生成ユーザー・セッション・コードを通じてログイン・サーバーに格納される、認可されたユーザー・データを取得するためにREST Webサービスを有効化できます。
|
注意: CookieをREST Webサービス・コールに挿入できるようにするには、アプリケーション機能にリモート認証が使用されている必要があり(MAFは、ユーザー資格証明をローカルに保存するアプリケーション機能に対するCookieの挿入をサポートしていません)、また「ログインURL」に入力されたドメインが、REST Webサービス・エンド・ポイントと一致する必要があります。 |
「HTTPリクエストに基本認証ヘッダーを含めます」: このオプションを選択すると、MAFでは、Webビューから作成したHTTPリクエストに基本認証ヘッダーを追加できます。基本認証は、MAFが使用するデフォルトのリクエスト・メソッドです。基本認証ヘッダーは、ログイン接続タイプがHTTP基本である場合にのみ挿入されます。第29.5.16項「基本認証ヘッダーの挿入に関する必知事項」も参照してください。
第29.5.7項「ログイン資格証明の格納方法」に示すとおり、「次へ」をクリックして、パラメータを構成できる「ログイン・オプション」ページを開きます。
第29.5.18項「アクセス制御の構成方法」に示すとおり、「次へ」をクリックして、パラメータを構成できる「認可オプション」ページを開きます。
図29-8に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードを使用して、クロスドメイン・シングル・サインオンを構成できます。
Web SSOサーバーで認証を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、認証サーバー・タイプとして「Webシングル・サインオン」を選択し、「次へ」をクリックします。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第29.5.1項「MAFログイン接続の作成方法」を参照してください。
「一般オプション」ページで、図29-9に示すとおり、次の項目を構成します。
「接続名」: 接続の名前を入力します。
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
「RESTコールにログイン・サーバーを含める」: リモート認証を使用したアプリケーション機能では、このオプションを選択すると、ログイン・サーバー生成ユーザー・セッション・コードを通じてログイン・サーバーに格納される、認可されたユーザー・データを取得するためにREST Webサービスを有効化できます。
「次へ」をクリックします。
「Webシングル・サインオン・オプション」ページで、成功したログインと失敗したログインを有効化するURLを構成します。
をクリックしてURLをテストできます。
第29.5.18項「アクセス制御の構成方法」に示すとおり、「次へ」をクリックして、「認可オプション」ページで、パラメータを構成します。
AdfmfJavaUtilitiesクラスでは、overrideConnectionPropertyおよびupdateSecurityConfigWithURLParametersメソッドが提供され、アプリケーション開発者は、すでに存在する接続の接続属性の定義または再定義に使用できます。この接続属性は、プレースホルダ(「MAFログイン接続の作成」ダイアログで「実行時に値を指定」を選択する場合)、または完全に作成された接続定義のいずれかです。両方のメソッドは、これもまたAdfmfJavaUtilitiesクラスによって提供される、clearSecurityConfigOverridesおよびupdateApplicationInformation APIと連携して起動する必要があります。
updateSecurityConfigWithURLParametersメソッドは、認証のみに必要なパラメータを更新します。connections.xml内で接続を指定する追加パラメータは、updateSecurityConfigWithURLParametersメソッドを使用して更新できません。updateSecurityConfigWithURLParametersですべてのパラメータを更新できるのと同様に、overrideConnectionPropertyを使用してすべての非認証パラメータを更新します。
|
注意: 一般的なタイミングは、アプリケーション・ライフサイクル・リスナー内でstart()メソッド実装にAdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIをコールします。機能ライフサイクル・リスナー内からこのメソッドをコールしないでください。 |
configUrlParamパラメータに関連付けられた接続属性を更新するには、次の例に示すように、updatedSecurityConfigWithURLParametersメソッドを他のメソッドと組み合せてコールします。
AdfmfJavaUtilities.clearSecurityConfigOverrides(loginConnectionName); AdfmfJavaUtilities.updateSecurityConfigWithURLParameters(configUrlParam, key, message, showConfirmation); // Final step to apply the changes AdfmfJavaUtilities.updateApplicationInformation(false);
keyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして設定されます。その後の更新など、その構成に対するすべての参照にこのkeyパラメータを使用します。MAFが接続の既存の属性に対する接続構成の変更を検出すると、trueに設定されたshowConfirmationパラメータでメソッドを呼び出して、MAFで確認プロンプトをエンド・ユーザーに表示できます。
configUrlParamパラメータに渡す文字列の値は、UTF-8エンコードで、次のように書式設定する必要があります。
String parameterString = "http://settings?" + "&<Parameter Name1>::=<Parameter Value1>" + "&<Parameter Name2>::=<Parameter Value2>" + ... "&<Parameter NameN>::=<Parameter ValueN>";
たとえば、configUrlParamパラメータに次の値を渡します。
http://settings?AuthServerType::=HTTPBasicAuthentication &ApplicationName::=Approvals &LoginURL::=http://hostname.com:8008/OA_HTML/RF.jsp?function_id=mLogin &LogoutURL::=http://hostname.com:8008/OA_HTML/RF.jsp?function_id=mLogout &SessionTimeOutValue::=28800 &IdleTimeOutValue::=7200 &CryptoScheme::=PlainText
URLは、次のように作成する必要があります。
http://settings?AuthServerType::=HTTPBasicAuthentication&ApplicationName::=Approvals&LoginURL::=http%3A%2F%2Fhostname.com%3A8008%2FOA_HTML%2FRF.jsp%3Ffunction_ id%3DmLogin&LogoutURL::=http%3A%2F%2Fhostname.com%3A8008%2FOA_HTML%2FRF.jsp%3Ffunction_id%3DmLogout&SessionTimeOutValue::=28800&IdleTimeOutValue::=7200&CryptoS cheme::=PlainText
updateSecurityConfigWithURLParametersおよびoverrideConnectionPropertyメソッドについては、さらに次の点に注意してください。
overrideConnectionPropertyでは、MAFアプリケーションが次にそのログイン接続を使用するまで構成の変更が永続化されないのに対し、updateSecurityConfigWithURLParametersメソッドでは、即時に新しい構成が永続化されます。たとえば、エンド・ユーザーがログイン接続によって保護されている機能に移動すると、MAFによってログイン・ビューが表示されます。
overrideConnectionPropertyを使用して接続参照内の任意のトップ・レベルのプロパティを再構成でき、再構成できる接続参照はconnections.xmlファイル内のログイン接続に限定されません。updateSecurityConfigWithURLParametersメソッドは、ログイン接続の更新にのみ使用できます。
updateSecurityConfigWithURLParametersのコールがそれ以前のupdateSecurityConfigWithURLParametersのコールを再構成し、その結果として、新しいログインURLのたびにupdateSecurityConfigWithURLParametersがコールされるのに対し、overrideConnectionPropertyのコールは累積されます。次の例は、一連のoverrideConnectionPropertyコールで、MyLoginConnectionという名前の接続のlogin、logoutおよびaccessControlプロパティの値をオーバーライドする方法を示しています。
AdfmfJavaUtilities.clearSecurityConfigOverrides("MyLoginConnection");
AdfmfJavaUtilities.overrideConnectionProperty("MyLoginConnection", "login", "url", newLoginUrl);
AdfmfJavaUtilities.overrideConnectionProperty("MyLoginConnection", "logout", "url", newLogoutUrl);
AdfmfJavaUtilities.overrideConnectionProperty("MyLoginConnection", "accessControl", "url", newAccessControlUrl);
AdfmfJavaUtilities.updateApplicationInformation(false);
overrideConnectionProperty (String node)の2番目のパラメータの値は、connections.xmlファイルで使用されるパラメータ名です。たとえば、次の接続を更新するには:
<Reference name="remotePage" className="oracle.adf.model.connection.url.HttpURLConnection" xmlns="">
<Factory className="oracle.adf.model.connection.url.URLConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="remotePage">
<Contents>
<urlconnection name=" remotePage_urlconnectionName " url="http://www.google.com"/>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
URLを変更するoverrideConnectionPropertyを次のようにコールします。
overrideConnectionProperty("remotePage", "urlconnection", "url", "http://www.oracle.com");
これは、updateSecurityConfigWithURLParametersと同じパラメータ名ではありません。updateSecurityConfigWithURLParametersを使用する場合は、前述のURL作成パターンに従います。connections.xmlファイルの内容に関する知識は必要ありません。
oracle.adfmf.framework.api.AdfmfJavaUtilitiesクラスおよびconfigUrlParamパラメータの使用方法の詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。
overrideConnectionPropertyを使用して接続プロパティ値をオーバーライドする方法の詳細は、第29.5.21項「認証前にログイン資格証明をプログラムで構成する方法」を参照してください。ConfigServiceDemoサンプル・アプリケーションのConfigServiceHandler.javaは、overrideConnectionPropertyメソッドを起動して複数の接続プロパティをオーバーライドする方法を示しています。ConfigServiceDemoサンプル・アプリケーションの詳細は、付録E「サンプルのMAFアプリケーション」を参照してください。
セキュリティが重要でない場合、MAFはユーザー資格証明の格納をサポートしますが、これは、ログイン・サーバーにリプレイできるか、またはユーザーをローカルで認証するために使用できます(ログイン接続に定義されているモードによって異なります)。資格証明を格納すると、ユーザーはログインしないでMAFアプリケーションにアクセスできるようになるため、ユーザーの操作性が向上します。IDM Mobile SDKを使用すると、MAFは次のモードをサポートできます。
ユーザー名を記憶 - MAFは、ユーザー名をキャッシュし、ログイン・ページの「ユーザー名」フィールドを移入します。ユーザーがパスワードを入力し、ログイン・ボタンをタップして確認すると、MAFはそれらの資格証明を認証サーバーにリプレイします。
資格証明を記憶: MAFはユーザー資格証明をキャッシュし、ログイン・ページのユーザー名フィールドとパスワード・フィールドに移入します。ユーザーがログイン・ボタンをタップして、これらの資格証明を確認すると、MAFはそれらを認証サーバーにリプレイします。
自動ログイン - MAFはユーザー資格証明をキャッシュし、以降の認証時にそれらを認証サーバーにリプレイします。このモードでは、ユーザーは、MAFによってユーザーに資格証明を入力または確認するよう求められずにアプリケーションを起動できます。ただし、MAFは、新しいアプリケーション・セッションが開始されたことをユーザーに通知できます。
|
注意: ユーザーは、MAFが資格証明を格納するかどうかを決定できます。 |
図29-11に示すとおり、「モバイル・ログイン・サーバー接続」ウィザードの「ログイン・オプション」ページを使用して、資格証明の格納オプションを選択できます。資格証明オプションを使用すると、オプションを使用したログイン・ページが移入され、ユーザー名とパスワードが記憶されるため、オプションデバイスが複数のエンド・ユーザーによって共有されている場合は選択しないでください。
MAFでは、connections.xmlファイル内のすべての接続情報が集約されます(このファイルはadfおよびMETA-INFノードの下のアセンブリ・プロジェクトにあります)。次の例に示すこのファイルは、アプリケーションにバンドルするか、構成サービスにホストできます。後者の場合、MAFは、アプリケーションが起動されるたびに、更新済の構成情報があるかどうかをチェックします。
|
注意: MAFアプリケーション認証の要件として、OEPEはadfCredentialStoreKey属性をログイン接続参照と同じ名前(例: Connection_1)に設定します。connections.xmlファイルのadfCredentialStoreKey属性またはログイン接続名を編集する場合は、値を互いに同じに設定してください。同じ値を維持しないと、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>
「マルチテナント対応」オプションを有効にしてモバイル・ログイン・サーバー接続ウィザードを完了すると、MAFは、connections.xmlファイルに、trueに設定された<isMultiTenantAware>要素を移入します。マルチテナント接続では、ユーザー名はテナント名とユーザー名の組合せです。
接続がマルチテナント対応である場合、ログイン・ページは、JavaScriptユーティリティを使用して認識します。ログイン・ページでそのような接続が検出されると、追加フィールドが表示され、ユーザーは、「MAFログイン接続の作成」(図29-3を参照)で構成したテナント名をそのフィールドに入力する必要があります。ログイン(正しいテナントIDの入力を含む)が成功すると、MAFは、ローカル資格証明ストアにテナントIDを格納します。
保護されたMAF機能へのアクセス権を付与するためのログインURLをconnections.xmlファイルまたはプログラムを使用して定義する場合、ログインURLはmydocument.txtのようなファイル・リソースを指すことはできません。このログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースが使用されていると、MAFアプリケーションがハングするかログインに失敗して、ユーザーが保護されたMAF機能にアクセスできない場合があります。
Oracle Mobile Security Suite (OMSS) AppTunnel機能を使用して企業のリソースにアクセスするには、MAFアプリケーションによって使用されるURIまたはエンドポイントをプロキシしてリソースにアクセスするように、Mobile Security Access Server (MSAS)インスタンスを構成する必要があります。詳細は、『Oracle Mobile Security Access Serverの管理』の「Mobile Security Access Serverアプリケーションの管理」および「Mobile Security Access Serverインスタンスの構成」を参照してください。
HTTP基本認証はOMSSによってサポートされますが、MAFログイン・ページは、OMSS認証プロセスによって再度表示されるため、ユーザーは2回認証する必要があります。
コンテナ化されたMAFアプリケーションでの認証の詳細は、第29.4項「コンテナ化されたMAFアプリケーションの認証プロセスの概要」を参照してください。
ローカルおよびハイブリッド・ログイン接続モードでは、リモート接続と同様、ユーザーはアプリケーション・ライフサイクル内で任意の数のIDを使用して、ログインおよびログアウトできます。ログイン接続を定義してこれらの接続モードを使用するとき、現在のセッション・タイムアウト期間内に、保護されているアプリケーション機能にすでにログイン済である場合は、ユーザーは、ローカル資格証明ストアを使用して保護されているアプリケーション機能に再びログインできます。この場合、明示的にログアウトしたユーザーまたはアイドル・タイムアウトが期限切れになっているためにログアウトされたユーザーは、保護されているアプリケーション機能(またはアプリケーション機能を保護するログイン・サーバーによって保護されているその他のアプリケーション機能)に再びログインできます。
|
注意: ローカル接続とハイブリッド接続は、基本認証でのみ使用可能です。OAuthおよびFederate SSOはリモート認証を使用するため、認証が成功しない場合、アプリケーション・ユーザーはアプリケーションに再びログインできません。 |
MAFアプリケーションを移行する場合、maf-feature.xmlで定義されている認証モード(<adfmf:feature id="feature1" name="feature1" credentials="remote">など)が、connections.xmlファイルのauthenticationMode属性で定義されていることを確認する必要があります。
connections.xmlファイルのauthenticationMode属性は、remoteまたはlocalとしてのみ定義できるため、none (<adfmf:feature id="feature1" name="feature1" credentials="none">)の値を移行しないでください(移行すると、デプロイメントが失敗します)。
カスタム・ヘッダーを定義して「MAFログイン接続の作成」ダイアログへの入力を完了すると、MAFは、connections.xmlファイルに、customAuthHeaders要素および各headerサブ要素を移入します。
カスタム・ヘッダーの値を実行時に指定すると、MAFアプリケーションはoracle.adfmf.framework.api.AdfmfJavaUtilitiesクラスのOverrideConnectionHandler APIを使用してヘッダー値を構成できます。oracle.adfmf.framework.api.AdfmfAuthConnectionクラスは、connection.xml XML要素がオーバーライドされている場合に、それらの要素にアクセスして最新の値を取得するための便利な方法です。第29.5.21項「認証前にログイン資格証明をプログラムで構成する方法」を参照してください。
ログイン(正しいヘッダー値の入力を含む)に成功すると、MAFはヘッダーの詳細をローカルの資格証明ストアに格納するため、HTTPリクエスト時に、セキュアなコール(RESTサービスに対するコールなど)にカスタム・ヘッダーを含めることができます。
ユーザーがローカルで認証されると、MAFは、モバイル・アプリケーションがREST Webサービスをコールするときに、ログイン・サーバーに対してユーザーをサイレントに認証します。ユーザーの資格証明が認証されると、MAFは、REST Webサービスに対してアプリケーションのリクエストを実行します。REST Webサービスが401ステータス・コードを返した場合(未許可)、MAFは、ユーザーにもう一度認証するよう求めます。REST Webサービスが302コードを返した場合(見つかったか一時的に移動されている)、MAFは、ログイン・サーバーをチェックして、ユーザーが認証されているか確認します。その場合は、コードが302リダイレクトとして処理されます。
ユーザーがログイン・サーバーに対して認証されていない場合、MAFは、ユーザーにもう一度認証するよう求めます。302ステータス・コードを返した場合、ログイン・サーバーは、ユーザーに独自のWebページを使用して認証するよう求めることもあります。このような場合、MAFはリダイレクションをサポートしていないため、かわりにユーザーにもう一度MAFログイン・ページを使用してログインするよう求めます。
MAFでは、Webビューから発行されたHTTPリクエストに基本認証ヘッダーを挿入することで、アプリケーション機能からセキュア・リソースにアクセスできます。これは、リモートのWebリソースが基本認証によって保護されており、認証に対してCookieが十分でないか、サーバーがCookieをまったく受け付けない状況に便利です。デプロイメント時に判明している場合は、「MAFログイン接続の作成」ダイアログの「認可」タブの「レルム」入力フィールドにリクエスト・レルムを指定します。デプロイメント時に判明していない場合、実行時にAdfmfJavaUtilities.overrideConnectionPropertyを使用してリクエスト・レルムを変更できます。
次の例は、「レルム」入力フィールド(realm要素)に値を指定する場合の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"/>
<userObjectFilter/>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
</References>
Webサービスでは、ログイン・ページはなく、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービス・コールのヘッダーに資格証明が挿入されます。Webサービスは、ローカルに格納されている資格証明(ユーザーによる認証サーバーへの最初のログインの成功後、MAFによって保持されている資格証明)を使用してアプリケーション・データにアクセスします。
ローカル資格証明ストアの名前は、ログイン・サーバー接続のadfCredentialStoreKey属性によって反映されます(第29.5.8項「モバイル・アプリケーション作成時の処理」の例のadfCredentialStoreKey="Connection_1"など)。Webサービスがこの資格証明ストアを使用できるようにするには、REST Webサービス接続のadfCredentialStoreKey属性に対して定義されている名前が、ログイン・サーバーのadfCredentialStoreKey属性に対して定義されている名前と一致する必要があります。connections.xmlファイルのadfCredentialStoreKey属性またはログイン接続名を編集する場合は、値を互いに同じに設定してください。同じ値を維持しないと、MAF実行時例外が発生します。
|
注意: connections.xmlファイルの概要エディタは存在しないため、ソース・エディタを使用して、<Reference>要素のadfcredentialStoreKey属性をログイン・サーバー接続のadfCredentialStoreKey属性用に構成されている名前で更新できます。 |
詳細は、第15.3.4項「資格証明の挿入に関する必知事項」を参照してください。
アクセス制御サービス(ACS)は、JSONを使用したRESTful Webサービスであり、オプションでMAFアプリケーションとは別の外部サーバー上にデプロイすることができます。通常は、アプリケーション機能に保護されたコンポーネントが含まれている場合に、ユーザーが単一のHTTP POSTメッセージを介して自身のユーザー・ロールと権限をダウンロードできるよう、MAFアプリケーションにACSサービスを提供します。このサービスをアプリケーションに提供する場合は、ACSサービスを実装してホストする必要があります(MAでは、このサービスは提供されません)。図29-12は、モバイル・ログイン・サーバー接続ウィザードの「認可」ページを示したもので、このページを使用して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は、取得されたユーザー・ロールと権限に照らして各アプリケーション用に構成されている制約を評価し、関連付けられているすべての制約を満たすユーザーのみがアプリケーション機能を使用できるようにします。
アクセス制御を構成するには:
「モバイル・ログイン・サーバー接続」ウィザードで、「認可」ページに移動します。
「モバイル・ログイン・サーバー接続」ウィザードを開く方法の詳細は、第29.5.1項「MAFログイン接続の作成方法」を参照してください。
図29-12に示すとおり、「認可」ページで、認可要件を完了します。
アクセス制御サービスURL: アクセス制御サービス(ACS)のエンドポイントであるURLを入力します。
「ロール」: アプリケーション機能によってチェックされるユーザー・ロールを入力します。セキュリティ・システムには、数千もの定義済のユーザー・ロールおよび権限が存在する可能性があるため、アプリケーション機能に固有のロールが記載されているマニフェスト(これは、アプリケーション機能の開発者によって提供されます)を使用して、このリストを作成します。
「権限」: アプリケーション機能によってチェックされる権限を入力します。
アクセス制御サービス(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"要素を含めないでください。
すべての権限を戻す必要がある場合は、 |
次の例は、HTTP POSTメッセージを示しています。この例では、JSONオブジェクトをペイロードとして識別し、John Smithというユーザーに割り当てられているすべてのフィルタとロールをリクエストします。
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配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられている権限のリスト全体が戻されます。
次の例は、戻されたJSONオブジェクトを示しています。これには、ユーザー名およびJohn Smithというユーザーに割り当てられているロールと権限が含まれています。
Content-Type: application/json
{
"userId": "johnsmith",
"roles": [ "role1" ],
"privileges": ["priv1", "priv3"]
}
|
注意: Webサービスでは、ログイン・ページはなく、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービスのヘッダーに自動的に資格証明が追加されます。詳細は、第15.3.4項「資格証明の挿入に関する必知事項」を参照してください。 |
|
注意: ACSサービスを実装してホストする必要があり、MAFでは、このサービスは提供されません。 |
MAFは、図29-12に示すように、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パラメータは、connections.xmlファイルのadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして戻されます(第29.5.16項「基本認証ヘッダーの挿入に関する必知事項」の例を参照)。appLoginパラメータをtrueに設定すると、ACSでフィーチャ・アクセスが再評価できます。OptionalExtraPayLoadパラメータは、今後の使用のために予約済であるため使用されません。
invokeACSメソッドまたはisAcsCalledAutomaticallyパラメータのいずれかを使用してACSを起動すると、アプリケーションにロール・ベースの制約が取得されます。
|
注意: connections.xmlファイルに<isAcsCalledAutomatically value = "false"/>が含まれていない場合、MAFは、ログインに成功した後、自動的にACSを起動します。 |
保護されているアプリケーション機能がinvokeACSメソッドをコールすると、MAFは、保護されているアプリケーション機能に構成されている制約を含む、アプリケーション・ログイン接続に関連付けられたすべてのアプリケーション機能のユーザー制約をフェッチします。保護されていないアプリケーション機能がこのメソッドをコールすると、MAFは、ログイン接続に関連付けられた制約を取得するのみです。
|
注意: invokeACSメソッドに加え、AdfmfJavaUtilitiesクラスには、次のライフサイクル・メソッドが含まれています。
詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。 |
MAFアプリケーションがログイン接続を起動してユーザーを認証する前に、接続値をプログラムで設定できます。この技術は、たとえば、カスタム・ヘッダー名がモバイル・ログイン・サーバー接続ウィザードで定義されているが、値を実行時に指定する必要がある場合に必要になることがあります。接続の詳細をプログラムで構成するために、MAFアプリケーションでは、oracle.adfmf.framework.api.AdfmfJavaUtilitiesクラスのOverrideConnectionHandler APIを起動できます。このAPIは、現在の接続プロパティを新しい値でオーバーライドし、オーバーライドされた値でアプリケーションがログインを開始できます。
接続値をプログラムでオーバーライドするには、次の一般的なプロセスが必要です。
オーバーライドするプロパティを定義するXML要素の名前をconnections.xmlファイルから取得する。
認証の前にオーバーライド値を取得する。たとえば、MAFアプリケーションでは、AMXページを定義して、この用途で値をエンド・ユーザーに求める場合があります。
オーバーライド・メソッドを実装するマネージドBeanを起動し(接続プロパティのオーバーライドごとに1つ)、ゲッター・メソッドとセッター・メソッドを定義する。たとえば、AMXページの場合、エンド・ユーザーがクリックするコマンド・ボタンで、マネージドBeanで入力した値を送信できます。
接続プロパティのオーバーライドを指定するには、connections.xmlファイルを調べて、次のXML要素の定義を取得します。
接続参照名。たとえば、ConnWithCustomHeaderです。
オーバーライドする属性を定義するプロパティのXML要素名。たとえば、テナント・ドメイン名の伝播に使用されるスキームのmultiTenantSchemeです。
オーバーライドするプロパティの属性を定義するXMLサブ要素名。一意の接続プロパティの場合は、常にvalue要素になります。
|
注意: カスタム・ヘッダー定義では、同じ要素名を使用して値を指定するため、カスタム・ヘッダーの場合は、XML要素headerおよびvalueを使用しないでください。かわりに、カスタム・ヘッダーにはContents、プロパティおよび属性にはcustomAuthHeadersを使用して、オーバーライド・メソッドにそれぞれ渡してください。 |
XML要素名の取得
たとえば、カスタム・ヘッダーの値をオーバーライドするには、次のconnections.xmlファイルで、接続名ConnWithCustomHeader、Contents要素、およびcustomAuthHeadersサブ要素を渡します(これらはヘッダー名/値のペアを定義します)。
package mobile; <References xmlns="http://xmlns.oracle.com/adf/jndi"> <Reference name="ConnWithCustomHeader" className="oracle.adf.model.connection.adfmf.LoginConnection" adfCredentialStoreKey="ConnWithCustomHeader" partial="false" manageInOracleEnterpriseManager="true" deployable="true" xmlns=""> <Factory className="oracle.adf.model.connection.adfmf.LoginConnectionFactory"/> <RefAddresses> <XmlRefAddr addrType="adfmfLogin"> <Contents> ... <isMultiTenantAware value="true"/> <multiTenantScheme value="custom_header"/> <multiTenantHeaderName value="X-ID-TENANT-NAME"/> <customAuthHeaders> <header name="State" value="Georgia"/> <header name="City" value="Atlanta"/> </customAuthHeaders> ... </Contents> </XmlRefAddr> </RefAddresses> </Reference>
オーバーライド値の取得
実行時に接続値のオーバーライドを実行するために、MAFアプリケーションは、値および値を送信するコマンドボタンのプロンプトでAMXページを起動する、デフォルトの保護されていない機能で値を求める場合があります。次のサンプルは、マネージドBeanのオーバーライド・メソッドをトリガーするアクション・リスナーを定義するコマンドボタンを示しています。
<?xml version="1.0" encoding="UTF-8" ?>
<amx:view xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:amx="http://xmlns.oracle.com/adf/mf/amx"
xmlns:dvtm="http://xmlns.oracle.com/adf/mf/amx/dvt">
<amx:panelPage id="pp1">
<amx:facet name="header">
<amx:outputText value="Home" id="ot1"/>
</amx:facet>
<amx:facet name="primary">
<amx:commandButton id="cb1"/>
</amx:facet>
<amx:facet name="secondary">
<amx:commandButton id="cb2"/>
</amx:facet>
<amx:inputText label="Name1" id="it1" value="#{applicationScope.OverrideBean.headerName1}"/>
<amx:inputText label="Value1" id="it2" value="#{applicationScope.OverrideBean.headerValue1}"/>
<amx:inputText label="Name2" id="it3" value="#{applicationScope.OverrideBean.headerName2}"/>
<amx:inputText label="Value1" id="it4" value="#{applicationScope.OverrideBean.headerValue2}"/>
<amx:inputText label="TenantHeader" id="it5"
value="#{applicationScope.TestBean.tenantHeaderName}"/>
<amx:inputText label="Scheme" id="it6" value="#{applicationScope.OverrideBean.scheme}"/>
<amx:commandButton text="Override headers" id="cb3"
actionListener="#{OverrideBean.overrideAndGotoOverrideFeature}"/>
</amx:panelPage>
</amx:view>
接続プロパティのオーバーライド
接続プロパティの値をプログラムでオーバーライドするために、マネージドBeanでは、接続プロパティのオーバーライドごとにオーバーライド・メソッドを実装します。次のサンプルでは、Ova headers HashMapが作成され、カスタム・ヘッダー値を渡します。他のプロパティの値(MultiTenantHeaderNameなど)は、connections.xml定義のXML要素によって一意に定義されるため、マップが必要になるのは、オーバーライドするカスタム・ヘッダーの場合のみです。
package mobile;
import oracle.adfmf.amx.event.ActionEvent;
import oracle.adfmf.framework.api.AdfmfJavaUtilities;
import oracle.adfmf.java.beans.PropertyChangeListener;
import oracle.adfmf.java.beans.PropertyChangeSupport;
import java.util.HashMap;
public class OverrideBean {
private String headerName1 = "", headerName2 = "", headerValue1 = "", headerValue2 = "";
private String tenantHeaderName = "";
private String scheme = "";
// Bean setter and getter methods omitted for brevity
...
// Command button action listener invokes override method implementation
public void overrideAndGotoOverrideFeature(ActionEvent e) {
overrideAndGotoOverrideFeature();
}
// Override method implementation configures custom headers and other connection properties
public void overrideAndGotoOverrideFeature()
{
AdfmfJavaUtilities.clearSecurityConfigOverrides("ConnWithCustomHeader");
HashMap<String, String> headers = new HashMap<String, String>();
headers.put(headerName1, headerValue1);
headers.put(headerName2, headerValue2);
AdfmfJavaUtilities.overrideConnectionProperty("ConnWithCustomHeader", "Contents",
"customAuthHeaders", headers);
AdfmfJavaUtilities.overrideConnectionProperty("ConnWithCustomHeader",
"multiTenantHeaderName", "value",
tenantHeaderName);
AdfmfJavaUtilities.overrideConnectionProperty("ConnWithCustomHeader", "multiTenantScheme",
"value", scheme);
AdfmfJavaUtilities.updateApplicationInformation(false);
}
public void addPropertyChangeListener(PropertyChangeListener l) {
propertyChangeSupport.addPropertyChangeListener(l);
}
public void removePropertyChangeListener(PropertyChangeListener l) {
propertyChangeSupport.removePropertyChangeListener(l);
}
}
MAF機能エディタ、MAFアプリケーション・エディタおよび「モバイル・ログイン・サーバー接続」ウィザードを使用してセキュリティを構成します。エディタを使用すると、認証を必要とするアプリケーション機能をユーザーが選択したときにMAFによって表示されるログイン・ページのタイプ(デフォルトまたはカスタム)を指定したり、ユーザー・ロールまたはユーザー権限ベースの制約を含めることができます。また、これらによって、セキュリティが必要な埋込みアプリケーション機能を選択することもできます。
セキュリティが適用されるように各アプリケーション機能を定義できます。残りのセキュリティ構成は、MAFアプリケーション・エディタの「セキュリティ」のセクションを使用して行います。
図29-13に示すとおり、セキュリティが適用されるアプリケーション機能およびMAF機能エディタの「機能」セクションで必要な認証タイプを指定できます。
始める前に:
機能のセキュリティを有効化すると、アプリケーションは、ネットワークにアクセスしてユーザーを認証する必要があります。ネットワーク・ソケットへのアプリケーション・アクセス権の付与の詳細は、第9.2項「MAFアプリケーションでのコア・プラグインの有効化」を参照してください。
アプリケーション機能に対するユーザー・アクセスを指定するには:
プロジェクト・エクスプローラのユーザー・インタフェース・プロジェクトで、MAFを展開し、「MAF機能エディタ」をダブルクリックします。
MAF機能エディタで、「機能」の下にリストされているアプリケーション機能を選択するか、または「機能」を右クリックし、「新」を選択してアプリケーション機能を追加します。
ログインが必要なアプリケーション機能に「セキュリティの有効化」を選択します。
|
ヒント: このオプションをデフォルトのアプリケーションに適用しない場合、ユーザーは匿名で(つまり、ログイン資格証明を入力せずに)ログインできます。ユーザーは、保護されていないデータおよび機能にアクセスでき、要求があった場合にはログインします(認証されたユーザーは、保護されているデータと保護されていないデータの両方にアクセスできます)。MAFアプリケーション内に保護されていないアプリケーション機能を提供すると、ユーザーは保護されているアプリケーション機能からログアウトするが、アプリケーション自体に残って、保護されていないアプリケーション機能とデータの両方に引き続きアクセスできます。 |
アプリケーション機能のセキュリティを指定したら、図29-14に示されているMAFアプリケーション・エディタの「セキュリティ」ページを使用して、セキュリティが適用される各アプリケーション機能に対して、ログイン・ページの構成およびログイン・サーバーへの接続の作成とその割当てを行います。このページにリストされているすべてのアプリケーション機能は、MAF機能エディタで、セキュリティが必要なものとして指定されています。
通常、アプリケーション機能のグループは、同じログイン・サーバー接続で保護され、ユーザーは、MAFから再度ログインを求められることなく、これらのアプリケーションをどれでも開くことが可能です。ただし、場合によっては、あるアプリケーション機能のセットを保護しているログイン・サーバーと、別のアプリケーション機能のセットを保護しているログイン・サーバーが異なるため、アプリケーション機能で要求される資格証明がそれぞれ異なる可能性があります。このような状況に対応するために、モバイル・アプリケーション用のログイン・サーバーへの接続をいくつも定義できます。maf-application.xmlファイルでは、機能参照に関連付けられている認証サーバー接続は、次のようにloginConnRefId属性を使用して指定されます。
<adfmf:featureReference id="feature1" loginConnRefId="Connection_1"/> <adfmf:featureReference id="feature2" loginConnRefId="Connection2"/>
MAFアプリケーションは、HTTPまたはHTTPS経由のBasic認証をサポートしている標準のログイン・サーバーなら、どのログイン・サーバーに対しても認証を受けることが可能です。MAFはまた、Oracle Identity Managementに対する認証もサポートしています。特定のアプリケーション機能用のカスタム・ログイン・ページを選択することもできます。詳細は、第29.6.4項「ログイン・ページに関する必知事項」を参照してください。
|
注意: デフォルトでは、保護されているすべてのアプリケーション機能が同じ接続を共有し、この接続は、図29-14に示すとおり、<application login server>と表示されます。ログイン・サーバー(接続)は、「セキュリティ」タブで定義します。登録された機能タブでは、特定の機能にそれらを割り当てたり、<default>を使用できます。モバイル・ログイン・サーバー接続ウィザードを使用して、MAFアプリケーション用に定義されている他の接続を選択できます。 |
始める前に:
MAFアプリケーションでカスタム・ログイン・ページを使用する場合、図29-14に示すように、ビュー・コントローラ・プロジェクトのViewContentディレクトリにこのファイルを追加して、MAFアプリケーション・エディタから使用できるようにします。第29.6.3項「カスタム・ログインHTMLページの作成方法」および第5.4項「外部リソースの選択に関する必知事項」も参照してください。
第22.2.4項「ユーザー制約とアクセス制御について」の説明に従って、ユーザー権限とロール用の制約を追加します。
アクセス制御サービス(ACS)・サーバーをプロビジョニングします。詳細は、第29.5.19項「アクセス制御サービスに関する必知事項」を参照してください。
ログイン・ページを指定するには:
プロジェクト・エクスプローラで、アセンブリ・プロジェクトおよびMAFの順に展開し、「MAFアプリケーション・エディタ」をダブルクリックします。
アウトラインで、「セキュリティ」をクリックします。
「セキュリティ」ページで、ユーザー名およびパスワードを受け入れるビューとして「ログイン・ページ」を選択します。
次のように、選択したログイン・ページのコンテンツ(またはユーザー・インタフェース)を選択します。
デフォルト: 選択されたすべての埋込みアプリケーション機能で使用されるデフォルト・ログイン・ページ。詳細は、第29.6.4.1項「デフォルト・ログイン・ページ」を参照してください。デフォルト・ログイン・ページはMAFによって指定されます。
「カスタム」: 「参照」をクリックして、アプリケーション・コントローラ・プロジェクト内のファイルのパスの場所を検索します。または、「新規」をクリックして、ログイン・ページのカスタムHTMLページをアプリケーション・コントローラ・プロジェクト内に作成します。詳細は、第29.6.4.2項「カスタム・ログイン・ページ」を参照してください。
|
ヒント: 「参照」機能を使用してログイン・ページの場所を検索するのではなく、「プロジェクト・エクスプローラ」からログイン・ページをフィールドにドラッグできます。 |
MAFのデプロイメントによってwwwディレクトリ内に生成されるアーティファクトであるデフォルトのログイン・ページ(adf.login.html)を変更すると、カスタム・ログイン・ページを作成できます。
始める前に:
wwwディレクトリ内のログイン・ページにアクセスするには、MAFアプリケーションをデプロイした後、deployディレクトリに移動します。iOSデプロイメントの場合、ページは次の場所にあります。
application workspace directory/deploy/deployment profile name/temporary_xcode_project/www/adf.login.html
Androidデプロイメントの場合、ページは、次の場所にあるAndroidアプリケーション・パッケージ(.apk)ファイル内に配置されます。
application workspace directory/application name/deploy/deployment profile name/deployment profile name.apk/assets/www/adf.login.html
カスタム・ログイン・ページを作成するには:
ビュー・コントローラ・プロジェクトのViewContentディレクトリ内の場所に、デフォルト・ログイン・ページをコピーします。
ログイン・ページの名前を変更します。
ページを更新します。
MAFアプリケーション・エディタの登録された機能タブの「セキュリティ」セクションで、カスタム・ログイン・ページを選択します。
アプリケーション機能の認証プロセスのエントリ・ポイントは、activateライフサイクル・イベントです(第10.1項「MAFアプリケーションのライフサイクル・リスナーの概要」を参照)。アプリケーション機能がアクティブ化されるたびに(つまり、アプリケーション機能のactivateイベント・ハンドラがコールされるたびに)、アプリケーション機能ログイン・プロセスは実行されます。このプロセスは、ログイン・ページ(デフォルトまたはカスタムのログイン・ページのいずれか)に移動し、そこでユーザー認証が必要かどうかを判断します。ただし、プロセスがログイン・ページに移動する前に、本来意図されていたアプリケーション機能をMAFに登録する必要があります。認証が成功すると、ログイン・ページは、MAFから本来意図されていた宛先を取得し、そこに移動します。
MAFによって提供されるデフォルトのログイン・ページは、ログイン・ボタンと、ユーザー名とパスワード用の入力テキスト・フィールド、マルチテナント名(オプション)、およびエラー・メッセージ・セクションから構成されます。これは、HTMLで記述されたクロス・プラットフォーム・ページです。図29-1は、デザインタイムでマルチテナント対応オプションを有効にしたデフォルトのログイン・ページを示し、このページでは、ユーザー名とパスワードの他、テナントのドメイン名の入力が要求されます。
MAF機能エディタを使用して、選択したアプリケーション機能用のカスタム・ログイン・ページを追加すると、OEPEは、次の例に示すとおり、<adfmf:login>要素を追加し、その子要素<adfmf:LocalHTML>を移入します。すべての<adfmf:LocalHTML>要素と同様に、そのurl属性は、public_htmlディレクトリ内の場所を参照します。ユーザー認証メカニズムとナビゲーション・コントロールは、デフォルトのログイン・ページと同じものになります。
<adfmf:login defaultConnRefId="Connection_1">
<adfmf:localHTML url="newlogin.html"/>
</adfmf:login>
カスタム・ログイン・ページはHTMLで記述されています。デフォルトのログイン・ページのフィールドには、特別に定義された<input>および<label>要素が含まれている必要があります。
|
ヒント: カスタム・ログイン・ページを作成するためのガイドとしてMAFアプリケーションのデプロイ時に生成されたデフォルトのログイン・ページを使用します。wwwディレクトリ内のログイン・ページにアクセスするには、MAFアプリケーションをデプロイした後、deployディレクトリに移動します(第29.6.3項「カスタム・ログインHTMLページの作成方法」を参照)。 |
次の例は、デフォルト・ログイン・ページに必要な<input>および<label>要素を示しています。
<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"/>
各HTMLログイン・ページに、表29-2にリストされたユーザー・インタフェース要素が含まれている必要があります。
表29-2 ログイン・ページのフィールドおよび関連するID
| ページの要素 | ID |
|---|---|
|
「ユーザー名」フィールド |
|
|
「パスワード」フィールド |
|
|
「ログイン」ボタン |
|
|
「取消」ボタン |
|
|
「Identityドメイン」/「テナント名」フィールド |
|
|
「エラー」フィールド |
|
|
自動ログイン・チェック・ボックス |
|
|
「資格証明を記憶」チェック・ボックス |
|
|
「ユーザー名を記憶」チェック・ボックス |
|
表29-3は、OnClickイベントで使用される推奨のJavaScriptコードをリストしています。
セキュリティが適用されるようにアプリケーション機能が指定されると、OEPEは、図29-14に示すとおり、対応する機能参照で登録された機能を更新します。参照される各アプリケーション機能が、connections.xmlファイル内に定義されている同じログイン・サーバー接続に対して認証を行うと、OEPEは、defaultConnRefId属性を使用して定義されている単一の<adfmf:login>要素(<adfmf:login defaultConnRefId="Connection_1">など)でmaf-application.xmlファイルを更新します。
connections.xmlファイル内に定義されている別のログイン・サーバー接続を使用するように構成されているアプリケーション機能の場合は、OEPEは、参照される各アプリケーション機能をloginConnReference属性(<adfmf:featureReference id="feature2" loginConnRefId="Connection2"/)で更新します。詳細は、第29.6.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照してください。Oracle Mobile Application Frameworkタグ・リファレンスも参照してください。
デバイス機能へのアクセスは、MAFアプリケーションに組み込まれているCordovaプラグインによって定義されます。コア・プラグインのセットはMAFによって提供されます。これらのプラグインの1つを有効にすると、そのプラグインに必要なすべてのデバイス・アクセス権限が有効になります。MAFアプリケーションに組み込まれている他のCordovaプラグインも、必要なデバイス・アクセス権限を有効にします。
MAFアプリケーションの大多数ではネットワーク・アクセスが必要なため、ネットワークにアクセスする権限はデフォルトで有効になっています(デフォルトで有効になっている唯一のデバイス機能)。
ネットワーク情報: アプリケーションによるネットワーク・ソケットのオープンを許可します。少なくとも1つのデバイス機能のセキュリティが有効な場合、ネットワーク・アクセス機能は有効にしておく必要があります。
デバイス機能の有効化または制限が可能なため、デプロイメント・フレームワークによって更新されるプラットフォーム固有の様々な構成ファイルやマニフェスト・ファイルでは、使用中のデバイス機能(または、MAFアプリケーションに使用が登録されているプラグイン)のみがリストされます。これらのファイルにより、MAFはこれらの機能の使用に関する情報を他のアプリケーションと共有できます。たとえば、AppStoreやGoogle Playに対して、MAFアプリケーションで場所ベースの機能が(搭載されていても)使用されていないことを通知できます。
MAFアプリケーションのCordovaプラグインの詳細は、第9章「MAFアプリケーションでのプラグインの使用方法」を参照してください。
MAFアプリケーション内の選択したアプリケーション機能がネイティブ・コンテナと、拡張により、MAFアプリケーションがアクセスできるデバイス機能にアクセスできないようにすることもできます。たとえば、MAFアプリケーションには、信頼していないWebアプリケーションからリモート・コンテンツを参照するアプリケーション機能が含まれます(リモートURLコンテンツ・アプリケーション機能)。このシナリオでは、次の例に示すように、この特定のアプリケーション機能がネイティブ・コンテナにアクセスできないようにします。
<adfmf:featureReference refId="remoteAppfeature1" id="fr1" allowNativeAccess="false"/>
allowNativeAccessプロパティのデフォルト値はtrueです。
ユーザーが、保護されているコンテンツを含むアプリケーション機能からログアウトするとき、または制約によって制限されているときは、MAFはアプリケーション機能を終了せず、またユーザーはアプリケーション内でログイン状態を維持し、セキュアでないコンテンツおよび機能に匿名ユーザーとしてアクセスできます。MAFでは、制約を再初期化できるため、ユーザーは、同じアイデンティティを使用して、アプリケーションに繰り返しログインできます。また、MAFは、ユーザーに別のアイデンティティを使用したログインを許可することで、複数のアイデンティティでアクセスを共有できます。
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 Mobile Application Framework Java APIリファレンスを参照してください。
MAFには、APIが含まれた様々な認証クラスが用意されており、MAFアプリケーションで認証関連のタスクを行う場合に役立ちます。
これらのAPIは、oracle.maf.api.authenticationパッケージの認証クラスに存在します。たとえば、AuthenticationHandlerクラス、AuthenticationPlatformクラス、AuthenticationUtilityクラスなどがあります。
これらのAPIを実装して実行できるタスクには、ログイン中のユーザーが保護されたアプリケーションにアクセスする前に行う処理などがあります。たとえば、認可ヘッダー情報を取得し、その情報を使用して、エンド・ユーザーがログイン成功時に移動するコンテンツを決定します。AuthenticationPlatformは、エンド・ユーザーが保護されたアプリケーション機能からログアウトしたときになんらかの処理を実行するために実装できるaddLogoutCallback APIも提供します。このコールバックAPIを使用すると、エンド・ユーザーがデバイスを共有しているシナリオで役立つ場合があります。これらの認証クラスの詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。
次の例は、実装クラスからのコードのスニペットを示しており、AuthenticationPlatformのインスタンスはそのgetToken() APIを使用して認可ヘッダー情報を取得します。
例29-1 認証プラットフォームからの認可ヘッダーの取得
import oracle.maf.api.authentication.AuthenticationPlatform;
import oracle.maf.api.authentication.AuthenticationUtility;
…
AuthenticationPlatform ap = AuthenticationUtility.getInstance().lookupByCredentialStoreKey("credentialStoreKey");
String authorization = ap.getToken("Authorization");
…
MAFは、cacerts証明書ファイル(HTTPSハンドシェークのためのクライアント・アプリケーションおよびサーバー間のJavaメカニズム)を提供します。このファイルは、OEPEにより、アプリケーション・リソース「セキュリティ」フォルダ([assembly project\lib\Security\cacertsにあります)内に作成されます。MAFのcacertsファイルにより、信頼できる既知のソースからの一連の証明書がJVMに対して識別され、デプロイメントが可能になります。
サーバーが自己署名証明書を使用しているサーバー・リソースにアプリケーションがアクセスする必要がある場合は、プライベート証明書をMAFのcacertsファイルに追加する必要があります。アプリケーションでカスタム証明書が必要な場合(RSA暗号化が使用されていない場合など)も、プライベート証明書を追加する必要があります。アプリケーションをデプロイする前に、プライベート証明書を追加します。
始める前に:
cacertsファイルの内容を理解しておくと役立ちます。詳細は、Oracle Enterprise Pack Oracle Enterprise Pack for EclipseのインストールのMAFにおけるSSL用の新規cacertsファイルへの移行に関する項を参照してください。
OEPEによるcacertsファイルの作成方法についても理解しておくと役立ちます。詳細は、第C.2項「アセンブリ・レベルのリソースについて」を参照してください。
cacertsファイルおよびkeytoolユーティリティの使用方法の詳細は、Java SEテクニカル・ドキュメント(https://download.oracle.com/javase/index.html)を参照してください。
プライベート証明書を追加するには:
プライベート証明書を作成します。たとえば、new_certという証明書ファイルを作成します。
次のようにして、プライベート証明書をアプリケーションに追加します。
シードされたcacertsファイル(cp cacerts cacerts.org)のコピーを作成します。
Java SE keytoolユーティリティを使用して、cacertsファイルに証明書を追加します。次の例は、new_certというcacertsファイルへの証明書の追加を示しています。
keytool -importcert
-keystore cacerts
-file new_cert
-storepass changeit
-noprompt
この例は、単一の証明書の追加方法を示しています。各証明書に対して同じ手順を繰り返します。表29-4は、keytoolのオプションを示しています。
新しいcacertsファイルの内容を目で見て調べて、すべてのフィールドが正しいことを確認します。次のコマンドを使用します。
keytool -list -v -keystore cacerts | more
証明書が指定のホスト名に対するものであることを確認します。
|
注意: 証明書の共通名(CN)は、ホスト名と正確に一致している必要があります。 |
JVM 1.4が読み取れるようにするために、カスタマイズされた証明書ファイルはSecurityディレクトリ(users\workspaces\assembly project\lib\Security)に確実に配置してください。
アプリケーションをデプロイします。
|
注意: デプロイメント時、証明書ファイルがSecurityディレクトリに存在している場合、MAFは、それをAndroidまたはXcodeテンプレート・プロジェクトにコピーし、cacertsファイルのデフォルト・コピーを置き換えます。 |
保護されているリソースにSSL経由でアクセスできることを確認します。
MAFアプリケーションのエンド・ユーザーは、デジタル証明書(クライアント証明書)をアプリケーションのキーストアにインストールし、双方向SSL、相互認証または双方向認証という様々な名前で呼ばれるプロセスを使用して、認証を有効にできます。
エンド・ユーザーがクライアント証明書をアプリケーションのキーストアにインストールすると、MAFアプリケーションでは、クライアントとサーバー間の認証を実行するために双方向SSL通信セッションが使用されるように、サーバーにその証明書を提示できます。
この機能を実装するには、クライアント証明書のファイル拡張子をアプリケーションに登録する必要があります。これを実行することにより、MAFアプリケーションは、エンド・ユーザーがクライアント証明書ファイルを自分のデバイスにダウンロードしてから開く際に、証明書を開いてインストールできます。MAFアプリケーションは、デバイス上でクライアント証明書のファイル拡張子を登録している唯一のアプリケーションである場合、証明書を開くエンド・ユーザーに対してデバイスのオペレーティング・システムが提示するアプリケーションとなります。他のアプリケーションがファイル拡張子を登録している場合、デバイスのオペレーティング・システムはアプリケーションのリストを提示し、エンド・ユーザーはそこからMAFアプリケーションを選択する必要があります。
管理者がクライアント証明書をMAFアプリケーションのエンド・ユーザーに配布するには、電子メール添付ファイルを使用するか、エンド・ユーザーがURLを使用してクライアント証明書をダウンロードできる場所で証明書をホストします。
iOSプラットフォームでは、サード・パーティ製アプリケーションがクライアント証明書のデフォルトの拡張子(.p12)を使用してファイルを開くことが許可されていません。この制限を回避するために、アプリケーション開発者は別の証明書拡張子(.certなど)を登録する必要があります。証明書を配布する管理者は、別の拡張子を使用するようにクライアント証明書の名前を変更して、MAFアプリケーションのエンド・ユーザーが電子メール添付ファイル、またはクライアント証明書の配布に使用するURLから直接クライアント証明書を開くことができるようにします。
双方向SSLを有効にするためにMAFアプリケーションを構成する方法
アプリケーションにクライアント証明書のファイル拡張子を登録するには、MAFアプリケーション・エディタの「アプリケーション」ページで、ファイル拡張子を「クライアントSSL証明書の拡張」フィールドに入力します。
双方向SSLを有効にするためにMAFアプリケーションを構成するには:
プロジェクト・エクスプローラで、アセンブリ・プロジェクトおよびMAFの順に展開し、「MAFアプリケーション・エディタ」をダブルクリックします。
「アウトライン」で、アセンブリ・プロジェクト名をクリックします。
「アプリケーション」ページで、「クライアントSSL証明書の拡張」フィールドにファイル拡張子を入力します。
双方向SSLを有効にするためにMAFアプリケーションを構成した場合の処理
例29-2に示すように、OEPEにより、「クライアントSSL証明書の拡張」フィールドに入力した値がmaf-application.xmlファイルに書き込まれます。
実行時に、エンド・ユーザーは、クライアント証明書を管理者が配置した場所からデバイスにダウンロードするか、または電子メール添付ファイルから自動的に開きます。サーバーの場所からのダウンロード動作は、エンド・ユーザーのデバイスのオペレーティング・システムによって異なります。たとえば、Androidデバイスを使用するMAFアプリケーションのエンド・ユーザーは、証明書をAndroidのダウンロード・ディレクトリにダウンロードします。ダウンロードすると、エンド・ユーザーはMAFアプリケーションのキーストアにインストールするために証明書を抽出します(開きます)。このステップを完了するには、エンド・ユーザーは、クライアント証明書を配布した管理者が提供したパスワードを入力する必要があります。エンド・ユーザーがアプリケーションのキーストアに証明書をインストールすると、MAFアプリケーションはその証明書をサーバーに提示して、双方向SSLセッションを確立できます。
例29-2 maf-application.xmlファイルでのクライアント証明書のファイル拡張子
<adfmf:application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:adfmf="http://xmlns.oracle.com/adf/mf"
version="1.0" name="twowayssltest" id="com.company.twowayssltest"
appControllerFolder="ApplicationController" listener-class="application.LifeCycleListenerImpl"
client-ssl-certificate-extension="cert">
….
