プライマリ・コンテンツに移動
Oracle® Mobile Application Framework Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発
2.1.3.0.0
E67370-01
  目次へ移動
目次

前
 
次
 

29 MAFアプリケーションの保護

この章では、MAF内のセキュリティ・フレームワークの概要と、セキュリティが適用されるようにMAFアプリケーションを構成する方法について説明します。

この章の内容は次のとおりです。

29.1 MAFセキュリティの概要

保護されているアプリケーション機能がアクティブ化されているとき、MAFによってログイン・ページがユーザーに対して表示されます。たとえば、アプリケーション機能がWebビュー内に表示されようとしているときやオペレーティング・システムがアプリケーションをフォアグラウンドに戻したときなどに、ログイン・ページがユーザーに表示されます。MAFは、アプリケーション機能が認証サーバーによって保護されている場合や、アプリケーション機能にユーザー・ロールまたは権限に基づく制約が含まれる場合に、アプリケーション機能へのアクセスで認証が必要かどうかを判断します。MAFは、ユーザーが有効な資格証明を入力した場合にのみ、目的のWebビュー、UIコンポーネントまたはアプリケーション・ページをレンダリングします。

アプリケーション機能のいずれかにこれらの条件がある場合、ユーザーはログインに成功しないとMAFアプリケーションにアクセスできないことがありますが、保護されておらず、かつアクセス関連の制約がないデフォルトのアプリケーション機能を含めることによって、保護されているアプリケーション機能と保護されていないアプリケーション機能の両方を含むMAFアプリケーションに、ユーザーがアクセスできるようにできます。この状況では、ユーザーは認証なしでMAFアプリケーションにアクセスできます。デフォルトのアプリケーション機能によって、これらの匿名ユーザーに、MAFアプリケーションへのエントランス・ポイントが提供され、これらのユーザーは保護されていないデータを表示でき、保護されたアプリケーション機能にアクセスするときには、リモート・サーバーに対して認証されます。保護されていないデフォルトのアプリケーション機能は、次のように指定できます。

  • デフォルトのアプリケーション機能を介して公開情報にアクセスすることを匿名ユーザーに許可するが、保護された情報には権限のあるユーザーのみがアクセスできるようにします。

  • 保護されたアプリケーション機能にアクセスする必要がある場合にのみユーザーを認証するようにします。そうでない場合、ユーザーは匿名ユーザーとしてMAFアプリケーションにアクセスでき、保護された機能に移動するにはログインします。

  • 保護されたアクセスが必要でない場合は保護されたアプリケーション機能からログアウトすることをユーザーに許可することで、権限のないユーザーが保護されたアプリケーション機能にアクセスすることを明示的に禁止します。


注意:

MAFでは、アプリケーション・ログイン・プロセスがアプリケーションの初期化フローから切り離されているため、匿名ユーザーが可能となり、ユーザーは認証資格証明を提供する必要なく、匿名ユーザーとしてMAFアプリケーションを起動し、保護されていないアプリケーション機能にアクセスできます。このような場合、MAFは権限を持つUIコンポーネントを無効化することによって、ユーザーのアクションを制限します。

詳細は、第29.6.1項「認証を要求するようにアプリケーション機能を設定する方法」および第22.2.4項「ユーザー制約とアクセス制御について」を参照してください。

MAFアプリケーションでは、デフォルト・ページまたはHTMLで記述されたカスタマイズ済のログイン・ページが使用されます。ログイン・ページ以外での認証が必要な場合、ナレッジベース認証(KBA)がOAMサーバー上に構成されていると、ナレッジベース認証ページを有効にできます。KBA画面では、母の旧姓などの追加情報を要求することで、追加のチャレンジがユーザーに表示されます。ログイン・ページと同様、KBA画面はカスタマイズできます。

user.rolesまたはuser.privileges制約を使用して定義されたアプリケーション機能には、特定のロールおよび権限が付与されたユーザーのみがアクセスできます。ユーザーがそのようなアプリケーション機能にログインする場合、アクセス制御サービス(ACS)と呼ばれるWebサービスが、このアプリケーション機能へのアクセスをユーザーに許可するユーザー・オブジェクトを戻します。ACSの詳細は、第29.5.21項「アクセス制御サービスに関する必知事項」を参照してください。

開発者は、デプロイ時にMAFアプリケーションのコンテナ化を選択できます。コンテナ化によって、アプリケーションは、Oracle Mobile Security Suite (OMSS)で構成されているエンタープライズ・ネットワーク・プラットフォームのセキュア・ネットワーク機能とネットワーク・トンネリング機能を利用できます。コンテナ化されたアプリケーションの配布は、Oracle Mobile Security Access Server (MSAS)コンポーネントのアプリケーション・カタログとSecure Workspaceコンテナの各機能を使用して、OMSS管理者が管理します。ユーザーの認証は、必要な認証タイプに対して構成されたMSASが実行します。MAFアプリケーションの開発とOMSSコンテナ化の詳細は、第2.7項「エンタープライズ配布に対応するためのMAFアプリケーションのコンテナ化」を参照してください。

29.2 ユーザー・ログイン・プロセスについて

エンド・ユーザーの視点からは、ログイン・プロセスは次のようなものになります。


注意:

MAFアプリケーションのコンテナ化に伴うログイン・プロセスの変更点の詳細は、第29.4項「コンテナ化されたMAFアプリケーションの認証プロセスの概要」を参照してください。

  1. ユーザーが保護されたアプリケーション機能にアクセスしようとすると、常に、図29-1に示すログイン・ページのWebビューがMAFによって表示されます。保護されたアプリケーション機能がデフォルトである場合は、ユーザーがアプリケーションを起動すると、MAFによってデフォルトのログイン・ページが表示されます。

    図29-1 デフォルトのログイン・ページ

    この図は周囲のテキストで説明しています

    注意:

    第29.6.4.2項「カスタム・ログイン・ページ」で説明されているとおり、MAFでは、デフォルト・ログイン・ページを表示するだけでなく、カスタム・ログイン・ページおよびオプションのカスタム・ナレッジベース認証(KBA)画面の使用もサポートされています。

  2. ユーザーがユーザー名とパスワードを入力し、「サインイン」をクリックします。


    注意:

    MAFでは、複数のユーザーが同じアプリケーションを使用できます。ユーザーは、前のユーザーのログアウト後、自由にアプリケーションにログインできます。

  3. ユーザー名とパスワードが検証されると、MAFによって、目的のWebビュー、ページまたはユーザー・インタフェース・コンポーネントが表示されます。

  4. MAFは、ユーザーが正常にログインするまで、ユーザー名とパスワードの入力を求めます。ユーザーがログインできない場合、別のアプリケーション機能に移動することのみが可能です。

  5. ユーザー名とパスワードの認証後、追加の質問による資格証明をチャレンジするナレッジベース認証(KBA)画面がユーザーに表示される場合があります。KBAが構成されている場合、ログイン・プロセスを完了するには、ユーザーが質問に正しく答える必要があります。KBAはオプションの構成で、OAMサーバー上での適切な構成が必要となります。


注意:

アプリケーション機能が最後にアクティブ化されて以降、事前定義された時間が経過すると、認証はタイムアウトになります。MAFでは、認証サーバーへの接続を使用するアプリケーション機能のいずれかがアクティブ化されたときのみ、アイドル・タイムアウトのタイマーの期限が更新されます。

29.3 MAFアプリケーションの認証プロセスの概要

MAFアプリケーションでは、リモート・ログイン・サーバー(Oracle ADF Fusion Webアプリケーションによって使用されるOracle Access Managerアイデンティティ・サーバーなど)、またはユーザーのデバイス上に存在するローカル資格証明ストアに対するユーザー資格証明の検証が必要になる場合があります。ローカルおよびリモート接続モードをサポートするため、MAFでは次の認証プロトコルがサポートされています。

  • HTTP Basic

  • Mobile-Social

  • OAuth

  • Web SSO


注意:

MAFアプリケーションのコンテナ化に伴う認証プロセスの変更点の詳細は、第29.4項「コンテナ化されたMAFアプリケーションの認証プロセスの概要」を参照してください。

デフォルトでは、MAFアプリケーション・ユーザーの認証は、デザインタイムに選択された認証プロトコルに関係なく、リモート・ログイン・サーバーに対して行われます。開発者は、Oracle Access Management Mobile and Social (OAMMS)およびBasic認証の場合に、ローカル認証を有効化するようアプリケーションを構成できます。ただし、最初は、ローカル資格証明ストアに資格証明が移入されていないため、ログインして保護されたアプリケーション機能にアクセスする場合、リモート・ログイン・サーバーに対する認証が必要となります。リモート認証に成功すると、以降は(デバイス上の認証サーバーからのユーザーのログイン資格証明が格納されている)ローカル資格証明ストアを使用できるようになります。このように、ユーザーが同じアプリケーション・セッション内(つまり、アプリケーション実行のライフサイクル内)でサーバーに対して認証されると、MAFはこの認証コンテキストをローカルに格納し、以降の認証試行に使用できるようにします。この場合、ローカルの認証コンテキストで問題なくユーザーを認証できるときには、MAFはサーバーに接続しません。最初の認証では認証サーバーへの接続が必要ですが、ローカル認証を使用するアプリケーションの場合はそのサーバーに頻繁にアクセスする必要はありません。


ヒント:

ローカル資格証明ストアに対する認証は、リモート・ログイン・サーバーに対する認証よりも高速で実行できますが、リモート接続のみをサポートするOAuthやWeb SSO認証プロトコルを使用した認証をお薦めします。

表29-1に、MAFアプリケーションのログイン構成オプションをまとめます。接続モードは、選択した認証プロトコルによって異なります。

表29-1 MAFの接続モードおよびサポートされている認証プロトコル

接続モード サポートされているプロトコル モードの説明

ローカル

  • HTTP Basic

  • Mobile-Social

