| Oracle® Fusion Middleware Oracle Application Development Frameworkモバイル開発者ガイド 11g リリース2 (11.1.2.4.0) B70750-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development Frameworkモバイル開発者ガイド 11g リリース2 (11.1.2.4.0) B70750-02 |
|
前 |
次 |
この章では、ADFモバイル内のセキュリティ・フレームワークの概要と、セキュリティが適用されるようにADFモバイル・アプリケーションを構成する方法について説明します。
この章には次の項が含まれます:
ADFモバイルは、保護されたアプリケーション機能がWebビュー内に表示されようとしているときやオペレーティング・システムがアプリケーション機能をフォアグラウンドに戻したときなど、保護されたアプリケーション機能がアクティブ化されたときに、エンド・ユーザーにログイン・ページを表示します。こうした場合、ADFモバイルは、アプリケーション機能へのアクセスで認証が必要かどうかを判断し、ユーザーにログイン・ページを提示します。ADFモバイルは、ユーザーが有効な資格証明を入力した場合のみ、目的のWebビュー、UIコンポーネントまたはアプリケーション・ページをレンダリングします。デフォルトでは、ADFモバイルは、アプリケーション機能にセキュリティが必要な場合や、ユーザー・ロールまたはユーザー権限に基づく制約を含める場合など、必要なときにのみログイン・ページを表示します。これらのうちいずれかの条件を満たしている場合、ADFモバイルは、ADFモバイル・アプリケーションの起動時にユーザーにログイン・ページを表示し、その結果に応じてナビゲーション・バーにアプリケーション機能を表示します。詳細は、第18.4.1項「認証を要求するようにアプリケーション機能を設定する方法」および第14.2.4項「ユーザー制約とアクセス制御について」を参照してください。
ADFモバイルは、JavaScript、Apache CordovaプラグインおよびネイティブのCordovaコマンド・ハンドラを使用します。これらは併せて、ログイン・ページとの対話、アプリケーション機能間のナビゲーション、およびOracle Identity ConnectのIDM Mobile SDKとの対話を処理し、そのクラスとプロトコルはユーザーの資格証明を検証します。ネイティブのCordovaコマンド・ハンドラ・メソッドは、Cordovaプラグインを介して実行されます。メソッドの結果は、要求されたアプリケーション機能または認証プロセスが開始されたWebビューのいずれかに移動する、対応するJavaScriptコールバック関数に返送されます。
|
注意: ログイン・プロセス全体がADFモバイル内で実行されます。埋込みJavaは必要ありません。 |
ADFモバイル・アプリケーションでは、デフォルト・ページまたはHTMLで記述されたカスタマイズ済のログイン・ページのいずれかが使用されます。
(adfmf-feature.xmlファイル内の)アプリケーション機能定義のcredential属性がリモートまたはローカルに指定されており、かつユーザーが認証されなかった場合は、ログインが必要です。エンド・ユーザーの視点からは、ログイン・プロセスは次のようなものになります。
ADFモバイルでは、図18-1に示されているような、ログイン・ページのWebビューが表示されます。このログイン・ページには、認証を必要とするアプリケーション機能の名前、feature1が示されています。
|
注意: 第18.4.12.2項「カスタム・ログイン・ページ」で説明されているとおり、ADFモバイルでは、プラットフォームに依存しないログイン・ページが提供されるだけでなく、カスタム・ログイン・ページの使用もサポートされています。 |
ユーザーがユーザー名とパスワードを入力し、「OK」をクリックします。
|
注意: ADFモバイルでは、同じアプリケーションに対して複数のユーザーが許可されません。あるユーザーがタイムアウトのためにログアウトした後、別のユーザーがアプリケーションにログインしようとすると、ADFモバイルでは、最初のユーザーの名前とパスワードを入力するか、アプリケーションを再起動することを求めるメッセージが表示されます。ログオフは、アプリケーションを自動的に終了するため、ユーザーは、ログオフすることでアプリケーションを再起動できます。エンド・ユーザーが、ログイン画面からログオフすることで、アプリケーションを終了できるようにする必要があります。 ユーザーがアプリケーションを終了せずに、そのアプリケーションからログオフできるようにするための |
ユーザー名とパスワードが検証されると、ADFモバイルによって、目的のWebビュー、ページまたはUIコンポーネントが表示されます。
ADFモバイルは、ユーザーが正常にログインするまで、ユーザー名とパスワードの入力を求めます。ユーザーがログインできない場合、別のアプリケーション機能に移動することのみが可能です。
|
注意: アプリケーション機能が最後にアクティブ化されて以降、事前定義された時間が経過すると、認証はタイムアウトになります。ADFモバイルでは、認証サーバーへの接続を使用するアプリケーション機能のいずれかがアクティブ化されたときのみ、アイドル・タイムアウトのタイマーの期限が更新されます。 |
ADFモバイルでは、Oracle Access Management (OAM) Identity Serverなどの認証サーバーに対して認証が行われます。
|
注意: ADFモバイルは、どの基本認証サーバーに対しても認証できます。 |
ADFモバイルがリモート・サーバーに対する認証を処理する場合、セキュリティのフローは次のようなものになります。
ADFモバイルによって、図18-1に示されているようなデフォルト・ログイン・ページまたはカスタム・ログイン・ページがユーザーに表示されます。
Oracle Identity Connect IDM Mobile SDK APIは、リモート認証サーバーに対する認証と、デバイス上の資格証明ストア(保存済のユーザー・オブジェクトが格納されている場合も、格納されていない場合もあります)に対する認証の両方を処理します。認証の成功または失敗に応じて、APIは、ADFモバイルに有効なユーザー・オブジェクトまたは失敗のいずれかを戻します。
|
注意: Oracle Identity Connect (OIC)にログインすると、ロールおよび権限コレクションが |
ログインに成功すると、ADFモバイルは、Cookieで使用されるOAMトークンを受け取ります。各ログイン接続にCookieが設定されます。
Oracle Identity Connect IDM Mobile SDK APIによって、デバイスの資格証明ストアに資格証明が保存されます。
ログインに失敗した場合、ログイン・ページが表示されたままになり、ユーザーは先に進むことができません。
少なくとも1つの保護されたアプリケーション機能にuser.rolesまたはuser.privileges制約が含まれている場合、エンド・ユーザーは、アプリケーションの起動時にログイン・ページへの入力を行い、アプリケーション・ログイン・サーバーに対して認証される必要があります。そうでない場合は、デフォルトのアプリケーション機能が表示されます。デフォルトのアプリケーション機能にセキュリティが適用される場合、ADFモバイルはログイン・ページを使用して、アプリケーション機能に関連付けられたログイン接続に対する認証をエンド・ユーザーに求めます。エンド・ユーザーは、認証を行わずに、別のアプリケーション機能に移動することも可能です。詳細は、第14.2.4項「ユーザー制約とアクセス制御について」を参照してください。
セキュリティは、adfmf-feature.xmlファイルとadfmf-application.xmlファイルの両方の概要エディタを使用して構成されます。adfmf-application.xmlファイルの概要エディタを使用すると、認証を必要とするアプリケーション機能をユーザーが選択したときにADFモバイルによって表示されるログイン・ページのタイプ(デフォルトまたはカスタム)を指定したり、ユーザー・ロールまたはユーザー権限ベースの制約を含めることができます。アプリケーション機能のコンテンツがリモートURLから提供される場合に、この概要エディタを使用すると、リモートURLのコンテンツをADFモバイルのWebビューに表示できるように、ドメインをホワイトリストできます。詳細は、第12章「リモートURLとしてのアプリケーション機能の実装」を参照してください。
adfmf-feature.xmlファイルの概要エディタを使用すると、アプリケーション機能で、リモート・ログイン・サーバーに対する認証、またはリモート・ログイン・サーバー用のユーザーのログイン資格証明が格納されているデバイス上の資格証明ストアに対する認証が必要であるかどうかを指定できます。前者の場合、モバイル・アプリケーションでは、Oracle ADF Fusion Webアプリケーションによって使用されるOracle Access Managerに対するユーザー認証を求めることができます。ユーザーが同じアプリケーション・セッション内(つまり、アプリケーション実行のライフサイクル内)でログイン・サーバーに対して認証されると、認証コンテキストがローカルに格納され、以降の認証は、このローカルの認証コンテキストに対して実行されます。ローカルの認証コンテキストで問題なくユーザーを認証できる場合、以降の認証では、ログイン・サーバーへの接続は試行されません。最初の認証ではリモート・ログイン・サーバーへの接続が必要ですが、ローカル認証のためにそのサーバーに頻繁にアクセスする必要はありません。さらに、ローカル資格証明ストアに対する認証は、リモート・ログイン・サーバーに対する認証よりも高速で実行できます。
アプリケーション機能のセキュリティが指定されると、JDeveloperによって、credential属性がそのアプリケーション機能の<adfmf:feature>要素に移入されます。そのようなアプリケーション機能をモバイル・アプリケーションに埋め込む場合、ログインおよびログアウト・サーバー接続情報を構成し、ユーザーにADFモバイルが提供するデフォルト・ログイン・ページを提示するか、カスタマイズされたページを提示するかを指定します。これらの要件は、<adfmf:login>要素の属性で設定されます。
(adfmf-feature.xmlファイル内の)アプリケーション機能定義の資格証明属性がリモートまたはローカルに指定されており(第18.4.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照)、かつユーザーがタイムアウト期間(図18-7に示されている「ADFモバイル・ログイン接続の作成」ダイアログで設定)内に認証されなかった場合は、ログインが必要です。第18.1項「ADFモバイル・アプリケーションのセキュリティの概要」も参照してください。
|
注意: リモート・ログイン・サーバーを使用して、または格納されている資格証明のセットを使用してローカルにセキュリティが適用されるアプリケーション機能用に、アプリケーション・ログイン・サーバーへの接続を少なくとも1つ定義する必要があります。アプリケーション・ログイン・サーバーへの定義済の接続が存在しないと、無効な構成になります。その結果、アプリケーションは正しく機能しません。 |
ADFモバイル・アプリケーションのセキュリティの構成は、アプリケーション機能レベルから始まります。ここでは、リモート・ログイン・サーバーまたはローカル資格証明ストアに対する認証をユーザーに求めるアプリケーション機能を指定します。セキュリティが適用されるように各アプリケーション機能を定義できます。残りのセキュリティ構成は、adfmf-application.xmlの概要エディタの「セキュリティ」ページを使用して行います。
図18-2に示されているadfmf-feature.xml概要エディタの「資格証明」タブでは、セキュリティを適用するアプリケーション機能と、それが要求する認証のタイプを指定できます。
アプリケーション機能に対するユーザー・アクセスを指定するには:
アプリケーション機能を選択するか、「追加」をクリックしてアプリケーション機能を追加します。
ログインが必要なアプリケーション機能の「機能セキュリティの有効化」をクリックし、次の認証オプションのいずれかを選択します。
ローカル: アプリケーションが、デバイス上にローカルに格納されている資格証明に対してユーザーを認証できるようにする場合は、これを選択します。ユーザーが最初にリモート・サーバーに対して正常に認証されると、ADFモバイルは、資格証明をデバイスの資格証明ストア内にローカルに保持します。アプリケーション機能への以降のアクセスでは、それらの資格証明が使用されます。第18.4.11項「Webサービス・セキュリティに関する必知事項」も参照してください。
リモート: アプリケーションが、Oracle Access Manager (OAM) Identity Serverなどのリモート・ログイン・サーバーまたは保護されているWebアプリケーションでの認証を要求する場合は、これを選択します。ユーザーがログインするたびに、リモート・サーバーに対する認証が求められます。デバイスがサーバーに接続できない場合、ユーザーは、前回は正常に認証されていても、アプリケーションにログインすることはできません。
図18-2に示されている概要エディタに加えて、図18-3に示す「プロパティ・インスペクタ」でセキュリティ・オプションを構成できます。
概要エディタで指定できるローカルおよびリモートのオプションに加えて、「プロパティ・インスペクタ」では、セキュリティが適用されないアプリケーション用に、「なし」と「デフォルト(なし)」のオプションも用意されています。「なし」を選択すると、概要エディタの「機能セキュリティの有効化」オプションがクリアされ、<adfmf:feature>がcredentials="none"で更新されます。「デフォルト(なし)」を選択した場合も、「機能セキュリティの有効化」がクリアされ、<admf:feature>からcredentials属性が削除されます。<admf:feature>は、デフォルトではcredentials属性を持ちません。
アプリケーション機能のセキュリティを指定したら、図18-4に示されているadfmf-application.xml概要エディタの「セキュリティ」ページを使用して、セキュリティが適用される各アプリケーション機能に対して、ログイン・ページの構成およびログイン・サーバーへの接続の作成と割当てを行います。このページにリストされているすべてのアプリケーション機能は、adfmf-feature.xmlファイルで、セキュリティが必要なものとして指定されています。通常、アプリケーション機能のグループは、同じログイン・サーバー接続で保護され、ユーザーは、ADFモバイルからさらにログインを求められることなく、これらのアプリケーションをどれでも開くことが可能です。ただし、場合によっては、あるアプリケーション機能のセットを保護しているログイン・サーバーと、別のアプリケーション機能のセットを保護しているログイン・サーバーが異なるため、アプリケーション機能で要求される資格証明がそれぞれ異なる可能性があります。このような状況に対応するために、ADFモバイル・アプリケーション用のログイン・サーバーへの接続をいくつも定義できます。adfmf-application.xmlファイルでは、機能参照に関連付けられている認証サーバー接続は、次のようにloginConnRefId属性を使用して指定されます。
<adfmf:featureReference id="feature1" loginConnRefId="Connection_1"/> <adfmf:featureReference id="feature2" loginConnRefId="Connection2"/>
ADFモバイル・アプリケーションは、HTTPまたはHTTPS経由の基本認証をサポートしている標準のログイン・サーバーなら、どのログイン・サーバーに対しても認証を受けることが可能です。ADFモバイルはまた、Oracle Identity Managementに対する認証もサポートしています。特定のアプリケーション機能用のカスタム・ログイン・ページを選択することもできます。詳細は、第18.4.12項「ログイン・ページに関する必知事項」を参照してください。
始める前に:
ADFモバイル・アプリケーションでカスタム・ログイン・ページを使用する場合は、アプリケーション・コントローラ・プロジェクトのpublic_htmlディレクトリ(JDeveloper\mywork\Application\ApplicationController\public_html)にファイルを追加して、図18-5に示されているように「アプリケーション・ナビゲータ」の「Webコンテンツ」ノードからそれを使用できるようにします。第18.4.12.3項「カスタム・ログインHTMLページの作成」および第5.9.2項「外部リソースの選択に関する必知事項」も参照してください。
第14.2.4項「ユーザー制約とアクセス制御について」の説明に従って、ユーザー権限とロール用の制約を追加します。
アクセス制御サービス(ACS)・サーバーをプロビジョニングします。詳細は、第18.4.7項「アクセス制御サービスに関する必知事項」を参照してください。
ログイン・ページを指定するには:
adfmf-application.xmlの概要エディタにある「セキュリティ」をクリックします。
ログイン・ページのタイプを選択します。
デフォルト: 選択したすべての埋込みアプリケーション機能に使用される、プラットフォームに依存しないデフォルトのログイン・ページ。詳細は、第18.4.12.1「デフォルト・ログイン・ページ」を参照してください。デフォルト・ログイン・ページは、ADFモバイルによって提供されているものです。
カスタム: フォーマット(HTML)を選択し、「参照」をクリックして、アプリケーション・コントローラ・プロジェクト内のファイルのパスの場所を検索します。または、「新規」をクリックして、アプリケーション・コントローラ・プロジェクト内にHTMLページを作成します。詳細は、第18.4.12.2項「カスタム・ログイン・ページ」および第18.4.12.3項「カスタム・ログインHTMLページの作成」を参照してください。
|
ヒント: 「参照」機能を使用してログイン・ページの場所を検索するのではなく、「アプリケーション・ナビゲータ」からログイン・ページをフィールドにドラッグできます。 |
リモート・サーバーへの接続を設定するには:
まず、次のように認証関連の接続を作成する必要があります。
図18-6に示されているように、「セキュリティが有効な機能」の表で、アプリケーション機能のサーバー接続フィールドを選択し、「追加」をクリックします。
|
注意: アプリケーション・ログイン・サーバー接続を定義し、それをデフォルトのアプリケーション機能に割り当てる必要があります(デフォルトのアプリケーション機能が保護されている場合)。また、アプリケーション・ログイン・サーバーで使用される資格証明は、アクセス制御サービス(ACS)を介してユーザー、ロールおよびサービスを検索するためにも使用されます。第18.4.7項「アクセス制御サービスに関する必知事項」も参照してください。 |
「ADFモバイル・ログイン接続の作成」ダイアログの「認証」タブに、次のとおり情報を入力します。
名前: 接続の名前を入力します。
ログインURL: 認証サーバーのログインURLを入力します。
ログアウトURL: 認証サーバーのログアウトURLを入力します。
アイドル・タイムアウト: ADFモバイルがアプリケーション機能のアクティブ化を検出しなくなって以降、アプリケーション機能をアイドル状態にしておく時間を入力します。この時間が経過すると、このログイン接続によって保護されているすべてのアプリケーション機能がタイムアウトになります。この状況では、ユーザーが再度その機能にアクセスすると、ADFモバイルによってログイン・ページが表示されます。デフォルトでは、アプリケーションが300秒(5分)アイドルのままである場合、ログイン・ページが表示されます。
|
注意: ADFモバイルは、アイドル・タイムアウト後、ローカル資格証明ストアに対して認証を行いますが、セッション・タイムアウト後にこの認証を行うことはありません。 |
セッション・タイムアウト: ユーザーがアプリケーション機能にログインした状態のままでいられる時間を秒単位で指定します。セッションが期限切れになった後、アイドル・タイムアウト期間が経過していない場合、ADFモバイルは、ユーザーにログイン・ページを表示します。デフォルトでは、ユーザー・セッションは28,800秒(8時間)継続します。
|
注意:
|
Cookie: 保護されたアプリケーション機能のリモート・ログインで使用します。格納された後に基本認証を有効にするCookie名のリストを入力します。ADFモバイルでは、Cookieがブラウザに格納されるため、ユーザーは1回ログインするだけですみます。これらのCookieと、Cookie内に格納される資格証明は、システム管理者によって提供されます。Cookie名では、大文字と小文字が区別されます。第18.4.10項「基本認証ヘッダーの挿入に関する必知事項」も参照してください。
RESTコールにログイン・サーバーのCookieを含める: リモート認証を使用するアプリケーション機能の場合(つまり、第18.4.1項「認証を要求するようにアプリケーション機能を設定する方法」で説明されているように、<adfmf:feature>要素にcredentials="remote"が含まれている場合)、ログイン・サーバーが生成したユーザー・セッションCookieを使用してログイン・サーバーに格納されている認可済のユーザーのデータを取得するために、これを選択してREST Webサービスを有効にします。詳細は、第18.4.9項「CookieをREST Webサービス・コールに挿入することに関する必知事項」を参照してください。
|
注意: CookieをREST Webサービス・コールに挿入できるようにするには、次の点に注意してください。
|
|
注意: 図18-7は、Oracle WebLogic Serverに対するHTTP基本認証で使用される、JSESSIONIDのCookieを示しています。他の認証メカニズムでは別のCookieが必要なため、ネットワーク・トレースまたはHTTPアナライザによってCookie名を取得できます。これについては、『Oracle Fusion Middleware Oracle JDeveloperユーザーズ・ガイド』のHTTPアナライザを使用したHTTPの監視に関する項を参照してください。 |
|
ヒント: OAM以外のリソースに対して認証を行う場合は、認証リソースのURLとして「ログインURL」と「ログアウトURL」の両方を構成し、CookieとしてJSESSIONIDを入力します。 |
アプリケーション機能に、たとえば、マネージャというロールが付与されているユーザーがクリックした場合のみtrueにレンダリングされるEL式で構成された送信ボタンがある経費レポート・アプリケーションなど、保護されているコンポーネントが含まれている場合は、「ADFモバイル・ログイン接続の作成」ダイアログの「認可」タブに情報を入力します(図18-8を参照)。このタブのフィールドに値を入力すると、アプリケーション機能によってチェックされる特定のユーザー・ロールの取得が可能になります。
アプリケーション・ログイン・サーバーによって付与されるアクセス制御は、第14.2.4項「ユーザー制約とアクセス制御について」で説明されているとおり、そのアプリケーション機能用に構成されているuser.rolesおよびuser.privileges制約の評価に基づきます。たとえば、manager_roleロールを持つユーザーにのみアプリケーション機能へのアクセスを許可するには、adfmf-feature.xmlファイル内の<adfmf:constraints>要素を次のように定義する必要があります。
<adfmf:constraint property="user.roles"
operator="contains"
value="manager_role"/>
</adfmf:constraints>
アプリケーションの起動時、アプリケーション・ログイン・サーバー接続のために、アクセス制御サービス(ACS)として知られているRESTful Webサービスが呼び出され、そのユーザーに割り当てられているロールと権限がフェッチされます。その後、ADFモバイルは、アプリケーション・ログイン・サーバー接続に対してログインするようにユーザーに要求します。
ADFモバイルは、取得されたユーザー・ロールと権限に照らして各アプリケーション用に構成されている制約を評価し、関連付けられているすべての制約を満たすユーザーのみがアプリケーション機能を使用できるようにします。
認可要件を次のように指定します。
アクセス制御URL: 図18-8に示されているように、アクセス制御サービスのエンドポイントであるURLを入力します。
|
注意: ADFモバイルは、ACSを呼び出すときに、認証サーバー(つまりログイン・サーバー)によって発行されたすべてのCookieをHTTPリクエスト・ヘッダーに挿入します。Cookieの挿入は、「RESTコールにログイン・サーバーのCookieを含める」を選択し、「アクセス制御URL」パラメータと「ログインURL」パラメータに同じアドレスを入力した場合に発生します。第18.4.9項「CookieをREST Webサービス・コールに挿入することに関する必知事項」も参照してください。 |
ユーザー・ロールのフィルタ・リスト: アプリケーション機能によってチェックされるユーザー・ロールを入力します。セキュリティ・システムには、数千もの定義済のユーザー・ロールおよび権限が存在する可能性があるため、アプリケーション機能に固有のロールが記載されているマニフェスト(これは、アプリケーション機能の開発者によって提供されます)を使用して、このリストを作成します。
権限のフィルタ・リスト: アプリケーション機能によってチェックされる権限を入力します。
「OK」をクリックします。
|
注意: デフォルトでは、保護されているすべてのアプリケーション機能が同じ接続を共有します。この接続は、図18-4に示されているように、<application login server>と表示されます。「機能参照」の「プロパティ・インスペクタ」では、このデフォルト・オプションが「ログイン・サーバー接続」ドロップダウン・メニューに |
例18-1のように、name=show-application-login-at-startup value=trueをadf-config.xmlファイル(「アプリケーション・ナビゲータ」のADF META-INFディレクトリにあります)に追加すると、ユーザーがアクセス制御サービス(ACS)・サーバーをプロビジョニングすることなくログインできるようになります。このフラグによって、ADFモバイル・アプリケーションの起動時にログイン・ページがトリガーされます。
例18-1 adf-config.xmlにおけるログイン・ページの構成
<adf:adf-properties-child xmlns="http://xmlns.oracle.com/adf/config/properties">
<adf-property name="adfAppUID" value="MobileApplication-3268"/>
<adf-property name="show-application-login-at-startup" value="true"/>
</adf:adf-properties-child>
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のadf-config.xmlに関する項を参照してください。
ADFモバイルでは、connections.xmlファイル内のすべての接続情報が集約されます(このファイルは、「アプリケーション・ナビゲータ」の「アプリケーション・リソース」パネルの「ディスクリプタ」および「ADF META-INF」ノードの下にあります)。このファイル(例18-2を参照)は、アプリケーションにバンドルすることも、構成サービス用にホスティングすることもできます。後者の場合、ADFモバイルは、アプリケーションが起動されるたびに、更新済の構成情報があるかどうかをチェックします。
例18-2 connections.xmlファイル内に定義されているADFモバイル接続
<?xml version = '1.0' encoding = 'UTF-8'?>
<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="Connection_1"
className="oracle.adf.model.connection.adfmf.LoginConnection"
adfCredentialStoreKey="Connection_1"
partial="false"
manageInOracleEnterpriseManager="true"
deployable="true"
xmlns="">
<Factory className="oracle.adf.model.connection.adfmf.LoginConnectionFactory"/>
<RefAddresses>
<XmlRefAddr addrType="adfmfLogin">
<Contents>
<login url="http://10.0.0.0/SecuredWebServicelogin/login.jsf"/>
<logout url="http://10.0.0.0/SecuredWebServicelogout/logout.jsf"/>
<accessControl url="http://10.0.0.0/Identity/Authorize"/>
<idleTimeout value="300"/>
<sessionTimeout value="28800"/>
<cookieNames>
<cookie name="JSESSIONID"/>
</cookieNames>
<injectCookiesToRESTHttpHeader value="true"/>
<userObjectFilter>
<role name="manager"/>
<privilege name="account manager"/>
<privilege name="supervisor"/>
<privilege name=""/>
</userObjectFilter>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
</References>
詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』のconnections.xmlファイル内で定義された参照に関する項を参照してください。
例18-3に示されているように、connections.xmlファイルにmax_retries属性を追加することで、そのユーザーに許可されるログイン試行の失敗の最大回数を設定できます。この属性が構成されない場合、ADFモバイルは、10回の再試行を許可します。ユーザーがログイン試行の設定回数を超えると、アプリケーションは自動的に終了します。
デフォルトでは、ADFモバイルは、ユーザーに3回のログイン試行の失敗を許可します。それを超えると、ローカルに格納されているそのユーザーの資格証明をクリアし、以降のログイン試行では、リモート・ログイン・サーバーに接続します。例18-3に示されているように、connections.xmlファイルにmaxFailuresBeforeCredentialCleared要素を追加することで、ローカルに格納されている資格証明が消去されるまでにユーザーに許可されるログイン試行の回数を変更できます。
|
注意:
|
例18-3 connections.xmlにおける最大再試行回数の構成
<?xml version = '1.0' encoding = 'UTF-8'?>
<References xmlns="http://xmlns.oracle.com/adf/jndi">
<Reference name="MyAuth"
className="oracle.adf.model.connection.adfmf.LoginConnection"
adfCredentialStoreKey="MyAuth"
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:7777/SecuredWeb1-ViewController-context-root/
faces/view1.jsf"/>
<logout url="http://10.0.0.0:7777/SecuredWeb1-ViewController-context-root/
faces/view1.jsf"/>
<accessControl url="http://myhost.us.example.com:7777/
UserObjects/jersey/getUserObjects" />
<idleTimeout value="10"/>
<sessionTimeout value="36000"/>
<cookieNames>
<cookie name="JSESSIONID"/>
</cookieNames>
<max_retries value="6"/>
<maxFailuresBeforeCredentialCleared value="3"/>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
</References>
adfmf-feature.xml概要エディタで「機能セキュリティの有効化」オプションを選択し、認証のタイプを選択すると、<adfmf:feature>要素が定義済のcredentials属性で更新されます。例:
<adfmf:feature id="feature1" name="feature1" credentials="remote"> <adfmf:feature id="feature2" name="feature2" credentials="local">
|
注意: セキュリティを必要としないアプリケーション機能(つまり、これらのセキュリティ・オプションが選択されていないもの)は、ADFモバイル・アプリケーションのすべてのユーザーが使用可能です。それらのアプリケーションでは、 |
セキュリティが適用されるようにアプリケーション機能が指定されると、JDeveloperは、図18-4に示されているように、対応する機能参照で「セキュリティが有効な機能」の表を更新します。参照される各アプリケーション機能が、connections.xmlファイル内に定義されている同じログイン・サーバー接続に対して認証を行うと、JDeveloperは、defaultConnRefId属性を使用して定義されている単一の<adfmf:login要素(<adfmf:login defaultConnRefId="Connection_1"など)でadfmf-application.xmlファイルを更新します。connections.xmlファイル内に定義されている別のログイン・サーバー接続を使用するように構成されているアプリケーション機能の場合は、JDeveloperは、参照される各アプリケーション機能をloginConnReference属性(<adfmf:featureReference id="feature2" loginConnRefId="Connection2"/)で更新します。詳細は、第18.4.1項「認証を要求するようにアプリケーション機能を設定する方法」を参照してください。また、Oracle Fusion Middleware Oracle ADFモバイルのタグ・リファレンスも参照してください。
アクセス制御サービス(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: ユーザー情報をフィルタ処理するために使用される権限のリスト。
|
注意: すべてのロールを戻す必要がある場合は、 すべての権限を戻す必要がある場合は、 |
例18-4は、HTTP POSTメッセージを示しています。この例では、JSONオブジェクトをペイロードとして識別し、John Smithというユーザーに割り当てられているすべてのフィルタとロールをリクエストします。
例18-4 ユーザー・ロールおよび権限のACSリクエスト
Protocol: POST
Authoization: Basic xxxxxxxxxxxx
Content-Type: application/json
{
"userId": "johnsmith",
"filterMask": ["role", "privilege"],
"roleFilter": [ "role1", "role2" ],
"privilegeFilter": ["priv1", "priv2", "priv3"]
}
レスポンスは、次のもので構成されています。
次のフィールドを持つレスポンス・ヘッダー: Last-Modified、Content-TypeおよびContent-Length。
ユーザー情報の詳細を含むレスポンス・メッセージ本文。
戻されるJSONオブジェクト。これには次のものが含まれます。
userId: ユーザーのID。
roles: ユーザー・ロールのリスト。これは、リクエスト内のroleFilter配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられているロールのリスト全体が戻されます。
privileges: ユーザーの権限のリスト。これは、リクエスト内のprivilegeFilter配列を定義することでフィルタ処理できます。フィルタ処理しない場合は、そのユーザーに割り当てられている権限のリスト全体が戻されます。
例18-5は、戻されたJSONオブジェクトを示しています。これには、ユーザー名およびJohn Smithというユーザーに割り当てられているロールと権限が含まれています。
例18-5 戻されたJSONオブジェクト
Content-Type: application/json
{
"userId": "johnsmith",
"roles": [ "role1" ],
"privileges": ["priv1", "priv3"]
}
|
注意: Webサービスでは、ログイン画面はありません。かわりに、ADFモバイルによってユーザー・アクセスが有効化され、Webサービスのヘッダーに自動的に資格証明が追加されます。詳細は、第9.5.3項「資格証明の挿入に関する必知事項」を参照してください。 |
|
注意: ACSサービスを実装してホストする必要があります。ADFモバイルでは、このサービスは提供されません。 |
ADFモバイル・アプリケーションがREST Webサービスを要求するたびに、ADFモバイルのセキュリティ・フレームワークは、REST Webサービスのトランスポート・レイヤーが、REST WebサービスのURLエンドポイントに関連付けられているログイン接続に対してCookieの挿入が可能かどうかをチェックできるようにします。(つまり、例18-2に示されているように、connections.xmlファイルに<injectCookiesToRESTHttpHeader value="true"/>が含まれている必要があります。)接続でCookieの挿入が許可されており、ログイン・サーバーとREST Webサービス・エンドポイントのドメインが一致している場合、セキュリティ・フレームワークによって、ユーザーがアプリケーション機能にログインしたときに格納されたCookieが取得されます。その後、文字列が"<cookie name1>=<cookie value1>;<cookie name2>=<cookie value2>;...<cookie nameN>=<cookie valueN>"という形式で戻されます。ログイン・サーバー用に構成されているドメインがREST WebサービスのURLエンドポイントと同じである場合のみ、セキュリティ・フレームワークは、Cookieヘッダーを作成し、この文字列をそれに挿入します。さらに、格納されているCookieの文字列(これらのCookieはREST Webサービスで必要とされます)は、ログイン・サーバーから戻されたものと一致している必要があります。
|
注意: ADFモバイルは、IDM Mobile SDK APIをコールすることで、Cookie文字列を作成します。IDM Mobile SDK APIは、プラットフォーム固有のCookieストアから名前でCookieを戻します。IDM Mobile SDKは、認証サーバーによって戻されたCookieを管理します。それらの名前は、 |
ユーザーがADFモバイル・アプリケーションによって正常に認証されると、ログイン・サーバーは、そのユーザーのセキュリティ・コンテキストを作成し、ユーザー・セッションを追跡するCookieを生成します。図18-2に示されているように、「ADFモバイル・ログイン接続の作成」ダイアログで「RESTコールにログイン・サーバーのCookieを含める」オプションを選択すると、ADFモバイルは、ログイン・サーバーによって送信されたこのユーザー・セッションCookieを取得し、それをADFモバイル・アプリケーションから開始されたREST Webサービス・コールのHTTPヘッダーに挿入します。CookieをWebサービス・コールに伝播することで、ログイン・サーバーに格納されているユーザーのセキュリティ・コンテキストを取得し、ADFモバイル・アプリケーションがREST Webサービスを使用して、そのユーザーに対して認可されているアプリケーション・データにアクセスできるようになります。ユーザー・セッションCookieが期限切れになると、ADFモバイルは、ユーザーに資格証明を要求し、ユーザーを再認証します。再認証されたユーザーは、引き続き、REST Webサービス・コールを介して認可済のアプリケーション・データにアクセスできます。
デフォルトのADFモバイルでは、Webビューから発行されたHTTPリクエスト内に基本認証ヘッダーを挿入することによって、アプリケーション機能がCookieを受け付けないサーバーから提供されるセキュア・リソースにアクセスすることを可能にします。ADFモバイルは、connections.xmlファイルに認証レルムの定義(<realm>要素)とそれに続く<injectBasicAuthHeader value="true">が含まれている場合に基本認証ヘッダーを挿入します(例18-6を参照)が、そのヘッダーは、connections.xmlファイルにこれらの定義が含まれているかどうかにかかわらず挿入されます。ADFモバイルによって基本認証ヘッダーが挿入されないようにするには、<injectBasicAuthHeader>要素のvalue属性をfalseに設定します。
|
注意:
|
例18-6 基本認証ヘッダーの挿入
<?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=""/>
<idleTimeout value="300"/>
<sessionTimeout value="28800"/>
<cookieNames/>
<realm value="Secure Area"/>
<injectBasicAuthHeader value="true"/>
<userObjectFilter/>
</Contents>
</XmlRefAddr>
</RefAddresses>
</Reference>
</References>
Webサービスでは、ログイン画面はありません。かわりに、ADFモバイルによってユーザー・アクセスが有効化され、Webサービス・コールのヘッダーに資格証明が挿入されます。Webサービスは、ローカルに格納されている資格証明(ユーザーによる認証サーバーへの最初のログインの成功後、ADFモバイルによって保持されている資格証明)を使用してアプリケーション・データにアクセスします。ローカル資格証明ストアの名前は、ログイン・サーバー接続のadfCredentialStoreKey属性によって示されます(例18-2ではadfCredentialStoreKey="Connection_1")。Webサービスがこの資格証明ストアを使用できるようにするには、SOAPまたはREST Webサービス接続のadfCredentialStoreKey属性に対して定義されている名前が、ログイン・サーバーのadfCredentialStoreKey属性に対して定義されている名前と一致する必要があります。
|
注意:
|
詳細は、第9.5.3項「資格証明の挿入に関する必知事項」を参照してください。
アプリケーション機能への認証プロセスのエントリ・ポイントは、activateライフサイクル・イベントです(第5.6.2項「モバイル・アプリケーション・イベントのタイミング」を参照)。アプリケーション機能がアクティブ化される(つまり、アプリケーション機能のactivateイベント・ハンドラがコールされる)たびに、アプリケーション機能のログイン・プロセスが実行されます。このプロセスは、ログイン・ページ(デフォルトまたはカスタムのログイン・ページのいずれか)に移動し、そこでユーザー認証が必要かどうかを判断します。ただし、プロセスがログイン・ページに移動する前に、本来意図されていたアプリケーション機能をADFモバイルに登録する必要があります。認証が成功すると、ログイン・ページは、ADFモバイルから本来意図されていた宛先を取得し、そこに移動します。
ADFモバイルによって提供されるデフォルトのログイン・ページ(図18-1「ログイン・ページ」を参照)は、ログイン・ボタンと、ユーザー名およびパスワード用の入力テキスト・フィールドから構成されます。これは、HTMLで記述されたクロス・プラットフォーム・ページです。
adfmf-application.xmlファイルの概要エディタを使用して、選択したアプリケーション機能用のカスタム・ログイン・ページを追加すると、JDeveloperは、例18-7に示されているように、<adfmf:login>要素を追加し、その子要素<adfmf:LocalHTML>を移入します。すべての<adfmf:LocalHTML>要素と同様に、そのurl属性は、public_htmlディレクトリ内の場所を参照します。ユーザー認証メカニズムとナビゲーション・コントロールは、デフォルトのログイン・ページと同じものになります。
例18-7 ログイン要素
<adfmf:login defaultConnRefId="Connection_1">
<adfmf:localHTML url="newlogin.html"/>
</adfmf:login>
ADFモバイルは、関連するセキュリティ機能にアクセスするためのJavaScript APIを提供します。HTMLページとしてカスタム・ログイン・ページを実装するので、表18-1に示されているように、adf.mf.api.invokeSecurityメソッドへのコールを追加することで、ADFモバイルがユーザー・コマンドを処理できるようにすることが可能です。
表18-1 adf.mf.api.invokeSecurityMethod
| セキュリティ・メソッド | 戻り値 | 渡されるパラメータ | 機能 |
|---|---|---|---|
|
|
なし |
|
ユーザーを認証し、(認証の結果に応じて)適切なプログラム・フローを実行します。 |
ログアウトを可能にするには、次のようにAdfmfJavaUtilitiesクラスのlogoutメソッドをコールします。例:
import oracle.adfmf.framework.api.AdfmfJavaUtilities; ... AdfmfJavaUtilities.logout();
例18-8に示されているように、adfmfJavaUtilitiesクラスのclearPasswordCredentialメソッドを使用して、アプリケーションに固有の資格証明(リモートまたはローカルに格納されているもの)を無効にできます。
例18-8 ユーザー資格証明のクリア
import oracle.adfmf.framework.api.AdfmfJavaUtilities; ... AdfmfJavaUtilities.clearPasswordCredential(adfCrendentialStorykey, username);
adfCredentialStorykeyパラメータは、connections.xmlファイル内のadfCredentialStoreKeyパラメータに対して定義されている値からStringオブジェクトとして戻されます。メソッドのusernameパラメータは、Stringオブジェクトとして戻され、資格証明ストアからその資格証明が削除されるユーザーを表します。
この資格証明セットをクリアすることで、ユーザーは、保護されている他のアプリケーション機能でセッションを維持したり、ADFモバイル・アプリケーションを終了せずに、保護されていないアプリケーション機能を開くことが可能になります。
AdfmfJavaUtiltiesクラスおよびkeyパラメータの使用方法の詳細は、Oracle Fusion Middleware Oracle ADFモバイルJava APIリファレンスを参照してください。
ADFモバイルのデプロイメントによってwwwディレクトリ内に生成されるアーティファクトである、デフォルトのログイン・ページ(adf.login.iphone.htmlまたはadf.login.android.html)を使用して、カスタム・ログイン・ページを作成できます。
始める前に:
wwwディレクトリ内のログイン・ページにアクセスするには、ADFモバイル・アプリケーションをデプロイした後、deployディレクトリに移動します。iOSデプロイメントの場合、adf.login.iphone.htmlページは次の場所にあります。
application workspace directory/deploy/deployment profile name/temporary_xcode_project/www/adf.login.iphone.html
Androidデプロイメントの場合、adf.login.android.htmlページは、次の場所にあるAndroidアプリケーション・パッケージ(.apk)ファイル内に配置されます。
application workspace directory/application name/deploy/deployment profile name/deployment profiile name.apk/assets/www/adf.login.android.html
カスタム・ログイン・ページを作成するには:
デフォルト・ログイン・ページ(adf.login.iphone.htmlまたはadf.login.android.html)を、アプリケーション・コントローラ・プロジェクトのpublic_htmlディレクトリ内の場所(JDeveloper\mywork\application name\ApplicationController\public_htmlなど)にコピーします。
ログイン・ページの名前を変更します。
第5.4.4項「HTMLコンテンツによるカスタムSpringboardアプリケーション機能に関する必知事項」および第B項「アプリケーション・コンテナAPI」の説明に従ってページを更新します。
adfmf-application.xmlファイルの概要エディタの「セキュリティ」ページで、「カスタム」を選択し、「参照」をクリックしてログイン・ページの場所を検索します。詳細は、第5.4項「Springboardとナビゲーション・バーの動作の構成」を参照してください。
第4.2.2.1項「アプリケーション・コントローラ・プロジェクト・レベルのリソースについて」に示されているように、JDeveloperは、アプリケーション・リソースのSecurityフォルダ内にcacerts証明書ファイルを作成します(JDeveloper\mywork\application name\resources\Security\cacertsにあります)。このファイルにより、信頼できる既知のソースからの一連の証明書がJVM 1.4に対して識別され、デプロイメントが可能になります。カスタム証明書を必要とするアプリケーションでは(RSA暗号化が使用されていない場合など)、アプリケーションをデプロイする前にプライベート証明書を追加する必要があります。
始める前に:
cacertsファイルおよびkeytoolユーティリティの使用方法については、Java SEテクニカル・ドキュメント(http://download.oracle.com/javase/index.html)を参照してください。
プライベート証明書を追加するには:
プライベート証明書を作成します。たとえば、new_certという証明書ファイルを作成します。
次のようにして、プライベート証明書をアプリケーションに追加します。
シードされたcacertsファイル(cp cacerts cacerts.org)のコピーを作成します。
Java SE keytoolユーティリティを使用して、cacertsファイルに証明書を追加します。例18-9は、new_certというcacertsファイルへの証明書の追加を示しています。
例18-9 keytoolユーティリティを使用した証明書の追加
keytool -importcert
-keystore cacerts
-file new_cert
-storepass changeit
-noprompt
例18-9は、単一の証明書の追加方法を示しています。各証明書に対して同じ手順を繰り返します。表18-2は、keytoolのオプションを示しています。
新しいcacertsファイルの内容を目で見て調べて、すべてのフィールドが正しいことを確認します。次のコマンドを使用します。
keytool -list -v -keystore cacerts | more
証明書が指定のホスト名に対するものであることを確認します。
|
注意: 証明書の共通名(CN)は、ホスト名と正確に一致している必要があります。 |
JVM 1.4が読み取れるようにするために、カスタマイズされた証明書ファイルはSecurityディレクトリ(JDeveloper\mywork\application name\resources\Security)に確実に配置してください。
アプリケーションをデプロイします。
|
注意: デプロイメント時、証明書ファイルが |
保護されているリソースにSSL経由でアクセスできることを確認します。