ローカルに格納されている資格証明がデバイスで使用不可能な場合にのみ、アプリケーションでリモート・ログイン・サーバーに対する認証を行う必要があります。最初のログインは、常にリモート・ログイン・サーバーに対して行われます。最初のログインが成功すると、MAFは、資格証明をデバイスの資格証明ストア内にローカルに保持します。アプリケーション機能への以降のアクセスでは、それらの資格証明が使用されます。第29.5.19項「Webサービス・セキュリティに関する必知事項」も参照してください。

リモート

  • HTTP Basic

  • Mobile-Social

  • OAuth

  • Web SSO

アプリケーションで、Oracle Access Manager (OAM)アイデンティティ・サーバーなどのリモート・ログイン・サーバーまたは保護されているWebアプリケーションに対する認証が必要です。ユーザーがログインするたびに、リモート・サーバーに対する認証が求められます。デバイスがサーバーに接続できない場合、ユーザーは、前回は正常に認証されていても、保護されたMAF機能にアクセスできません。

ハイブリッド

  • HTTP Basic

  • Mobile-Social

ネットワーク接続が使用可能である場合は、デバイス上のローカル資格証明がで使用可能でも、アプリケーションでリモート・ログイン・サーバーに対する認証を行う必要があります。ネットワーク接続が切断されてログイン・サーバーにアクセスできない場合にのみ、デバイス上のローカル資格証明が使用されます。


例として、次のプロセスは、Mobile-Social認証プロトコルがリモート認証サーバーに対してユーザー資格証明を確認するようにMAFアプリケーションが構成されている場合に、セキュリティのフローを表しています。

  1. MAFは、(図29-1のような)ログイン・ページ、またはナレッジベース認証画面をユーザーに表示します。

  2. Oracle Access Management Mobile and Social (OAMMS)クライアントSDKのAPIは、認証サーバーと、デバイス上の資格証明ストア(保存済のユーザー・オブジェクトが格納されている場合があります)の両方に対する資格証明認証を処理します。認証に成功すると、APIは有効なユーザー・オブジェクトをMAFに戻します。それ以外の場合は、失敗を戻します。

  3. ログインに成功すると、MAFは、Cookieで使用されるOAMトークンを受け取ります。各ログイン接続にCookieが設定されます。

  4. OAMMSクライアントSDK APIは、デバイスのローカル資格証明キーストアに資格証明をキャッシュします。アプリケーション・セッション・タイムアウトまたはアイドル・タイムアウトのしきい値を超えると、MAFはローカル資格証明キーストアを消去します。

  5. ログインに失敗した場合、ログイン・ページまたはKBA画面が表示されたままになり、ユーザーは先に進むことができません。

29.4 コンテナ化されたMAFアプリケーションの認証プロセスの概要

MAFアプリケーションを開発するときは、ログイン接続を定義してセキュア機能を開発およびテストする必要があります。テストでは、保護されたリソースにアクセスする前に、MAFのログイン・ページを使用して認証が行われます。デプロイ時に、MAFアプリケーションをコンテナ化してOracle Mobile Security Suite (OMSS)で構成されているエンタープライズ・ネットワーク・プラットフォームのセキュア・ネットワーク機能とネットワーク・トンネリング機能を利用するように選択すると、モバイルVPNは不要になります。

コンテナ化されたMAFアプリケーションのデプロイ後、社内ファイアウォールの背後にあるバックエンド・リソースへのアクセスには、OMSSのコンポーネントであるモバイル・セキュリティ・アクセス・サーバー(MSAS)によって集中アクセス・ポイントが提供され、モバイル・デバイスから社内リソースへのトラフィックが保護されます。この場合、MSASインスタンスを構成して認証エンドポイントを適用し、これを使用して最初のユーザー認証が行われます。

ユーザー認証は、MSASが登録済のMAFアプリケーションに対して提供する、コンテナのシングル・サインオン(SSO)統合によって処理されます。MAFアプリケーションがMSASと通信できるようにするには、MSASインスタンスに対して構成されている認証タイプに対応したSecure Workspaceアプリケーションを、ユーザーがインストールして登録します。その後でユーザーが保護されたリソースにアクセスを試みると、MAFのログイン・ページは表示されずに、ユーザーのモバイル・デバイス上にあるSecure Workspaceアプリケーションを通してMSAS独自のログインが表示されます。


注意:

MSASによる認証を有効にしてAppTunnelを使用するには、MAFアプリケーションで定義されているログインURLまたは認証エンドポイントをプロキシするようにMSASインスタンスを構成する必要があります。MAFログイン接続に対応してMSASを構成する方法の詳細は、第29.5.13項「ログイン接続とコンテナ化されたMAFアプリケーションに関する必知事項」を参照してください。

MSAS AppTunnelを使用してバックエンド・リソース・リクエストをプロキシするかどうかは、MAFアプリケーションとSecure Workspaceアプリケーションが使用するMSAS生成のプロキシ自動構成ファイルによって決まります。AppTunnelは、各Secure Workspaceアプリケーションからの相互認証されたSSLトンネルで、コンテナ化されたMAFアプリケーションへのセキュアなアクセスを提供します。AppTunnelは遷移中のすべてのデータを暗号化し、ユーザーのモバイル・デバイス上にある統制外のアプリケーションから保護して、デバイス・レベルのモバイルVPNに対応します。

コンテナ化されたMAFアプリケーションに対するOMSSのサポートの概要は、第2.7項「エンタープライズ配布に対応するためのMAFアプリケーションのコンテナ化」を参照してください。

29.5 MAF接続の構成

セキュリティが適用されるアプリケーション機能用に、アプリケーション・ログイン・サーバーへの接続を少なくとも1つ定義する必要があります。アプリケーション・ログイン・サーバーへの定義済の接続が存在しないと、無効な構成になります。その結果、アプリケーションは正しく機能しません。

29.5.1 MAFログイン接続の作成方法

図29-2に示すように、「MAFログイン接続の作成」ダイアログを使用して接続タイプを選択し、接続タイプに応じて、ローカルおよびリモート認証の両方を有効化します(ハイブリッド)。アプリケーション要件に応じて、次の認証プロトコルをサポートするサーバーへの接続を構成できます。

  • HTTP Basic

  • Mobile-Social

  • OAuth

  • Web SSO


注意:

OAuthまたはWeb SSO接続タイプを使用したログイン・サーバーへの接続を構成することをお薦めします。OAuthおよびWeb SSOでは、リモート・ログイン・サーバーに対する認証が必要となり、デバイス上でのローカル資格証明ストアからの認証をユーザーに許可しません。

図29-2 認証の構成

この図は周囲のテキストで説明しています

ログイン・サーバー接続を作成するには:

  1. 次のアクションのいずれかを実行します。

    • ナビゲータで、「ディスクリプタ」ノード、「ADF META-INF」と開き、maf-application.xmlをダブルクリックします。次に、maf-application.xmlファイルの概要エディタで、「セキュリティ - 認証とアクセス制御」セクションを展開し、「作成」をクリックします(図29-3を参照)。

      図29-3 サーバー接続の追加

      この図は周囲のテキストで説明しています
    • または、「新規ギャラリ」で「接続」を選択し、「MAFログイン・サーバー接続」を選択します。

  2. 「MAFログイン接続の作成」ダイアログで、目的の「認証サーバー・タイプ」を選択します。

  3. 次の項の説明に従って接続タイプを構成します。

    ダイアログに表示される、アスタリスクが付いたオプションは必須フィールドであることに注意してください。このダイアログでは、すべての必須フィールドが入力された後にのみ「接続のテスト」ボタンが有効になります。このボタンは、Basic認証がダイアログで選択されている場合にのみ表示されます。

29.5.2 マルチテナント対応MAFログイン接続の作成方法

図29-4に示すように、「MAFログイン接続の作成」ダイアログを使用して、1つのアプリケーションに異なる組織(テナント)で共有可能な1つのホスト・アプリケーション機能が含まれ、それが特定のテナントによって所有されているように見える、マルチテナントの概念がサポートされたMAFアプリケーション接続を作成できます。次の認証プロトコルをサポートするサーバーへのマルチテナント対応の接続を構成できます。

  • HTTP Basic

  • Mobile-Social

図29-4 マルチテナント対応の接続の構成

このイメージについては周囲のテキストで説明しています。

図29-5に示すように、MAFアプリケーションで表示されるマルチテナント対応の接続が定義されたデフォルトのログイン・ページでは、HTTPリクエストでテナント値を伝播するため、ドメインIDの入力をユーザーに要求します。

図29-5 マルチテナント対応の接続用のデフォルト・ログイン・ページ

この図は周囲のテキストで説明しています

マルチテナント対応のログイン・サーバー接続を作成するには:

  1. 次のアクションのいずれかを実行します。

    • ナビゲータで、「ディスクリプタ」ノード、「ADF META-INF」と開き、maf-application.xmlをダブルクリックします。次に、maf-application.xmlファイルの概要エディタで、「セキュリティ - 認証とアクセス制御」セクションを展開し、「作成」をクリックします(図29-6を参照)。

      図29-6 サーバー接続の追加

      この図は周囲のテキストで説明しています
    • または、「新規ギャラリ」で「接続」を選択し、「MAFログイン・サーバー接続」を選択します。

  2. 「MAFログイン接続の作成」ダイアログで、マルチテナント・ログインに対応している「認証サーバー・タイプ」を選択します。

  3. 図29-4に示すように、「カスタム・ヘッダー」タブをクリックして、次を構成します。

    • マルチテナント対応: MAFアプリケーション接続にマルチテナント対応を定義する場合に選択します。第29.5.11項「マルチテナント対応の接続の作成時に行われる処理」も参照してください。

    • マルチテナント対応スキーム: テナントのドメインIDを認証サーバーに伝播する場合に使用するスキームを選択します。個別のヘッダーとして送信するには、「カスタム・ヘッダー」(デフォルト)を選択します。「ユーザー名」オプションは下位互換性をサポートし、テナントIDをユーザーIDの一部として送信します(ユーザー名の混在と呼ばれます)。

    • ヘッダー名: 認証サーバーで必要とされるテナント・ヘッダー名を入力します。たとえば、ログイン時にテナントIDの入力をエンド・ユーザーに要求するには、マルチテナント・ヘッダー名「X-ID-TENANT-NAME」を入力します。図29-5に示すように、デフォルトのログイン・ページでは、ドメイン名の入力をユーザーに要求します。

    • カスタム・ヘッダー: オプションで、認証の実行に必要な追加のカスタム・ヘッダー名を入力します。これらは、マルチテナント・ヘッダーの他に構成される場合があります。第29.5.16項「カスタム・ヘッダーに関する必知事項」も参照してください。

      カスタム・ヘッダーのヘッダー値を把握している場合は、その値を入力します。指定したカスタム・ヘッダーの値がログイン時にオーバーライドされる場合は、対応する「値」フィールドを空のままにします。実行時にヘッダー値を指定する場合は、OverrideConnectionHandler APIを使用して値をプログラムで設定する必要があります。APIを使用してヘッダーを構成する方法の詳細は、第29.5.23項「認証の前にログイン資格証明をプログラムで構成する方法」を参照してください。

  4. 次の項の説明に従って接続タイプを構成します。

    ダイアログに表示される、アスタリスクが付いたオプションは必須フィールドであることに注意してください。このダイアログでは、すべての必須フィールドが入力された後にのみ「接続のテスト」ボタンが有効になります。このボタンは、Basic認証がダイアログで選択されている場合にのみ表示されます。

29.5.3 Basic認証の構成方法

図29-7に示すように、「MAFログイン接続の作成」ダイアログで「HTTP基本」認証サーバー・タイプを選択して、Basic認証の接続を構成できます。

図29-7 Basic認証の構成

この図は周囲のテキストで説明しています

Basic認証を構成するには:

  1. 「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」「HTTP基本」を選択します。

    「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.5.1項「MAFログイン接続の構成方法」を参照してください。

  2. 「一般」タブで、次を定義します。

    • 接続モード: 表29-1に示すように、認証のタイプを選択します。

    • 接続名: 接続の名前を入力します。

    • アイドル・タイムアウト: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。


      注意:

      MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を実行しますが、セッション・タイムアウト後にこの認証を実行することはありません。

    • セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。

    • ログイン最大試行回数: ローカル資格証明がクリアされるまでにユーザーに許可する最大ログイン試行失敗回数を設定します。デフォルトで、MAFは、ユーザーに3回のログイン試行の失敗を許可しており、それを超えると、ローカルに格納されているそのユーザーの資格証明をクリアし、以降のログイン試行では、リモート・ログイン・サーバーに接続します。リモート・サーバーに接続した後は、そのユーザーに許可されるログイン試行回数は無制限になります。

      ユーザーがログイン試行を指定した回数失敗すると、ローカル資格証明がクリアされるため、MAFはサーバーに対して認証を実行します。これにより、ユーザーは、管理者がユーザーのパスワードを変更した後、パスワードがデバイス上にまだ格納されていない状態で、この新しいパスワードを使用してログインできるようになります。ローカル認証が許可されている場合、ユーザーがサーバー接続へのログインに成功するとパスワードはデバイス上に安全に格納されます。


      注意:

      アプリケーション機能がローカル認証を使用するように構成されている場合でも、MAFは、ローカルに格納されているユーザー資格証明をクリアします。

  3. 図29-8に示すように、「HTTP基本」タブをクリックして、次を構成します。

    • ログインURL: ログイン・ページのログインURLを入力します。

      ログインURLには、リモート・サーバー上のログイン・ページではなく、HTTP基本認証のユーザー名/パスワードのチャレンジを表示する、保護されたページを指定します。ログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。

    • ログアウトURL: 認証サーバーのログアウトURLを入力します。

      ログアウトURLはログインURLと同じ場合もあれば、セッションで追加アクション(無効化など)を実行するリモート・サーバーへのURLの場合もあります。ログアウトURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。

    図29-8 Basic認証の構成

    このイメージについては周囲のテキストで説明しています。
  4. オプションで、図29-4に示すように、「カスタム・ヘッダー」タブをクリックして、次を構成します。

  5. 「自動ログイン」タブをクリックし、第29.5.9項「ログイン資格証明の格納方法」の説明に従って、パラメータを構成します。

  6. 「認可」タブをクリックし、第29.5.20項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。

  7. 「一般」タブをクリックし、「接続のテスト」をクリックします。

  8. 「OK」をクリックします。

29.5.4 Oracle Mobile and Social Identity Managementを使用して認証を構成する方法

図29-9に示すように、「MAFログイン接続の作成」ダイアログで「Mobile-Social」認証サーバー・タイプを選択して、Oracle Access Manager (OAM)サーバーで認証を行うようにMAFアプリケーションの接続を構成できます。この接続タイプのOAMバックエンドでは、Oracle Mobile and Socialサーバーおよび10g WebGate (リソースに対するHTTPリクエストを捕捉して、認証と認可のためにOAMサーバーに転送するWebサーバー・プラグイン)を実行している必要があります。

図29-9 Mobile-Socialでの認証の構成

このイメージについては周囲のテキストで説明しています。

始める前に

OAMバックエンドがOracle Mobile and Socialサーバーおよび10g Webgateを実行していることを確認します。

OM_PROP_OAMMS_URLプロパティ・キーを使用するようにサーバーを構成します。このURL (プロトコル、ホスト名およびポート番号を含む)は、Mobile and Socialサーバーにアクセスするために必要です。HTTPおよびHTTPSプロトコルのみがサポートされています。OAM_ID CookieをWebサーバー・リクエスト・ヘッダーに挿入するようにサーバーを構成する必要もあります。


注意:

この接続タイプでは、KBA (ナレッジベース認証)が必要です。詳細は、第29.6.2項「ログイン・ページの指定方法」を参照してください。

Oracle Mobile and Socialサーバーを介したOracle Access Managementでの認証を構成するには:

  1. 「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」「Mobile-Social」を選択します。

    「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.5.1項「MAFログイン接続の構成方法」を参照してください。

  2. 「一般」タブで、次を定義します。

    • 接続モード: 表29-1に示すように、認証のタイプを選択します。

    • 接続名: 接続の名前を入力します。

    • アイドル・タイムアウト: MAFがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、MAFによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。


      注意:

      MAFは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を実行しますが、セッション・タイムアウト後にこの認証を実行することはありません。

    • セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。

    • ログイン最大試行回数: ローカル資格証明がクリアされるまでにユーザーに許可する最大ログイン試行失敗回数を設定します。デフォルトで、MAFは、ユーザーに3回のログイン試行の失敗を許可しており、それを超えると、ローカルに格納されているそのユーザーの資格証明をクリアし、以降のログイン試行では、リモート・ログイン・サーバーに接続します。リモート・サーバーに接続した後は、そのユーザーに許可されるログイン試行回数は無制限になります。

      ユーザーがログイン試行を指定した回数失敗すると、ローカル資格証明がクリアされるため、MAFはサーバーに対して認証を実行します。これにより、ユーザーは、管理者がユーザーのパスワードを変更した後、パスワードがデバイス上にまだ格納されていない状態で、この新しいパスワードを使用してログインできるようになります。ローカル認証が許可されている場合、ユーザーがサーバー接続へのログインに成功するとパスワードはデバイス上に安全に格納されます。


      注意:

      アプリケーション機能がローカル認証を使用するように構成されている場合でも、MAFは、ローカルに格納されているユーザー資格証明をクリアします。

  3. 「Mobile-Social」タブをクリックし、Oracle Access Management Mobile and SocialサーバーへのURLを入力し、MAFアプリケーション・サービス・ドメインを入力します。

    また、図29-10に示すように、デバイスでの位置の更新をサーバーで有効化するように接続を構成することもできます。

    図29-10 OAM認証の構成

    このイメージについては周囲のテキストで説明しています。
  4. オプションで、図29-4に示すように、「カスタム・ヘッダー」タブをクリックして、次を構成します。

  5. 「自動ログイン」タブをクリックし、第29.5.9項「ログイン資格証明の格納方法」の説明に従って、パラメータを構成します。

  6. 「認可」タブをクリックし、第29.5.20項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。

29.5.5 OAuth認証の構成方法

図29-11に示すように、「MAFログイン接続の作成」ダイアログを使用して、サードパーティ・アプリケーション(クライアント)がリモート・サーバーに格納されている保護されたデータまたはサービスへの制限付きアクセスを取得する方法を構成できます。Oracle Mobile and Socialサーバーが提供するリライイング・パーティ認証では、アプリケーションがサードパーティOAuthプロバイダに対する認証を実行できます。Oracle Web Services Manager (OWSM) Lite MobileのADFアプリケーション・エージェントは、Webサービス・コールのセキュリティ・ヘッダーにCookieを挿入します。

図29-11 OAuthの構成

このイメージについては周囲のテキストで説明しています。

始める前に

OM_PROP_OAUTH_OAUTH20_SERVERプロパティ・キーを使用するようにサーバーを構成します。

OAuthサーバーでの認証を構成するには:

  1. 「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」「OAuth」を選択します。

    「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.5.1項「MAFログイン接続の構成方法」を参照してください。

  2. 「一般」タブで、次を構成します。

    • 接続名: 接続の名前を入力します。

  3. 「OAuth」タブをクリックし、図29-12に示すように、次を構成します。

    • 「権限タイプ」を選択し、アプリケーションがログイン・ページを取得する場所を決定します。サーバー・ログイン・ページを表示する場合は、「認可コード」を選択します。MAFアプリケーションでデフォルト・ログイン・ページまたはカスタム・ログイン・ページ(構成されている場合)を表示する場合は、「リソース所有者の資格証明」を選択します。

    • 「クライアント識別子」を入力し、オプションで、「クライアント・シークレット」フィールドに接続パスワード値を入力します。

    • 認可サーバーの「リダイレクト・エンドポイント」およびそのエンドポイントのURIを認可サーバー・エンドポイント自体および「トークン・エンドポイント」に入力します。

    • ユーザーのログアウト時にリダイレクトされる「ログアウトURL」を入力します。このフィールドは必須入力で、URLパラメータは特定の認証プロバイダによって決まります。

    • アプリケーション内の組込みブラウザにログイン・ページを表示する場合は、「埋込みブラウザ・モードの有効化」を選択します。外部ブラウザにログイン・ページを表示する場合は選択を解除します。シングル・サインオン(SSO)が必要となる場合は、このオプションを選択解除して、アプリケーションによって外部ブラウザが使用されるようにします。

    図29-12 クライアントIDおよびエンド・ポイントの構成

    このイメージについては周囲のテキストで説明しています。
  4. 「認可」タブをクリックし、第29.5.20項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。

29.5.6 Web SSO認証の構成方法

図29-13に示すように、「MAFログイン接続の作成」ダイアログを使用して、クロスドメイン・シングル・サインオンを構成できます。

図29-13 フェデレーテッドSSO認証の構成

このイメージについては周囲のテキストで説明しています。

Web SSOサーバーでの認証を構成するには:

  1. 「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」「Web SSO」を選択します。

    「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.5.1項「MAFログイン接続の構成方法」を参照してください。

  2. 「一般」タブで、次を構成します。

    • 接続名: 接続の名前を入力します。

    • セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、MAFは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。

  3. 「Web SSO」タブをクリックし、図29-14に示すように、成功したログインおよび失敗したログインを有効化する次のURLを構成します。

    • ログインURL: 訪問時にユーザーに対して資格証明の入力を要求するURLを入力します。ログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。

    • ログアウトURL: サーバー・セッションを終了してユーザーをログアウトする、サーバー側URLを入力します。ログアウトURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースを指すことはできません。

    • ログイン成功URL: ユーザーが認証成功後にリダイレクトされるターゲットURLを入力します。

      ログイン成功URLはログインURLと同じにできます。たとえば、ログインURLとログイン成功URLがhttp://www.mysite.comの場合、ユーザーがブラウザでhttp://www.mysite.comを指定すると、ブラウザはまずサイトのログイン・ページにリダイレクトされ、そこで認証に成功するとhttp://www.mysite.comに再びリダイレクトされます。その後、MAFでは、ログイン成功URLによって指定されたページを検出すると、ログイン・プロセスを完了してリクエストされた機能をアクティブにします。このようにして、ログイン成功URLページの内容がユーザーに表示されることなく、ユーザーはMAF機能にアクセスできるようになります。

    • ログイン失敗URL: ユーザーが認証失敗後にリダイレクトされるURLを入力します。失敗用のURLがない場合は、任意のURLを入力します。

      ブラウザにログイン失敗URLがロードされると、MAFはまずエラーを検出してから、アプリケーションに制御を戻します。これは、MAFアプリケーションによってユーザーの最大ログイン試行回数が制限されている場合に有用です。この場合、ユーザーが許容回数の最後の試行で認証に失敗すると、MAFによってログイン失敗URLにリダイレクトされます。

      失敗用のURLがない場合は、任意のURLを入力しても構いません。この場合、ユーザーがログイン・ページのキャンセル・ボタンをクリックするか、所定の期間内にユーザーアクションが行われなかったためにログインがタイム・アウトすると(非アクティブのタイムアウトは2分)、認証が終了します。

      図29-14 認証URLの構成

      このイメージについては周囲のテキストで説明しています。
  4. 「認可」タブをクリックし、第29.5.20項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。

29.5.7 MAFアプリケーション・ログイン用プレースホルダ接続の構成方法

図29-15に示すように、「MAFログイン接続の作成」ダイアログを使用して、開発時に名前付き接続を作成し、実行時にログイン属性を移入してこの接続の定義を完成させることができます。この接続タイプは、デザインタイムに接続属性の一部がわからない場合に特に便利です。

アプリケーション開発者は、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIを使用して、第29.5.8項「実行時に名前付き接続の接続属性を更新する方法」の説明に従って、デザインタイムに作成されたプレースホルダ接続を完全に定義する必要があります。

図29-15 プレースホルダ接続の構成

このイメージについては周囲のテキストで説明しています。

実行時に定義するためのプレースホルダ接続を構成するには:

  1. 「MAFログイン接続の作成」ダイアログの「認証サーバー・タイプ」「実行時に値を指定」を選択します。

    「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.5.1項「MAFログイン接続の構成方法」を参照してください。

  2. 「一般」タブで接続名を入力します。

    アプリケーション開発者はこの識別子を使用して、第29.5.8項「実行時に名前付き接続の接続属性を更新する方法」の説明に従って、更新する接続を識別します。

  3. 「認可」タブをクリックし、第29.5.20項「アクセス制御の構成方法」の説明に従って、パラメータを構成します。

29.5.8 実行時に名前付き接続の接続属性を更新する方法

アプリケーション開発者は、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIを使用して、プレースホルダ(図29-15に示すように「MAFログイン接続の作成」ダイアログで「実行時に値を指定」を選択した場合)、または完全に設定された接続定義のいずれかによって、すでに存在する接続の接続属性を定義または再定義できます。


注意:

通常のタイミングでは、アプリケーション・ライフサイクル・リスナー内のstart()メソッド実装でAdfmfJavaUtilities.updateSecurityConfigWithURLParameters APIをコールします。このメソッドを機能ライフサイクル・リスナー内からコールしないでください。

configUrlParamパラメータに関連付けられた接続属性を更新するには、updatedSecurityConfigWithURLParametersメソッドを次のようにコールします。

import oracle.adfmf.framework.api.AdfmfJavaUtilities;
...
   AdfmfJavaUtilities.updateSecurityConfigWithURLParameters(configUrlParam,
              key, message, showConfirmation);

keyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして設定されます。このメソッドをshowConfirmationパラメータをtrueに設定して呼び出すと、MAFが既存の接続の属性に対する接続構成の変更を検出した場合にエンド・ユーザーに確認のプロンプトを表示できるようになります。

oracle.adfmf.framework.api.AdfmfJavaUtilitiesクラスおよびconfigUrlParamパラメータの使用の詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスを参照してください。

29.5.9 ログイン資格証明の格納方法

セキュリティが重要でない場合、MAFではユーザー資格証明を格納することがサポートされており、これを(ログイン接続で定義したモードに応じて)ログイン・サーバーに対してリプレイしたり、ユーザーのローカル認証に使用することができます。資格証明を格納すると、ユーザーはログインしないでMAFアプリケーションにアクセスできるようになるため、ユーザーの操作性が向上します。IDM Mobile SDKにより、MAFは次のモードをサポートできるようになります。

  • ユーザー名を記憶: MAFはユーザー名をキャッシュし、ログイン・ページのユーザー名フィールドに移入します。ユーザーがパスワードを入力し、ログイン・ボタンをタップして確認すると、MAFはこれらの資格証明を認証サーバーに対してリプレイします。

  • 資格証明を記憶: MAFはユーザー資格証明をキャッシュし、ログイン・ページのユーザー名フィールドとパスワード・フィールドに移入します。ユーザーがログイン・ボタンをタップしてこれらの資格証明を確認すると、MAFはそれらを認証サーバーに対してリプレイします。

  • 自動ログイン: MAFは、ユーザー資格証明をキャッシュし、これらを以降の認証で認証サーバーに対してリプレイします。このモードでは、ユーザーは、MAFによって資格証明の入力や確認を求められることなくアプリケーションを起動できます。ただし、MAFは新しいアプリケーション・セッションが開始されたことをユーザーに知らせることができます。


注意:

ユーザーは、これらの資格証明をMAFが格納するかどうかを決定できます。

図29-16に示すように、「MAFログイン接続の作成」ダイアログの「自動ログイン」ページを使用して、資格証明格納オプションを選択できます。資格証明オプションを選択すると、ユーザー名とパスワードを記憶するオプションによってログイン・ページが設定されるため、デバイスを複数のエンド・ユーザーが共有する場合は選択しないでください。

図29-16 ユーザー資格証明のキャッシュ

この図は周囲のテキストで説明しています

29.5.10 MAFアプリケーションの接続の作成時に行われる処理

MAFでは、connections.xmlファイル内のすべての接続情報が集約されます(このファイルは、「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルの「ディスクリプタ」および「ADF META-INF」ノードの下にあります)。次の例に示すこのファイルは、アプリケーションにバンドルするか、構成サービスにホストできます。後者の場合、MAFは、アプリケーションが起動されるたびに、更新済の構成情報があるかどうかをチェックします。


注意:

MAFアプリケーションの認証の要件として、JDeveloperでは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>

詳細は、Oracle Fusion Middleware Oracle Application Development FrameworkによるFusion Webアプリケーションの開発のconnections.xmlファイルで定義されている参照に関する項を参照してください。

29.5.11 マルチテナント対応の接続の作成時に行われる処理

「マルチテナント対応」オプションを有効にして、「MAFログイン接続の作成」ダイアログへの入力が完了すると、MAFはtrueに設定された<isMultiTenantAware>要素をconnections.xmlファイルに移入します。マルチテナント接続では、ユーザー名はテナント名とユーザー名の組合せです。

ログイン・ページでは、JavaScriptユーティリティを使用して、接続がマルチテナント対応であるかどうかを識別します。ログイン・ページでそのような接続が検出されると、追加フィールドが表示され、ユーザーは、「MAFログイン接続の作成」(図29-5を参照)で構成したテナント名をそのフィールドに入力する必要があります。(正しいテナントIDの入力を含む)ログインに成功すると、MAFはテナントIDをローカル資格認証ストアに格納します。

29.5.12 ログイン接続構成に関する必知事項

保護されたMAF機能へのアクセス権を付与するためのログインURLをconnections.xmlファイルまたはプログラムを使用して定義する場合、ログインURLはmydocument.txtのようなファイル・リソースを指すことはできません。このログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースが使用されていると、MAFアプリケーションがハングするかログインに失敗して、ユーザーが保護されたMAF機能にアクセスできない場合があります。

29.5.13 ログイン接続とコンテナ化されたMAFアプリケーションに関する必知事項

Oracle Mobile Security Suite (OMSS)のAppTunnel機能を使用して社内リソースにアクセスするには、MAFアプリケーションがリソースにアクセスする場合に使用するURIまたはエンドポイントをプロキシするようにモバイル・セキュリティ・アクセス・サーバー(MSAS)インスタンスを構成する必要があります。詳細は、『Oracle Mobile Security Access Serverの管理』のモバイル・セキュリティ・アクセス・サーバー・アプリケーションの管理およびモバイル・セキュリティ・アクセス・サーバー・インスタンスの構成の各章を参照してください。

HTTP基本認証はOMSSでサポートされていますが、MAFログイン・ページはOMSSの認証プロセスによって非表示にならないため、ユーザーは2回認証を行う必要があります。

コンテナ化されたMAFアプリケーションでの認証の詳細は、第29.4項「コンテナ化されたMAFアプリケーションの認証プロセスの概要」を参照してください。

29.5.14 ローカルおよびハイブリッド・ログイン接続の場合の複数のアイデンティティに関する必知事項

リモート接続と同様、ローカルおよびハイブリッド・ログイン接続モードでは、ユーザーは、アプリケーション・ライフサイクル内で、任意の数のアイデンティティを使用してログインおよびログアウトできます。これらの接続モードを使用するようにログイン接続を定義すると、現在のセッションのタイムアウト期間内に、保護されているアプリケーション機能に前にログインしたユーザーは、ローカル資格証明ストアを使用して、保護されているアプリケーション機能に再びログインできます。この場合、明示的にログアウトしたユーザー、またはアイドル・タイムアウトが経過したためにログアウトしたユーザーは、保護されているアプリケーション機能(またはそのアプリケーション機能を保護しているログイン・サーバーにより保護されている他のアプリケーション機能)に再びログインできます。


注意:

ローカルおよびハイブリッド接続は、Basic認証、およびOracle Access Management Mobile and Social (OAMMS)への認証にのみ使用できます。OAuthおよびフェデレーテッドSSOは、リモート認証を使用するため、アプリケーション・ユーザーは、認証に成功しないかぎり、再びログインすることはできません。

29.5.15 MAFアプリケーションおよび認証モードの移行に関する必知事項

MAFアプリケーションを移行する場合、maf-feature.xmlで定義されている認証モード(<adfmf:feature id="feature1" name="feature1" credentials="remote">など)が、connections.xmlファイルのauthenticationMode属性で定義されていることを確認する必要があります。credentials属性の存在を検出するJDeveloperの監査ルールを使用すると、その属性をmaf-feature.xmlから削除するのに役立ちます。

connections.xmlファイルのauthenticationMode属性は、remoteまたはlocalとしてのみ定義できるため、none (<adfmf:feature id="feature1" name="feature1" credentials="none">)の値を移行しないでください(移行すると、デプロイメントが失敗します)。

29.5.16 カスタム・ヘッダーに関する必知事項

カスタム・ヘッダーを定義して、「MAFログイン接続の作成」ダイアログへの入力が完了すると、MAFはcustomAuthHeaders要素と各headerサブ要素をconnections.xmlファイルに移入します。

カスタム・ヘッダーの値が実行時に指定される場合、MAFアプリケーションはoracle.adfmf.framework.api.AdfmfJavaUtilitiesクラスのOverrideConnectionHandler APIを使用してヘッダー値を構成できます。oracle.adfmf.framework.api.AdfmfAuthConnectionクラスには、connection.xmlの各XML要素にアクセスし、オーバーラドする場合には最新の値を取得する便利なメソッドが用意されています。APIを使用してヘッダーを構成する方法の詳細は、第29.5.23項「認証の前にログイン資格証明をプログラムで構成する方法」を参照してください。

(正しいヘッダー値を入力して)ログインに成功すると、MAFはヘッダーの詳細をローカル資格証明ストアに格納し、RESTサービスに対して行われるような安全な呼出しを許可して、カスタム・ヘッダーをHTTPリクエストに追加します。

29.5.17 実行時に行われる処理: MAFがREST Webサービスをコールした場合

ユーザーがローカルに認証されると、MAFはMAFアプリケーションがREST Webサービスをコールしたときにログイン・サーバーに対してユーザーをサイレントに認証します。ユーザーの資格証明が認証されると、MAFはREST Webサービスに対するアプリケーションのリクエストを実行します。REST Webサービスが401ステータス・コード(未許可)を戻した場合、MAFはユーザーに再度の認証を指示します。REST Webサービスが302コード(検出または一時的に移動されました)を戻した場合、MAFはログイン・サーバーをチェックして、ユーザーが認証されているかどうかを確認します。そうである場合、コードは302リダイレクトとして処理されます。

ユーザーがログイン・サーバーに対して認証されていない場合、MAFはユーザーに再度の認証を指示します。場合によっては、ログイン・サーバーが、302ステータス・コードを戻したときに、サーバー独自のWebページを使用した認証をユーザーに指示する場合があります。MAFでは、このような場合のリダイレクションをサポートしておらず、かわりにMAFログイン・ページを使用して再度ログインすることをユーザーに指示します。

29.5.18 基本認証ヘッダーの挿入に関する必知事項

アプリケーション機能の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>

29.5.19 Webサービス・セキュリティに関する必知事項

Webサービス用のログイン・ページはなく、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービス・コールのヘッダーに資格証明が挿入されます。Webサービスは、ローカルに格納されている資格証明(ユーザーによる認証サーバーへの最初のログインの成功後、MAFによって保持されている資格証明)を使用してアプリケーション・データにアクセスします。

ローカル資格証明ストアの名前は、ログイン・サーバー接続のadfCredentialStoreKey属性に反映されます(第29.5.10項「MAFアプリケーションの接続の作成時に行われる処理」adfCredentialStoreKey="Connection_1"など)。Webサービスがこの資格証明ストアを使用できるようにするには、SOAPまたはREST Webサービス接続のadfCredentialStoreKey属性に対して定義されている名前が、ログイン・サーバーのadfCredentialStoreKey属性に対して定義されている名前と一致する必要があります。connections.xmlファイルのadfCredentialStoreKey属性またはログイン接続名を編集する場合、それぞれ同じ値になるように設定してください。同じ値を維持できないと、MAFのランタイム例外が発生します


注意:

connections.xmlファイルの概要エディタはないため、「プロパティ」ウィンドウを使用して、<Reference>要素のadfcredentialStoreKey属性をログイン・サーバー接続のadfCredentialStoreKey属性用に構成されている名前で更新できます。または、「ソース」エディタを使用して属性を追加または更新できます。

詳細は、第15.7.4項「資格証明の挿入に関する必知事項」を参照してください。

29.5.20 アクセス制御の構成方法

アクセス制御サービス(ACS)は、JSONを使用したRESTful Webサービスであり、オプションでMAFアプリケーションとは別の外部サーバー上にデプロイすることができます。通常は、アプリケーション機能に保護されたコンポーネントが含まれている場合に、ユーザーが単一のHTTP POSTメッセージを介して自身のユーザー・ロールと権限をダウンロードできるよう、MAFアプリケーションにACSサービスを提供します。このサービスをアプリケーションに提供する場合は、ACSサービスを実装してホストする必要があります(MAでは、このサービスは提供されません)。図29-17は、「MAFログイン接続の作成」ダイアログの「認可」ページを示したもので、このページを使用してMAFアプリケーションのアクセス制御を構成します。

図29-17 アクセス制御の構成

この図は周囲のテキストで説明しています

アプリケーション・ログイン・サーバーによって付与されるアクセス制御は、第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は、取得されたユーザー・ロールと権限に照らして各アプリケーション用に構成されている制約を評価し、関連付けられているすべての制約を満たすユーザーのみがアプリケーション機能を使用できるようにします。

アクセス制御を構成するには:

  1. 「MAFログイン接続の作成」ダイアログで、「認可」タブをクリックします。

    「MAFログイン接続の作成」ダイアログを開く方法の詳細は、第29.5.1項「MAFログイン接続の構成方法」を参照してください。

  2. 「認可」ページで、図29-17に示すように、認可要件を入力します。

    • レルム: 開発時に把握している場合は、基本認証ヘッダーに追加するリクエスト・レルムを指定します(MAFはこの基本認証ヘッダーをHTTPリクエストに挿入します)。

      詳細は、第29.5.18項「基本認証ヘッダーの挿入に関する必知事項」を参照してください。

    • アクセス制御サービスURL: アクセス制御サービス(ACS)のエンド・ポイントであるURLを入力します。

    • ユーザー・ロールのフィルタ・リスト: アプリケーション機能によってチェックされるユーザー・ロールを入力します。セキュリティ・システムには、数千もの定義済のユーザー・ロールおよび権限が存在する可能性があるため、アプリケーション機能に固有のロールが記載されているマニフェスト(これは、アプリケーション機能の開発者によって提供されます)を使用して、このリストを作成します。

    • 権限のフィルタ・リスト: アプリケーション機能によってチェックされる権限を入力します。

29.5.21 アクセス制御サービスに関する必知事項

アクセス制御サービス(ACS)は、ユーザーが単一のHTTP POSTメッセージを介して自身のユーザー・ロールと権限をダウンロードできるようにする、JSONを使用したRESTful Webサービスです。これは、特定のユーザーのロールまたは権限(あるいはその両方)を戻すリクエスト・メッセージです。必要なロールと権限のリストを提供することで、特定のロールと権限を戻すこともできます。リクエスト・メッセージは、次のもので構成されています。

  • リクエスト・ヘッダー・フィールド: If-MatchAccept-LanguageUser-AgentAuthorizationContent-TypeContent Length

  • リクエスト・メッセージ本文: ユーザー情報のリクエスト。

  • 次のものが含まれている、リクエストされたJSONオブジェクト:

    • userId: ユーザーID。

    • filterMask: ユーザー・ロールと権限のいずれのフィルタを使用する必要があるのかを判断するために使用される"role"要素と"privilege"要素の組合せ。

    • roleFilter: ユーザー情報をフィルタ処理するために使用されるロールのリスト。

    • privilegeFilter: ユーザー情報をフィルタ処理するために使用される権限のリスト。


注意:

すべてのロールを戻す必要がある場合は、filterMask配列に"role"要素を含めないでください。

すべての権限を戻す必要がある場合は、filterMask配列に"privilege"要素を含めないでください。


次の例は、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-ModifiedContent-TypeおよびContent-Length

  • ユーザー情報の詳細を含むレスポンス・メッセージ本文。

  • 戻されるJSONオブジェクト。これには次のものが含まれます。

    • userId: ユーザーのID。

    • roles: ユーザー・ロールのリスト。これは、リクエスト内のroleFilter配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられているロールのリスト全体が戻されます。

    • privileges: ユーザーの権限のリスト。これは、リクエスト内のprivilegeFilter配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられている権限のリスト全体が戻されます。

次の例は、ユーザーJohn Smithに割り当てられたユーザー名およびロールと権限を含む、戻されるJSONオブジェクトを示します。

Content-Type: application/json
 
{
        "userId": "johnsmith",
        "roles": [ "role1" ],
        "privileges": ["priv1", "priv3"] 
}

注意:

Webサービスでは、ログイン・ページはありませんが、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービスのヘッダーに自動的に資格証明が追加されます。詳細は、第15.7.4項「資格証明の挿入に関する必知事項」を参照してください。


注意:

ACSサービスを実装してホストする必要があります(MAFモバイルでは、このサービスは提供されません)。

29.5.22 アプリケーションのロード順序の変更方法

MAFは、図29-17に示すように、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リクエストに挿入できます。第29.5.18項「基本認証ヘッダーの挿入に関する必知事項」に示すように、keyパラメータはconnections.xmlファイルのadfCredentialStoreKeyパラメータに対して定義された値からStringオブジェクトとして戻されます。appLoginパラメータは、ACSが機能アクセスを再評価するようにtrueに設定できます。OptionalExtraPayLoadパラメータは今後使用するために予約されており、使用されていません。

invokeACSメソッドまたはisAcsCalledAutomaticallyパラメータを使用してACSを呼び出すと、アプリケーションのロールベース制約が取得されます。


注意:

MAFは、<isAcsCalledAutomatically value = "false"/>connections.xmlファイルに含まれていない場合、ログインの成功後、ACSを自動的に呼び出します。

保護されているアプリケーション機能がinvokeACSメソッドをコールすると、MAFは、アプリケーション・ログイン接続に関連付けられたすべてのアプリケーション機能のユーザー制約(保護されているアプリケーション機能に構成されている制約を含む)をフェッチします。保護されていないアプリケーション機能がこのメソッドをコールすると、MAFはログイン接続に関連付けられた制約のみを取得します。


注意:

invokeACSメソッドに加え、AdfmfJavaUtilitiesクラスには次のライフサイクル・メソッドが含まれます。
  • applicationLogout: アプリケーション・ログイン接続をログアウトします。

  • featureLogout(<feature_ID>): アプリケーション機能に関連付けられたログイン接続をログアウトします。

詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスを参照してください。


29.5.23 認証の前にログイン資格証明をプログラムで構成する方法

MAFアプリケーションがログイン接続を起動してユーザーを認証する前に、プログラムを使用して接続値を設定できます。この方法は通常、「MAFログイン接続の作成」ダイアログでカスタム・ヘッダー名を定義し、値は実行時に指定する場合に必要になります。接続の詳細をプログラムで構成するには、MAFアプリケーションでoracle.adfmf.framework.api.AdfmfJavaUtilitiesクラスのOverrideConnectionHandler APIを呼び出すことができます。このAPIは現在の接続プロパティ値を新しい値でオーバーライドし、アプリケーションがオーバーライドされた値でログインを開始できるようにします。

接続値をプログラムでオーバーライドするには、一般的に次のプロセスを伴います。

  1. オーバーライドするプロパティを定義するXML要素の名前をconnections.xmlファイルから取得します。

  2. 認証の前にオーバーライド値を取得します。たとえばMAFアプリケーションでは、これに対応して、エンド・ユーザーに値の入力を要求するようにAMXページを定義できます。

  3. オーバーライド・メソッドを(接続プロパティのオーバーライドごとに1つずつ)実装して接続プロパティのgetterメソッドとsetterメソッドを定義するマネージドBeanを起動します。たとえば、AMXページの場合、エンド・ユーザーがコマンド・ボタンをクリックすると、そのユーザーの入力値がマネージドBean上で送信されます。

接続プロパティのオーバーライドを指定するには、connections.xmlファイルを調べて、次のXML要素の定義を取得します。

  • 接続参照名。たとえば、ConnWithCustomHeaderなどです。

  • オーバーライドする属性を定義するプロパティのXML要素名。たとえば、テナントのドメイン名を伝播する場合に使用するスキームのmultiTenantSchemeなどです。

  • オーバーライドするプロパティの属性のXMLサブ要素名。一意の接続プロパティの場合、これは常にvalue要素です。


注意:

カスタム・ヘッダーの場合、すべてのカスタム・ヘッダー定義で同じ要素名を使用して値を指定するため、XML要素のheadervalueは使用しないでください。かわりに、カスタム・ヘッダーでは、オーバーライド・メソッドに渡すプロパティと属性に、それぞれContentscustomAuthHeadersを使用します。

たとえば、カスタム・ヘッダーの値をオーバーライドするには、次のconnections.xmlファイルで、接続名ConnWithCustomHeaderContents要素および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で接続プロパティのオーバーライドごとにオーバーライド・メソッドを実装します。次の例では、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);
    }
}

29.6 MAFアプリケーションのセキュリティの構成

maf-feature.xmlmaf-application.xmlファイルの概要エディタ、および「MAFログイン接続の作成」ダイアログを使用して、セキュリティを構成します。概要エディタを使用すると、認証を必要とするアプリケーション機能をユーザーが選択したときにMAFによって表示されるログイン・ページのタイプ(デフォルトまたはカスタム)を指定したり、ユーザー・ロールまたはユーザー権限ベースの制約を含めることができます。また、セキュリティが必要な埋込みアプリケーション機能を選択することもできます。

29.6.1 認証を要求するようにアプリケーション機能を設定する方法

セキュリティが適用されるように各アプリケーション機能を定義できます。残りのセキュリティ構成は、maf-application.xmlの概要エディタの「セキュリティ」ページを使用して実行します。アプリケーション機能のコンテンツがリモートURLから提供される場合に、この概要エディタを使用すると、リモートURLのコンテンツをMAFのWebビューに表示できるように、ドメインをホワイトリストできます。詳細は、第20章「リモートURLを使用したアプリケーション機能コンテンツの実装」を参照してください。

図29-18に示されているmaf-feature.xml概要エディタでは、セキュリティを適用するアプリケーション機能を指定できます。

図29-18 アプリケーション機能に対するユーザー資格証明オプションの指定

この図は周囲のテキストで説明しています

始める前に

機能のセキュリティを有効にすると、アプリケーションでは、ユーザーを認証するためにネットワークにアクセスする必要があります。ネットワーク・ソケットへのアプリケーション・アクセス権の付与の詳細は、第9.2項「MAFアプリケーションでのコア・プラグインの有効化」を参照してください。

アプリケーション機能に対するユーザー・アクセスを指定するには:

  1. ナビゲータのユーザー・インタフェース・プロジェクトで、「アプリケーション・ソース」および「META-INF」フォルダ・ノードを開いてから、maf-feature.xmlをダブルクリックします。

  2. maf-feature.xmlファイルの概要エディタで、「機能」表にリストされているアプリケーション機能を選択するか、または「追加」をクリックしてアプリケーション機能を追加します。

  3. ログインが必要なすべてのアプリケーション機能に「セキュリティ有効化」を選択します。


    ヒント:

    このオプションをデフォルト・アプリケーションに適用しない場合、ユーザーは匿名でログインできます(つまり、ログイン資格証明を提示する必要がありません)。ユーザーは、保護されていないデータや機能にアクセスでき、必要に応じてログインできます(認証されたユーザーは保護されたデータと保護されていないデータの両方にアクセスできます)。MAFアプリケーション内に保護されていないアプリケーション機能を提供すると、ユーザーは保護されているアプリケーション機能からログアウトするが、アプリケーション自体に残って、保護されていないアプリケーション機能とデータの両方に引き続きアクセスできます。

29.6.2 ログイン・ページの指定方法

アプリケーション機能のセキュリティを指定したら、図29-19に示されているmaf-application.xml概要エディタの「セキュリティ」ページを使用して、セキュリティが適用される各アプリケーション機能に対して、ログイン・ページの構成およびログイン・サーバーへの接続の作成と割当てを行います。このページにリストされているすべてのアプリケーション機能は、maf-feature.xmlファイルで、セキュリティが必要なものとして指定されています。

通常、アプリケーション機能のグループは、同じログイン・サーバー接続で保護され、ユーザーは、MAFから再度ログインを求められることなく、これらのアプリケーションをどれでも開くことが可能です。ただし、場合によっては、あるアプリケーション機能のセットを保護しているログイン・サーバーと、別のアプリケーション機能のセットを保護しているログイン・サーバーが異なるため、アプリケーション機能で要求される資格証明がそれぞれ異なる可能性があります。このような状況に対応するために、MAFアプリケーション用のログイン・サーバーへの接続をいくつも定義できます。maf-application.xmlファイルでは、機能参照に関連付けられている認証サーバー接続は、次のようにloginConnRefId属性を使用して指定されます。

<adfmf:featureReference refId="feature1" loginConnRefId="BasicAuthentication"/>
<adfmf:featureReference refId="feature2" loginConnRefId="OAMMS"/>

MAFアプリケーションは、HTTPまたはHTTPS経由のBasic認証をサポートしている標準のログイン・サーバーなら、どのログイン・サーバーに対しても認証を受けることが可能です。MAFはまた、Oracle Identity Managementに対する認証もサポートしています。特定のアプリケーション機能用のカスタム・ログイン・ページを選択することもできます。詳細は、第29.6.4項「ログイン・ページに関する必知事項」を参照してください。


注意:

デフォルトでは、保護されているすべてのアプリケーション機能が同じ接続を共有します。この接続は、図29-19に示されているように、<application login server>と表示されます。「機能参照」の「プロパティ」ウィンドウには、このデフォルト・オプションが「ログイン・サーバー接続」ドロップダウン・メニューに<default> (application login server)と表示されます。「MAFログイン接続の作成」ダイアログを使用して、MAFアプリケーション用に定義されている他の接続を選択できます。

図29-19 maf-application.xmlの概要エディタの「セキュリティ」ページ

この図は周囲のテキストで説明しています

始める前に

MAFアプリケーションでカスタム・ログイン・ページを使用する場合は、アプリケーション・コントローラ・プロジェクトのpublic_htmlディレクトリ(JDeveloper\mywork\Application\ApplicationController\public_html)にファイルを追加して、図29-20に示されているように「アプリケーション・ナビゲータ」の「Webコンテンツ」ノードからそれを使用できるようにします。第29.6.3項「カスタム・ログインHTMLページまたはカスタムKBAページの作成方法」および第5.4項「外部リソースの選択に関する必知事項」も参照してください。

第22.2.4項「ユーザー制約とアクセス制御について」の説明に従って、ユーザー権限とロール用の制約を追加します。

アクセス制御サービス(ACS)・サーバーをプロビジョニングします。詳細は、第29.5.21項「アクセス制御サービスに関する必知事項」を参照してください。

図29-20 カスタム・ログイン・ページの追加

この図は周囲のテキストで説明しています

ログイン・ページおよびKBAページを指定するには:

  1. ナビゲータで、「アプリケーション・リソース」パネルを開き、「ディスクリプタ」および「ADF META-INF」フォルダ・ノードを開いて、maf-application.xmlをダブルクリックします。

  2. maf-application.xmlファイルの概要エディタで、「セキュリティ」ナビゲーション・タブをクリックします。

  3. 「セキュリティ」ページで、ログイン・ページのタイプを指定します。

    • ユーザー名とパスワードを受け入れるビューの「ログイン・ページ」を選択します。

    • 資格証明に対するチャレンジをユーザーに表示し、ユーザーの答えを受け入れるナレッジベース認証(KBA)ビューの場合は、「KBAページ」を選択します。ナレッジベース認証はOAAMサーバー上に構成でき、別のページで、母の旧姓などの追加の質問に対する入力をユーザーに求めることができます。この機能は、Mobile-Social認証タイプでのみ使用できます。

  4. 次のように、選択したログイン・ページ、およびオプションで選択したKBAページのコンテンツ(またはユーザー・インタフェース)を選択します。

    • デフォルト: 選択されたすべての埋込みアプリケーション機能で使用されるデフォルト・ログイン・ページまたはKBA画面。詳細は、第29.6.4.1項「デフォルト・ログイン・ページ」を参照してください。デフォルト・ログイン・ページおよびデフォルトKBAページは、MAFによって提供されているものです。

    • カスタム: 「参照」をクリックして、アプリケーション・コントローラ・プロジェクト内のファイルのパスの場所を検索します。または、「新規」をクリックして、ログイン・ページまたはKBAページ用のカスタムHTMLページをアプリケーション・コントローラ・プロジェクト内に作成します。詳細は、第29.6.4.2項「カスタム・ログイン・ページ」および第29.6.3項「カスタム・ログインHTMLページまたはカスタムKBAページの作成方法」を参照してください。


      ヒント:

      「参照」機能を使用してログイン・ページの場所を検索するのではなく、「アプリケーション・ナビゲータ」からログイン・ページをフィールドにドラッグできます。

29.6.3 カスタム・ログインHTMLページまたはカスタムKBAページの作成方法

ログイン・ページ以外での認証が必要な場合、ナレッジベース認証(KBA)がOAMサーバー上に構成されていると、ナレッジベース認証ページを有効にできます。KBA画面では、母の旧姓などの追加情報を要求することで、追加のチャレンジがユーザーに表示されます。ログイン・ページと同様、KBA画面はカスタマイズできます。

MAFのデプロイメントによってwwwディレクトリ内に生成されるアーティファクトであるデフォルトのログイン・ページ(adf.login.htmlまたはadf.kba.html)を変更すると、カスタム・ログイン・ページを作成できます。

始める前に

wwwディレクトリ内のログイン・ページにアクセスするには、MAFアプリケーションをデプロイした後、deployディレクトリに移動します。iOSデプロイメントの場合、ページは次の場所にあります。

application workspace directory/deploy/deployment profile name/temporary_xcode_project/www/adf.login.html

および

application workspace directory/deploy/deployment profile name/temporary_xcode_project/www/adf.kba.html

Androidデプロイメントの場合、ページは、次の場所にあるAndroidアプリケーション・パッケージ(.apk)ファイル内に配置されます。

application workspace directory/application name/deploy/deployment profile name/deployment profile name.apk/assets/www/adf.login.html

および

application workspace directory/application name/deploy/deployment profile name/deployment profile name.apk/assets/www/adf.kba.html

カスタム・ログイン・ページを作成するには:

  1. デフォルト・ログイン・ページを、ユーザー・インタフェース・プロジェクトのpublic_htmlディレクトリ内の場所(JDeveloper\mywork\application name\ApplicationController\public_htmlなど)にコピーします。

  2. ログイン・ページの名前を変更します。

  3. ページを更新します。

  4. maf-application.xmlファイルの概要エディタの「セキュリティ」ページで、「カスタム」を選択し、「参照」をクリックしてログイン・ページの場所を検索します。

29.6.4 ログイン・ページに関する必知事項

アプリケーション機能の認証プロセスのエントリ・ポイントは、activateライフサイクル・イベントです(第11章「MAFアプリケーションでのライフサイクル・リスナーの使用方法」を参照)。アプリケーション機能がアクティブ化されるたびに(つまり、アプリケーション機能のactivateイベント・ハンドラがコールされるたびに)、アプリケーション機能ログイン・プロセスは実行されます。このプロセスは、ログイン・ページ(デフォルトまたはカスタムのログイン・ページのいずれか)に移動し、そこでユーザー認証が必要かどうかを判断します。ただし、プロセスがログイン・ページに移動する前に、本来意図されていたアプリケーション機能をMAFに登録する必要があります。認証が成功すると、ログイン・ページは、MAFから本来意図されていた宛先を取得し、そこに移動します。

29.6.4.1 デフォルト・ログイン・ページ

MAFによって提供されるデフォルトのログイン・ページは、ログイン・ボタンと、ユーザー名、パスワード、マルチテナント名(オプション)用の入力テキスト・フィールド、およびエラー・メッセージ・セクションから構成されます。これは、HTMLで記述されたクロス・プラットフォーム・ページです。図29-21は、デザインタイムでマルチテナント対応オプションを有効にしたデフォルトのログイン・ページを示し、このページでは、ユーザー名とパスワードの他、テナントのドメイン名の入力が要求されます。

図29-21 マルチテナント・ドメイン・フィールドを備えたデフォルトのログイン・ページ

この図は周囲のテキストで説明しています

29.6.4.2 カスタム・ログイン・ページ

maf-application.xmlファイルの概要エディタを使用して、選択したアプリケーション機能用のカスタム・ログイン・ページを追加すると、JDeveloperは、次の例に示されているように、<adfmf:login>要素を追加し、その子要素<adfmf:LocalHTML>を設定します。すべての<adfmf:LocalHTML>要素と同様に、そのurl属性は、public_htmlディレクトリ内の場所を参照します。ユーザー認証メカニズムとナビゲーション・コントロールは、デフォルトのログイン・ページと同じものになります。

<adfmf:login defaultConnRefId="Connection_1">
    <adfmf:localHTML url="newlogin.html"/>
</adfmf:login>

カスタム・ログイン・ページはHTMLで記述されています。ログイン・ページとナレッジベース(KBA)・ページの両方のフィールドには、具体的に定義された<input>要素および<label>要素を含める必要があります。


ヒント:

カスタム・ログイン・ページを作成するためのガイドとしてMAFアプリケーションのデプロイ時に生成されたデフォルトのログイン・ページを使用します。wwwディレクトリ内のログイン・ページにアクセスするには、MAFアプリケーションをデプロイした後、deployディレクトリに移動します(第29.6.3項「カスタム・ログインHTMLページまたはカスタムKBAページの作成方法」を参照)。

次の例は、デフォルト・ログイン・ページに必要な<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"/>

次の例は、KBAログイン・ページの必須要素を示しています。

<input type="text"

<label id="oracle_access_kba_ques_id" >Question</label><br>
 
<input class="field-value"
       name="oracle_access_kba_ans_id"
       id="oracle_access_kba_ans_id">
   </input>
 
<label id="oracle_access_error_id"
       class="error-text">
   </label>
 
<label id="message_id"
      class="message-text">
   </label>
 
<input type="button"
       onclick="oracle_access_sendParams(this.id)"
       value="Login"
       id="oracle_access_submit_id"/>

29.6.5 ログイン・ページ要素に関する必知事項

各HTMLログイン・ページに、表29-2にリストされたユーザー・インタフェース要素が含まれている必要があります。

表29-2 ログイン・ページのフィールドおよび関連するID

ページ要素 ID

ユーザー名フィールド

oracle_access_user_id

パスワード・フィールド

oracle_access_pwd_id

ログイン・ボタン

oracle_access_submit_id

取消ボタン

oracle_access_cancel_id

アイデンティティ・ドメイン/テナント名フィールド

oracle_access_iddomain_id

KBA質問フィールド(読取り専用/ラベル)

oracle_access_kba_ques_id

KBA回答フィールド

oracle_access_ans_id

エラー・フィールド

oracle_access_error_id

自動ログイン・チェックボックス

oracle_access_auto_login_id

資格証明を記憶チェックボックス

oracle_access_remember_credentials_id

ユーザー名を記憶チェックボックス

oracle_access_remember_username_id


表29-3には、OnClickイベントで使用される、推奨のJavaScriptコードがリストされています。

表29-3 OnClickイベントで使用されるJavaScript

ボタン JavaScript

ログイン・ボタン

oracle_access_sendParams(this.id)

取消ボタン

oracle_access_sendParams(this.id)

KBA送信ボタン

oracle_access_sendParams(this.id)

KBA取消ボタン

oracle_access_sendParams(this.id)


29.6.6 アプリケーション機能用セキュリティの構成時のJDeveloperでの処理

セキュリティが適用されるようにアプリケーション機能が指定されると、JDeveloperは、図29-19に示されているように、対応する機能参照で「セキュリティが有効な機能」の表を更新します。参照される各アプリケーション機能が、connections.xmlファイル内に定義されている同じログイン・サーバー接続に対して認証を行うと、JDeveloperは、defaultConnRefId属性を使用して定義されている単一の<adfmf:login>要素(<adfmf:login defaultConnRefId="Connection_1">など)でmaf-application.xmlファイルを更新します。

connections.xmlファイル内に定義されている別のログイン・サーバー接続を使用するように構成されているアプリケーション機能の場合は、JDeveloperは、参照される各アプリケーション機能をloginConnReference属性(<adfmf:featureReference refId="feature2" loginConnRefId="Connection2"/)で更新します。詳細は、第29.6.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照してください。また、Oracle Fusion Middleware Oracle Mobile Application Frameworkのタグ・リファレンスも参照してください。

29.7 デバイス機能へのアクセスの許可

デバイス機能へのアクセスは、MAFアプリケーションに組み込まれているCordovaプラグインによって定義されます。コア・プラグインのセットはMAFによって提供されます。これらのプラグインの1つを有効にすると、そのプラグインに必要なすべてのデバイス・アクセス権限が有効になります。MAFアプリケーションに組み込まれている他のCordovaプラグインも、必要なデバイス・アクセス権限を有効にします。

MAFアプリケーションの大多数ではネットワーク・アクセスが必要なため、ネットワークにアクセスする権限はデフォルトで有効になっています(デフォルトで有効になっている唯一のデバイス機能)。

  • ネットワーク情報: アプリケーションによるネットワーク・ソケットのオープンを許可します。少なくとも1つのデバイス機能のセキュリティが有効な場合、ネットワーク・アクセス機能は有効にしておく必要があります。

デバイス機能の有効化または制限が可能なため、デプロイメント・フレームワークによって更新されるプラットフォーム固有の様々な構成ファイルやマニフェスト・ファイルでは、使用中のデバイス機能(または、MAFアプリケーションに使用が登録されているプラグイン)のみがリストされます。これらのファイルにより、MAFはこれらの機能の使用に関する情報を他のアプリケーションと共有できます。たとえば、AppStoreやGoogle Playに対して、MAFアプリケーションで場所ベースの機能が(搭載されていても)使用されていないことを通知できます。

MAFアプリケーションのCordovaプラグインの詳細は、第9章「MAFアプリケーションでのプラグインの使用方法」を参照してください。

29.8 アプリケーション機能からのユーザーのログアウトの有効化

MAFでは、保護された内容が含まれるか、制約により制限されているアプリケーション機能からユーザーがログアウトした場合、アプリケーション機能は終了されず、ユーザーはアプリケーション内に残り、匿名ユーザーとして保護されていない内容や機能にアクセスできます。MAFでは制約を再度初期化できるため、ユーザーは同じアイデンティティを使用してアプリケーションに繰り返しログインできます。また、ユーザーが異なるアイデンティティを使用してログインできることにより、複数のアイデンティティでアプリケーションへのアクセスを共有することもできます。

Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスで説明しているAdfmfJavaUtilitiesクラスのlogoutFeatureおよびlogoutメソッドにより、ユーザーはアプリケーションの起動後、認証サーバーに対する明示的なログインおよびログアウトを実行できます。また、これらにより、ユーザーは保護されたアプリケーション機能を呼び出した後に認証サーバーにログインできます。ユーザーは個々のアプリケーション機能からログアウトできますが、同じ接続によって保護されているアプリケーション機能からも同時にログアウトすることになります。

これらのメソッドを使用して、ユーザーは次のことを実行できます。

  • アプリケーション機能からログアウトするが、保護されていないコンテンツへのアクセスを継続します(つまり、MAFはアプリケーションを終了しません)。

  • ログイン・サーバーで認証する一方、アプリケーションで、保護されているそのコンテンツおよびUIコンポーネントを有効化します。

  • MAFアプリケーションまたはアプリケーション機能からログアウトし、別のアイデンティティを使用して再びログインします。

  • MAFアプリケーションまたはアプリケーション機能からログアウトし、ロールと権限が更新された同じアイデンティティを使用して再びログインします。

現在の認証サーバーからのログアウトを有効にするには、次のようにAdfmfJavaUtilitiesクラスのlogoutメソッドをコールします。次に例を示します。

import oracle.adfmf.framework.api.AdfmfJavaUtilities;
...
   AdfmfJavaUtilities.logout();

keyパラメータに関連付けられた認証サーバーからのログアウトを有効にするには、次のようにlogoutFeatureメソッドをコールします。

import oracle.adfmf.framework.api.AdfmfJavaUtilities;
...
   AdfmfJavaUtilities.logoutFeature(adfCrendentialStorykey);

adfCredentialStorykeyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして戻されます。AdfmfJavaUtiltiesクラスおよびkeyパラメータの使用方法の詳細は、Oracle Fusion Middleware Oracle Mobile Application Framework Java APIリファレンスを参照してください。

29.9 SSLのサポート

MAFは、cacerts証明書ファイル(クライアント・アプリケーションとサーバー間のHTTPSハンドシェイクのJavaメカニズム)を提供します。JDeveloperは、アプリケーション・リソースのSecurityフォルダ内にこのファイルを作成します(JDeveloper\mywork\application name\resources\Security\cacertsにあります)。MAFのcacertsファイルにより、信頼できる既知のソースからの一連の証明書がJVMに対して識別され、デプロイメントが可能になります。カスタム証明書を必要とするアプリケーションでは(RSA暗号化が使用されていない場合など)、アプリケーションをデプロイする前にプライベート証明書を追加する必要があります。

始める前に

cacertsファイルの内容を理解しておくと役立ちます。詳細は、『Oracle Mobile Application Framework Oracle Mobile Application Frameworkのインストール』のMAFの新しいSSL用cacertsファイルへの移行に関する項を参照してください。

JDeveloperによるcacertsファイルの作成方法についても理解しておくと役立ちます。詳細は、第C.2項「アプリケーション・コントローラ・プロジェクト・レベルのリソースについて」を参照してください。

cacertsファイルおよびkeytoolユーティリティの使用方法については、Java SEテクニカル・ドキュメント(http://download.oracle.com/javase/index.html)を参照してください。

プライベート証明書を追加するには:

  1. プライベート証明書を作成します。たとえば、new_certという証明書ファイルを作成します。

  2. 次のようにして、プライベート証明書をアプリケーションに追加します。

    1. シードされたcacertsファイル(cp cacerts cacerts.org)のコピーを作成します。

    2. Java SE keytoolユーティリティを使用して、cacertsファイルに証明書を追加します。次の例は、new_certというcacertsファイルへの単一の資格証明の追加を示しています。

      keytool -importcert              
              -keystore cacerts 
              -file new_cert
              -storepass changeit
              -noprompt
      

      各証明書に対して同じ手順を繰り返します。表29-4には、keytoolのオプションがリストされています。

      表29-4 証明書の追加に関するオプション

      オプション 説明

      -importcert

      証明書をインポートします。

      -keystore cacerts file

      インポートされた証明書のファイルの場所を特定します。

      -file certificate file

      新しい証明書を含むファイルを特定します。

      -storepass changeit

      cacertsファイルのパスワードを提供します。デフォルトでは、パスワードはchangeitです。

      -noprompt

      証明書を信頼するかどうかを(stdinを介して)ユーザーに確認しないように、keytoolに指示します。


    3. 新しいcacertsファイルの内容を目で見て調べて、すべてのフィールドが正しいことを確認します。次のコマンドを使用します。

      keytool -list -v -keystore cacerts | more
      
    4. 証明書が指定のホスト名に対するものであることを確認します。


      注意:

      証明書の共通名(CN)は、ホスト名と正確に一致している必要があります。

    5. JVMが読み取れるようにするために、カスタマイズされた証明書ファイルはSecurityディレクトリ(JDeveloper\mywork\application name\resources\Security)に確実に配置してください。

  3. アプリケーションをデプロイします。


    注意:

    デプロイメント時、証明書ファイルがSecurityディレクトリに存在している場合、MAFは、それをAndroidまたはXcodeテンプレート・プロジェクトにコピーし、cacertsファイルのデフォルト・コピーを置き換えます。

  4. 保護されているリソースにSSL経由でアクセスできることを確認します。