Oracle® Mobile Application Framework Oracle Mobile Application Frameworkでのモバイル・アプリケーションの開発 2.5.0.0.0 E94553-01 |
|
前 |
次 |
この章の内容は次のとおりです。
MAFは、セキュアなMAFアプリケーションの開発を容易にする、すぐに使用できる複数の機能を提供しています。これらには、保護されたアプリケーション機能用のデフォルトのログイン・ページ、匿名ユーザーのサポート、特定のロールまたは権限を持つユーザーに対するアクセスを制限する制約が含まれます。
MAFは、保護されているアプリケーション機能がアクティブ化されたときに、ユーザーにログイン・ページを表示します。たとえば、アプリケーション機能がWebビュー内に表示されようとしているときやオペレーティング・システムがアプリケーションをフォアグラウンドに戻したときに、ユーザーにログイン・ページを表示します。MAFは、アプリケーション機能が認証サーバーによって保護されているときや、アプリケーション機能にユーザー・ロールまたはユーザー権限に基づいた制約が含まれているときに、アプリケーション機能へのアクセスにユーザー認証を必要とするかどうかを決定します。MAFは、ユーザーが有効な資格証明を入力した場合のみ、目的のWebビュー、UIコンポーネントまたはアプリケーション・ページをレンダリングします。
アプリケーション機能のいずれかにこれらの条件がある場合、ユーザーはログインに成功しないとMAFアプリケーションにアクセスできないことがありますが、保護されておらず、かつアクセス関連の制約がないデフォルトのアプリケーション機能を含めることによって、保護されているアプリケーション機能と保護されていないアプリケーション機能の両方を含むMAFアプリケーションに、ユーザーがアクセスできるようにできます。この状況では、ユーザーは認証なしでMAFアプリケーションにアクセスできます。デフォルトのアプリケーション機能によって、これらの匿名ユーザーに、MAFアプリケーションへのエントランス・ポイントが提供され、これらのユーザーは保護されていないデータを表示でき、保護されたアプリケーション機能にアクセスするときには、リモート・サーバーに対して認証されます。保護されていないデフォルトのアプリケーション機能は、次のように指定できます。
デフォルトのアプリケーション機能を通じて公共の情報にアクセスすることを匿名ユーザーに許可する一方、認可されたユーザーのみが保護された情報にアクセスできるようにする。
保護されたアプリケーション機能にアクセスする必要がある場合にのみユーザーを認証するようにします。そうでない場合、ユーザーは匿名ユーザーとしてMAFアプリケーションにアクセスでき、保護された機能に移動するにはログインします。
アクセスを保護する必要がない場合に、保護されているアプリケーション機能からログアウトすることをユーザーに許可し、それにより権限のないユーザーが保護されているアプリケーション機能にアクセスすることを明示的に禁止する。
注意:
MAFでは、アプリケーション・ログイン・プロセスがアプリケーションの初期化フローから切り離されているため、匿名ユーザーが可能となり、ユーザーは認証資格証明を提供する必要なく、匿名ユーザーとしてMAFアプリケーションを起動し、保護されていないアプリケーション機能にアクセスできます。このような場合、MAFは権限を持つUIコンポーネントを無効化することによって、ユーザーのアクションを制限します。「認証を要求するようにアプリケーション機能を設定する方法」および「ユーザー制約とアクセス制御について」を参照してください。
MAFアプリケーションでは、デフォルト・ページまたはHTMLで記述されたカスタマイズ済のログイン・ページが使用されます。
特定のロールおよび権限を付与されたユーザーのみが、user.roles
またはuser.privileges
制約で定義されるアプリケーション機能にアクセスできます。ユーザーがこのようなアプリケーション機能にログインすると、アクセス制御サービス(ACS)として知られるWebサービスは、アプリケーション機能へのアクセス権を付与するユーザー・オブジェクトをユーザーに返します。「アクセス制御サービスに関する必知事項」を参照してください。
MAFは、Webログイン・ページでログインして認証されたユーザーにWebビュー、ページ、またはユーザー・インタフェース・コンポーネントを表示します。MAFは、ログインが有効になるまで試行して、構成された間隔後にログインがタイム・アウトになります。
エンド・ユーザーの視点からは、ログイン・プロセスは次のようなものになります。
ユーザーが保護されたアプリケーション機能にアクセスしようとすると、常に、ログイン・ページのWebビューがMAFによって表示されます。保護されたアプリケーション機能がデフォルトである場合は、ユーザーがアプリケーションを起動すると、MAFによってデフォルトのログイン・ページが表示されます。
注意:
「カスタム・ログイン・ページ」で説明されているように、MAFでは、デフォルトのログイン・ページが提供されるだけでなく、カスタム・ログイン・ページの使用もサポートされています。
ユーザーがユーザー名とパスワードを入力し、「サインイン」をクリックします。
注意:
MAFでは、同じアプリケーションに対して複数のユーザーを許可します。ユーザーは、前のユーザーがログアウトした後、アプリケーションに自由にログインできます。
ユーザー名とパスワードが検証されると、MAFによって、目的のWebビュー、ページまたはユーザー・インタフェース・コンポーネントが表示されます。
MAFは、ユーザーが正常にログインするまで、ユーザー名とパスワードの入力を求めます。ユーザーがログインできない場合、別のアプリケーション機能に移動することのみが可能です。
注意:
アプリケーション機能が最後にアクティブ化されて以降、事前定義された時間が経過すると、認証はタイムアウトになります。MAFでは、認証サーバーへの接続を使用するアプリケーション機能のいずれかがアクティブ化されたときのみ、アイドル・タイムアウトのタイマーの期限が更新されます。
MAFアプリケーションでは、ユーザー資格証明をリモートのログイン・サーバーまたはユーザーのデバイスにあるローカル資格証明ストアに対して検証する必要があります。
ローカルおよびリモートの接続モードをサポートするために、MAFは次の認証プロトコルをサポートしています。
HTTP Basic
OAuth
OpenID
Web SSO
デフォルトでは、MAFアプリケーション・ユーザーの認証は、デザインタイムに選択された認証プロトコルに関係なく、リモート・ログイン・サーバーに対して行われます。基本認証を使用している場合、開発者はローカル認証を有効にするようにアプリケーションを構成できます。ただし、最初はローカル資格証明ストアに資格証明が伝播されていないため、保護されているアプリケーション機能にアクセスするためのログインでは、リモート・ログイン・サーバーに対する認証が必要です。リモート認証に成功すると、その後、認証サーバーのユーザーのログイン資格証明をデバイス上に格納するローカル資格証明ストアを使用できるようになります。そのため、ユーザーが同じアプリケーション・セッション内(つまり、アプリケーション実行のライフサイクル内)でサーバーに対して認証されると、MAFは認証コンテキストをローカルに格納し、以降の認証の試行でそれを使用できるようになります。この場合、ローカルの認証コンテキストで問題なくユーザーを認証できる場合、MAFでは、ログイン・サーバーに接続されません。最初の認証では認証サーバーへの接続が必要ですが、ローカル認証を使用したアプリケーションのためにこのサーバーに頻繁にアクセスする必要はありません。
ヒント:
ローカル資格証明ストアに対する認証は、リモート・ログイン・サーバーに対する認証よりも高速に実行できますが、リモート接続のみをサポートしている認証プロトコルを使用した認証をお薦めします。
表27-1に、MAFアプリケーションのログイン構成オプションをまとめます。接続モードは、選択した認証プロトコルによって異なります。
表27-1 MAFの接続モードおよびサポートされている認証プロトコル
接続モード | サポートされているプロトコル | モードの説明 |
---|---|---|
ローカル |
|
ローカルに格納されている資格証明がデバイスで利用できない場合にのみ、アプリケーションでは、リモート・ログイン・サーバーに対する認証が必要です。初回ログインは、常にリモート・ログイン・サーバーに対して行われます。初回ログインに成功すると、MAFは、資格証明をデバイスの資格証明ストア内にローカルに保持します。アプリケーション機能への以降のアクセスでは、それらの資格証明が使用されます。「Webサービス・セキュリティに関する必知事項」も参照してください。 |
リモート |
|
アプリケーションで、Oracle Access Manager (OAM)アイデンティティ・サーバーなどのリモート・ログイン・サーバーまたは保護されているWebアプリケーションに対する認証が必要です。ユーザーがログインするたびに、リモート・サーバーに対する認証が求められます。デバイスがサーバーに接続できない場合、ユーザーは、前回は正常に認証されていても、保護されたMAF機能にアクセスできません。 |
ハイブリッド |
|
デバイスでローカル資格証明が利用可能でも、ネットワーク接続が利用できる場合は、アプリケーションでは、リモート・ログイン・サーバーに対する認証が必要です。ネットワーク接続がないためにログイン・サーバーにアクセスできない場合にのみ、デバイスのローカル資格証明が使用されます。 |
セキュリティが適用されるアプリケーション機能のアプリケーション・ログイン・サーバーに1つ以上の接続を定義する必要があります。アプリケーション・ログイン・サーバーへの接続が定義されていないと、構成が無効になり、アプリケーションが正しく機能しなくなります。
MAF接続の作成ダイアログを使用して接続タイプを選択し、接続タイプに応じて、ローカルおよびリモート認証の両方を有効化します(ハイブリッド)。
アプリケーション要件によっては、次の認証プロトコルをサポートするサーバーへの接続を構成できます。
HTTP Basic
OAuth
OpenID
Web SSO
注意:
リモート・ログイン・サーバーに対する認証が必要な接続タイプを使用し、ユーザーがローカル資格証明ストアからデバイスで認証できないようにすることをお薦めします。
ログイン・サーバー接続を作成するには:
MAFアプリケーション接続は、様々な組織やテナントで共有可能なホスト・アプリケーション機能をサポートできます。
図に示すように、MAFアプリケーションで表示されるマルチテナント対応の接続が定義されたデフォルトのログイン・ページでは、HTTPリクエストでテナント値を伝播するため、ユーザーにドメインIDの入力が要求されます。
「MAFログイン接続の作成」ダイアログを使用して、リモート・サーバーに格納されている保護されたデータやサービスへのアプリケーションのアクセスを構成します。
始める前に:
OM_PROP_OAUTH_OAUTH20_SERVER
プロパティ・キーを使用するようにサーバーを構成します。
OAuthサーバーで認証を構成するには:
「MAFログイン接続の作成」ダイアログを使用して、OpenID認証プロトコルを使用する接続を構成し、MAFアプリケーションがリモート・サーバーに格納されている保護されたデータやサービスにアクセスできるようにします。
OpenID認証プロトコルで認証を設定するには:
MAFでは、すべてのプラットフォーム(Android、iOSおよびユニバーサルWindowsプラットフォーム)にデプロイされるMAFアプリケーションでシングル・サインオン(SSO)およびフェデレーテッドSSOがサポートされています。
SSOの構成に使用するアイデンティティ・プロバイダは、Azure Active Directoryのインスタンスなど、企業ドメインでホストされるサードパーティ・アイデンティティ・プロバイダ、またはMAFアプリケーションがたとえばOracle Mobile Cloud Service (MCS)などに接続する、バックエンド・サービスのためにすでに構成されているどのようなアイデンティティ・プロバイダにもできます。
ユニバーサルWindowsプラットフォームにデプロイするMAFアプリケーションがMCS SSOのサポートを必要とする場合、MCS SSOにアクセスできるアプリケーションでCordovaプラグインを登録する必要があります。次の例に示すように、このアクセスが可能なプラグインのplugin.xml
ファイルにエントリを構成してください。
<config-file target="package.appxmanifest" parent="/Package/Applications/Application/uap:ApplicationContentUriRules"> <!-- Allow Webviews access to server so the token relay header can be injected --> <uap:Rule Match="http://*.oracle.com:7777/*/*/*/*" Type="include"/> </config-file>
MAFアプリケーションのCordovaプラグインの作成と使用の詳細は、「MAFアプリケーションでのプラグインの使用方法の概要」と「MAFアプリケーションでの追加プラグインの登録」を参照してください。
{ "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }
注意:
「トークン・リレー・レスポンスの解析」チェック・ボックスを選択すると、MAFで、ログインURLに問合せパラメータとしてformat=JSON
が含まれます。URLでこの問合せパラメータを指定する必要はありません。MCSのために構成されているアイデンティティ・プロバイダを使用する場合は、MAFアプリケーション内で構成する接続URL内の問合せパラメータとして、MAFアプリケーションが接続するMCSモバイル・バックエンドIDによって発行された、OAuth ConsumerのためのクライアントIDを提供します。次の例では、MCSモバイル・バックエンドで構成されるSSOをアプリケーションで使用できるようにする接続のために、MAFアプリケーションのconnections.xml
ファイル内で生成されたエントリのサブセットを示します。
<Contents> <login url="http://yourmcsinstance.com/sso/token?clientID=C490B55...FO51"/> <logout url="http://yourmcsinstance.com/sso/appLogout"/> <loginSuccessUrl url="http://yourmcsinstance.com/sso/success/token?clientID=C490B55...FO51"> <parseTokenRelayResponse value="true"/> </loginSuccessUrl> <loginFailureUrl url="http://yourmcsinstance.com/sso/appError"/> … </Contents>
シングル・サインオン認証を構成するには、次の手順を実行します。
MAFアプリケーション・ログインのすべての接続属性が設計時にわからない場合は、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters
APIを使用して、プレースホルダ接続を定義します。タスク内の手順に従って、実行時にプレースホルダ接続を定義するように構成します。
図に示すように、「MAFログイン接続の作成」ダイアログを使用して、開発時に名前付き接続を作成し、実行時にログイン属性を移入してこの接続の定義を完成させることができます。この接続タイプは、デザインタイムに接続属性の一部がわからない場合に特に便利です。
アプリケーション開発者は、AdfmfJavaUtilities.updateSecurityConfigWithURLParameters
APIを使用して、「実行時の名前付き接続の接続属性の更新方法」の説明に従って、設計時に作成されたプレースホルダ接続を完全に定義する必要があります。
設計時にプレースホルダ接続の定義を構成するには:
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%3 Ffunction_id%3DmLogout&SessionTimeOutValue::=28800&IdleTimeOutValue::=7200&CryptoScheme::=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
を使用して接続プロパティの値をオーバーライドする方法の詳細は、「認証前にログイン資格証明をプログラムで構成する方法」を参照してください。ConfigServiceDemoサンプル・アプリケーションのConfigServiceHandler.java
では、overrideConnectionProperty
メソッドを起動して、いくつかの接続プロパティをオーバーライドする方法を示しています。ConfigServiceDemoサンプル・アプリケーションの詳細は、「サンプルのMAFアプリケーション」を参照してください。
ログインすることなくMAFアプリケーションにアクセスするために、MAFで資格証明、ユーザー名および自動ログインを保管することもできます。「MAFログイン接続の作成」ダイアログの「自動ログイン」オプションを使用して、資格証明の保管オプションを選択します。
セキュリティが重要でない場合、MAFはユーザー資格証明の格納をサポートしますが、これは、ログイン・サーバーにリプレイできるか、またはユーザーをローカルで認証するために使用できます(ログイン接続に定義されているモードによって異なります)。資格証明を格納すると、ユーザーはログインしないでMAFアプリケーションにアクセスできるようになるため、ユーザーの操作性が向上します。IDM Mobile SDKを使用すると、MAFは次のモードをサポートできます。
ユーザー名を記憶: MAFはユーザー名をキャッシュし、ログイン・ページのユーザー名フィールドに移入します。ユーザーがパスワードを入力し、ログイン・ボタンをタップして確認すると、MAFはこれらの資格証明を認証サーバーに対してリプレイします。
資格証明を記憶: MAFはユーザー資格証明をキャッシュし、ログイン・ページのユーザー名フィールドとパスワード・フィールドに移入します。ユーザーがログイン・ボタンをタップしてこれらの資格証明を確認すると、MAFはそれらを認証サーバーに対してリプレイします。
自動ログイン - MAFはユーザー資格証明をキャッシュし、以降の認証時にそれらを認証サーバーにリプレイします。このモードでは、ユーザーは、MAFによってユーザーに資格証明を入力または確認するよう求められずにアプリケーションを起動できます。ただし、MAFは、新しいアプリケーション・セッションが開始されたことをユーザーに通知できます。
注意:
ユーザーは、MAFが資格証明を格納するかどうかを決定できます。
図に示すように、「MAFログイン接続の作成」ダイアログの「自動ログイン」ページを使用して、資格証明格納オプションを選択できます。資格証明オプションを選択すると、ユーザー名とパスワードを記憶するオプションによってログイン・ページが設定されるため、デバイスを複数のユーザーが共有する場合は選択しないでください。
アプリケーションの接続情報は、connections.xml
ファイルで得られます。このファイルは、アプリケーションにバンドルできます。このファイルが構成サービス用にホストされている場合、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 Application Development FrameworkによるFusion Webアプリケーションの開発』のconnections.xmlファイルで定義されたルックアップに関する項を参照してください。
マルチテナント対応の接続を作成すると、MAFは、connections.xml
ファイル内で<isMultiTenantAware>
要素の値をtrueに設定します。
「マルチテナント対応」オプションを有効にして、「MAFログイン接続の作成」ダイアログへの入力が完了すると、MAFはtrueに設定された<isMultiTenantAware>
要素をconnections.xml
ファイルに移入します。マルチテナント接続では、ユーザー名はテナント名とユーザー名の組合せです。
接続がマルチテナント対応である場合、ログイン・ページは、JavaScriptユーティリティを使用して認識します。ログイン・ページでそのような接続が検出されると、追加フィールドが表示され、ユーザーは、「MAFログイン接続の作成」(図27-5を参照)で構成したテナント名をそのフィールドに入力する必要があります。ログイン(正しいテナントIDの入力を含む)が成功すると、MAFは、ローカル資格証明ストアにテナントIDを格納します。
connections.xml
ファイルまたはプログラム内でログインURLを定義するときには、そのURLがリクエスト時にファイル転送を発生しないWebリソースを指すようにする必要があります。
保護されたMAF機能へのアクセス権を付与するためのログインURLをconnections.xml
ファイルまたはプログラムを使用して定義する場合、ログインURLはmydocument.txt
のようなファイル・リソースを指すことはできません。このログインURLは、リクエスト時にファイル転送が発生しないWebリソースを指している必要があります。ファイル・リソースが使用されていると、MAFアプリケーションがハングするかログインに失敗して、ユーザーが保護されたMAF機能にアクセスできない場合があります。
アプリケーションのライフサイクル内で、ユーザーは複数のIDを使用してローカルおよびハイブリッドのログイン接続モードでログインおよびログアウトできます。
ローカルおよびハイブリッド・ログイン接続モードでは、リモート接続と同様、ユーザーはアプリケーション・ライフサイクル内で任意の数のIDを使用して、ログインおよびログアウトできます。ログイン接続を定義してこれらの接続モードを使用するとき、現在のセッション・タイムアウト期間内に、保護されているアプリケーション機能にすでにログイン済である場合は、ユーザーは、ローカル資格証明ストアを使用して保護されているアプリケーション機能に再びログインできます。この場合、明示的にログアウトしたユーザーまたはアイドル・タイムアウトが期限切れになっているためにログアウトされたユーザーは、保護されているアプリケーション機能(またはアプリケーション機能を保護するログイン・サーバーによって保護されているその他のアプリケーション機能)に再びログインできます。
注意:
ローカル接続とハイブリッド接続は、基本認証でのみ使用可能です。OAuthおよびFederate SSOはリモート認証を使用するため、認証が成功しない場合、アプリケーション・ユーザーはアプリケーションに再びログインできません。
MAFアプリケーションを移行するときには、maf-feature.xml
ファイルで定義した認証モードが、connections.xml
ファイルのauthenticationMode
属性で定義されていることを確認します。
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">
)の値を移行しないでください(移行すると、デプロイメントが失敗します)。
MAFログイン接続の作成時にカスタム・ヘッダーが定義されていると、connections.xml
ファイルには、customAuthHeaders
要素と個別のヘッダーサブ要素が移入されます。ヘッダーの値は、OverrideConnectionHandler
APIを使用することで実行時に構成できます。
カスタム・ヘッダーを定義して「MAFログイン接続の作成」ダイアログへの入力を完了すると、MAFは、connections.xml
ファイルに、customAuthHeaders
要素および各header
サブ要素を移入します。
カスタム・ヘッダーの値が実行時に指定される場合、MAFアプリケーションはoracle.adfmf.framework.api.AdfmfJavaUtilities
クラスのoverrideConnectionProperty
APIを使用してヘッダー値を構成できます。oracle.adfmf.framework.api.AdfmfAuthConnection
クラスは、connection.xml
XML要素がオーバーライドされている場合に、それらの要素にアクセスして最新の値を取得するための便利な方法です。APIを使用してヘッダーを構成する方法の詳細は、「認証前にログイン資格証明をプログラムで構成する方法」を参照してください。
ログイン(正しいヘッダー値の入力を含む)に成功すると、MAFはヘッダーの詳細をローカルの資格証明ストアに格納するため、HTTPリクエスト時に、セキュアなコール(RESTサービスに対するコールなど)にカスタム・ヘッダーを含めることができます。
MAFアプリケーションがREST Webサービスをコールするときに、ユーザーがローカルに認証されている場合、MAFはログイン・サーバーに対してユーザーを認証します。MAFは、ユーザーが認証されている場合に、REST Webサービスへのアプリケーション・リクエストを実行します。
ユーザーがローカルに認証されると、MAFはMAFアプリケーションがREST Webサービスをコールしたときにログイン・サーバーに対してユーザーをサイレントに認証します。ユーザーの資格証明が認証されると、MAFはREST Webサービスへのアプリケーション・リクエストを実行します。REST Webサービスが401
ステータス・コードを返した場合(未許可)、MAFは、ユーザーにもう一度認証するよう求めます。REST Webサービスが302
コードを返した場合(見つかったか一時的に移動されている)、MAFは、ログイン・サーバーをチェックして、ユーザーが認証されているか確認します。その場合は、コードが302
リダイレクトとして処理されます。
ユーザーがログイン・サーバーに対して認証されていない場合、MAFは、ユーザーにもう一度認証するよう求めます。302
ステータス・コードを返した場合、ログイン・サーバーは、ユーザーに独自のWebページを使用して認証するよう求めることもあります。このような場合、MAFはリダイレクションをサポートしていないため、かわりにユーザーにもう一度MAFログイン・ページを使用してログインするよう求めます。
MAFは、基本認証ヘッダーをHTTP要求に挿入して、アプリケーション機能が保護されたリソースにアクセスできるようにします。
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サービス・コールのヘッダーに挿入します。挿入される資格証明は、認証サーバーへのログインに使用された後でMAFによって永続化された資格証明です。
Webサービスでは、ログイン・ページはなく、かわりに、MAFによってユーザー・アクセスが有効化され、Webサービス・コールのヘッダーに資格証明が挿入されます。Webサービスは、ローカルに格納されている資格証明(ユーザーによる認証サーバーへの最初のログインの成功後、MAFによって保持されている資格証明)を使用してアプリケーション・データにアクセスします。
ローカル資格証明ストアの名前は、ログイン・サーバー接続のadfCredentialStoreKey
属性に反映されます(「MAFアプリケーションの接続の作成時に行われる処理」のadfCredentialStoreKey="Connection_1"
など)。Webサービスがこの資格証明ストアを使用できるようにするには、REST Webサービス接続のadfCredentialStoreKey
属性に対して定義されている名前が、ログイン・サーバーのadfCredentialStoreKey
属性に対して定義されている名前と一致する必要があります。connections.xml
ファイルのadfCredentialStoreKey
属性またはログイン接続名を編集する場合は、値を互いに同じに設定してください。同じ値を維持しないと、MAF実行時例外が発生します。
注意:
connections.xml
ファイルの概要エディタが存在しないため、「プロパティ」ウィンドウを使用して、<Reference>
要素のadfcredentialStoreKey
属性をログイン・サーバー接続のadfCredentialStoreKey
属性用に構成されている名前で更新してください。または、「ソース」エディタを使用して属性を追加または更新できます。
「資格証明の挿入に関する必知事項」を参照してください。
アプリケーションに保護対象のコンポーネントが含まれている場合は、そのコンポーネントがアクセス制御サービスを実装してホストするように構成します。タスク内の手順に従ってアクセス制御を構成し、ユーザーに許可したアプリケーション機能のみが使用可能になるようにします。
アクセス制御サービス(ACS)は、JSONを使用したRESTful Webサービスであり、オプションでMAFアプリケーションとは別の外部サーバー上にデプロイすることができます。通常は、アプリケーション機能に保護されたコンポーネントが含まれている場合に、ユーザーが単一のHTTP POSTメッセージを介して自身のユーザー・ロールと権限をダウンロードできるよう、MAFアプリケーションにACSサービスを提供します。このサービスをアプリケーションに提供する場合は、ACSサービスを実装してホストする必要があります(MAでは、このサービスは提供されません)。「MAFログイン接続の作成」ダイアログの「認可」ページを図に示します。このページを使用してMAFアプリケーションのアクセス制御を構成します。
アプリケーション・ログイン・サーバーによって付与されるアクセス制御は、「ユーザー制約とアクセス制御について」で説明されているように、アプリケーション機能用に構成された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は、取得されたユーザー・ロールと権限に照らして各アプリケーション用に構成されている制約を評価し、関連付けられているすべての制約を満たすユーザーのみがアプリケーション機能を使用できるようにします。
アクセス制御を構成するには:
アクセス制御サービス(ACS)は、ユーザーが単一のHTTP POST
メッセージを介して自身のユーザー・ロールと権限をダウンロードできるようにする、JSONを使用したREST Webサービスです。これは、特定のユーザーのロールまたは権限(あるいはその両方)を戻すリクエスト・メッセージです。
必要なロールと権限のリストを提供することで、特定のロールと権限を戻すこともできます。リクエスト・メッセージは、次のもので構成されています。
リクエスト・ヘッダー・フィールド: If-Match
、Accept-Language
、User-Agent
、Authorization
、Content-Type
、Content 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-Modified
、Content-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サービスのヘッダーに自動的に資格証明が追加されます。
ACSサービスを実装してホストする必要があり、MAFでは、このサービスは提供されません。
MAFは、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
オブジェクトとして戻されます(「基本認証ヘッダーの挿入に関する必知事項」を参照)。appLogin
パラメータをtrue
に設定すると、ACSでフィーチャ・アクセスが再評価できます。OptionalExtraPayLoad
パラメータは、今後の使用のために予約済であるため使用されません。
invokeACS
メソッドまたはisAcsCalledAutomatically
パラメータのいずれかを使用してACSを起動すると、アプリケーションにロール・ベースの制約が取得されます。
注意:
connections.xml
ファイルに<isAcsCalledAutomatically value = "false"/>
が含まれていない場合、MAFは、ログインに成功した後、自動的にACSを起動します。
保護されているアプリケーション機能がinvokeACS
メソッドをコールすると、MAFは、保護されているアプリケーション機能に構成されている制約を含む、アプリケーション・ログイン接続に関連付けられたすべてのアプリケーション機能のユーザー制約をフェッチします。保護されていないアプリケーション機能がこのメソッドをコールすると、MAFは、ログイン接続に関連付けられた制約を取得するのみです。
注意:
invokeACS
メソッドに加え、AdfmfJavaUtilities
クラスには、次のライフサイクル・メソッドが含まれています。
applicationLogout
: アプリケーション・ログイン接続をログアウトします。
featureLogout(
<feature_ID>
)
: アプリケーション機能に関連付けられたログイン接続をログアウトします。
詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。
MAFアプリケーションがログイン接続を起動してユーザーを認証する前に、接続値をプログラムで設定できます。
この方法は通常、「MAFログイン接続の作成」ダイアログでカスタム・ヘッダー名を定義し、値は実行時に指定する場合に必要になります。接続の詳細をプログラムで構成するには、MAFアプリケーションでoracle.adfmf.framework.api.AdfmfJavaUtilities
クラスのoverrideConnectionProperty
APIを呼び出すことができます。このAPIは、現在の接続プロパティを新しい値でオーバーライドし、オーバーライドされた値でアプリケーションがログインを開始できます。
接続値をプログラムでオーバーライドするには、次の一般的なプロセスが必要です。
オーバーライドするプロパティを定義するXML要素の名前をconnections.xml
ファイルから取得する。
認証の前にオーバーライド値を取得する。たとえば、MAFアプリケーションでは、この目的のために、ユーザーに値の入力を要求するようにAMXページを定義できます。
オーバーライド・メソッドを実装するマネージドBeanを起動し(接続プロパティのオーバーライドごとに1つ)、ゲッター・メソッドとセッター・メソッドを定義する。たとえば、AMXページの場合、ユーザーがコマンド・ボタンをクリックすると、そのユーザーの入力値がマネージドBean上で送信されます。
接続プロパティのオーバーライドを指定するには、connections.xml
ファイルを調べて、次のXML要素の定義を取得します。
接続参照名。たとえば、ConnWithCustomHeader
です。
オーバーライドする属性を定義するプロパティのXML要素名。たとえば、テナント・ドメイン名の伝播に使用されるスキームのmultiTenantScheme
です。
オーバーライドするプロパティの属性を定義するXMLサブ要素名。一意の接続プロパティの場合は、常にvalue要素になります。
注意:
カスタム・ヘッダー定義では、同じ要素名を使用して値を指定するため、カスタム・ヘッダーの場合は、XML要素headerおよびvalueを使用しないでください。かわりに、カスタム・ヘッダーにはContents、プロパティおよび属性にはcustomAuthHeaders
を使用して、オーバーライド・メソッドにそれぞれ渡してください。
たとえば、カスタム・ヘッダーの値をオーバーライドするには、次の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では、接続プロパティのオーバーライドごとにオーバーライド・メソッドを実装します。次の例では、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-feature.xml
ファイルとmaf-application.xml
ファイルの概要エディタ、および「MAFログイン接続の作成」ダイアログを使用して、MAFアプリケーションのセキュリティを構成します。
maf-feature.xml
とmaf-application.xml
ファイルの概要エディタ、および「MAFログイン接続の作成」ダイアログを使用して、セキュリティを構成します。概要エディタを使用すると、認証を必要とするアプリケーション機能をユーザーが選択したときにMAFによって表示されるログイン・ページのタイプ(デフォルトまたはカスタム)を指定したり、ユーザー・ロールまたはユーザー権限ベースの制約を含めることができます。また、セキュリティが必要な埋込みアプリケーション機能を選択することもできます。
セキュリティが適用されるように各アプリケーション機能を定義できます。セキュリティ構成は、maf-application.xml
の概要エディタの「セキュリティ」ページを使用して実行します。
maf-feature.xml
概要エディタでは、セキュリティを適用するアプリケーション機能を指定できます。
始める前に:
機能のセキュリティを有効化すると、アプリケーションは、ネットワークにアクセスしてユーザーを認証する必要があります。ネットワーク・ソケットへのアプリケーション・アクセス権の付与の詳細は、「MAFアプリケーションでのコア・プラグインの有効化」を参照してください。
アプリケーション機能に対するユーザー・アクセスを指定するには:
アプリケーション機能にセキュリティを定義したら、maf-application.xml
概要エディタの「セキュリティ」ページを使用して、ログイン・ページの構成、ログイン・サーバーへの接続の作成、およびセキュリティが有効化されたアプリケーション機能への接続の割当てを実行します。タスク内の手順に従って、ログイン・ページを指定します。
アプリケーション機能のセキュリティを指定したら、次の図に示されているmaf-application.xml
概要エディタの「セキュリティ」ページを使用して、セキュリティが適用される各アプリケーション機能に対して、ログイン・ページの構成およびログイン・サーバーへの接続の作成と割当てを行います。このページにリストされているすべてのアプリケーション機能は、maf-feature.xml
ファイルで、セキュリティが必要なものとして指定されています。
通常、アプリケーション機能のグループは、同じログイン・サーバー接続で保護され、ユーザーは、MAFから再度ログインを求められることなく、これらのアプリケーションをどれでも開くことが可能です。ただし、場合によっては、あるアプリケーション機能のセットを保護しているログイン・サーバーと、別のアプリケーション機能のセットを保護しているログイン・サーバーが異なるため、アプリケーション機能で要求される資格証明がそれぞれ異なる可能性があります。このような状況に対応するために、MAFアプリケーション用のログイン・サーバーへの接続をいくつも定義できます。maf-application.xml
ファイルでは、機能参照に関連付けられている認証サーバー接続は、次のようにloginConnRefId
属性を使用して指定されます。
<adfmf:featureReference refId="feature1" loginConnRefId="BasicAuthentication"/> <adfmf:featureReference refId="feature2" loginConnRefId="WebSSO"/>
MAFアプリケーションは、HTTPまたはHTTPS経由のBasic認証をサポートしている標準のログイン・サーバーなら、どのログイン・サーバーに対しても認証を受けることが可能です。MAFはまた、Oracle Identity Managementに対する認証もサポートしています。特定のアプリケーション機能用のカスタム・ログイン・ページを選択することもできます。「ログイン・ページに関する必知事項」を参照してください。
注意:
デフォルトでは、保護されているすべてのアプリケーション機能が同じ接続を共有します。この接続は、<application login server>
と表示されます。「機能参照」の「プロパティ」ウィンドウには、このデフォルト・オプションが「ログイン・サーバー接続」ドロップダウン・メニューに<default> (application login server)
と表示されます。「MAFログイン接続の作成」ダイアログを使用して、MAFアプリケーション用に定義されている他の接続を選択できます。
始める前に:
MAFアプリケーションでカスタム・ログイン・ページを使用する場合は、アプリケーション・コントローラ・プロジェクトのpublic_html
ディレクトリ(JDeveloper\mywork\
Application
\ApplicationController\public_html
)にファイルを追加して、次の図に示すように、「アプリケーション・ナビゲータ」の「Webコンテンツ」ノードからそれを使用できるようにします。「カスタム・ログインHTMLページの作成方法」および「外部リソースの選択に関する必知事項」も参照してください。
「ユーザー制約とアクセス制御について」の説明に従って、ユーザー権限とロール用の制約を追加します。
アクセス制御サービス(ACS)・サーバーをプロビジョニングします。「アクセス制御サービスに関する必知事項」を参照してください。
ログイン・ページを指定するには:
デフォルトのログイン・ページadf.login.html
と、MAFのデプロイメントによってwww
ディレクトリに生成されるアーティファクトを変更することで、カスタム・ログイン・ページを作成します。タスク内の手順に従って、カスタム・ログイン・ページを作成し、その場所を取得します。
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
カスタム・ログイン・ページを作成するには:
public_html
ディレクトリ(JDeveloper\mywork\
application name
\ApplicationController\public_html
など)内にコピーします。maf-application.xml
ファイルの概要エディタの「セキュリティ」ページで、「カスタム」を選択し、「参照」をクリックしてログイン・ページの場所を検索します。MAFに登録した機能がアクティブ化されると、ログイン・プロセスが実行されます。認証の成功時に、ログイン・ページは指定された宛先を取得して、その宛先に移動します。
アプリケーション機能の認証プロセスのエントリ・ポイントは、「MAFアプリケーションでのライフサイクル・リスナーの使用方法」で説明されているactivate
ライフサイクル・イベントです。アプリケーション機能がアクティブになる(つまり、アプリケーション機能のactivate
イベント・ハンドラがコールされる)たびに、アプリケーション機能のログイン・プロセスが実行されます。このプロセスは、ログイン・ページ(デフォルトまたはカスタムのログイン・ページのいずれか)に移動し、そこでユーザー認証が必要かどうかを判断します。ただし、プロセスがログイン・ページに移動する前に、本来意図されていたアプリケーション機能をMAFに登録する必要があります。認証が成功すると、ログイン・ページは、MAFから本来意図されていた宛先を取得し、そこに移動します。
組込みCordovaサポートを使用して、ログイン・ページからリソース・バンドルなどのJavaクラスまたはリソースを使用する場合は、ApplicationController
プロジェクトにこれらのクラスおよびリソースを配置する必要があります。
MAFが提示するデフォルトのログイン・ページは、HTMLで記述されたクロス・プラットフォームのページです。このページには、資格証明用のフィールドが含まれています。
MAFによって提供されるデフォルトのログイン・ページは、ログイン・ボタンと、ユーザー名とパスワード用の入力テキスト・フィールド、マルチテナント名(オプション)、およびエラー・メッセージ・セクションから構成されます。これは、HTMLで記述されたクロス・プラットフォーム・ページです。デザインタイムでマルチテナント対応オプションを有効にしたデフォルトのログイン・ページを図に示します。このページでは、ユーザー名とパスワードの他、テナントのドメイン名の入力が要求されます。
カスタム・ログイン・ページには、デフォルトのログイン・ページと同じ認証メカニズムとナビゲーション・コントロールが含まれています。カスタム・ログイン・ページが追加されると、JDeveloperは<adfmf:login>
要素を追加して、その子要素の<adfmf:LocalHTML>
を移入します。
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で記述されています。ログイン・ページのフィールドには、具体的に定義された<input>
要素および<label>
要素を含める必要があります。
ヒント:
カスタム・ログイン・ページを作成するためのガイドとしてMAFアプリケーションのデプロイ時に生成されたデフォルトのログイン・ページを使用します。「カスタム・ログインHTMLページの作成方法」で説明されているように、www
ディレクトリ内のログイン・ページにアクセスするには、MAFアプリケーションをデプロイした後、deploy
ディレクトリに移動します。
次の例は、デフォルト・ログイン・ページに必要な<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ログイン・ページに、表27-2にリストされたユーザー・インタフェース要素が含まれている必要があります。
表27-2 ログイン・ページのフィールドおよび関連するID
ページ要素 | ID |
---|---|
ユーザー名フィールド |
|
パスワード・フィールド |
|
ログイン・ボタン |
|
取消ボタン |
|
「Identityドメイン」/「テナント名」フィールド |
|
エラー・フィールド |
|
自動ログイン・チェック・ボックス |
|
資格証明記憶チェック・ボックス |
|
ユーザー名記憶チェック・ボックス |
|
表27-3は、OnClick
イベントで使用される推奨のJavaScriptコードをリストしています。
表27-3 OnClickイベントで使用されるJavaScript
ボタン | JavaScript |
---|---|
ログイン・ボタン |
|
取消ボタン |
|
セキュリティが有効化されたアプリケーションごとに、JDeveloperは、対応する機能参照を「セキュリティが有効な機能」表に追加します。
セキュリティが適用されるようにアプリケーション機能が指定されると、JDeveloperは、対応する機能参照で「セキュリティが有効な機能」の表を更新します。参照される各アプリケーション機能が、connections.xml
ファイル内に定義されている同じログイン・サーバー接続に対して認証を行うと、JDeveloperは、defaultConnRefId
属性を使用して定義されている単一の<adfmf:login>
要素(<adfmf:login defaultConnRefId="Connection_1">
など)でmaf-application.xml
ファイルを更新します。
connections.xml
ファイル内に定義されている別のログイン・サーバー接続を使用するように構成されているアプリケーション機能の場合は、JDeveloperは、参照される各アプリケーション機能をloginConnReference
属性(<adfmf:featureReference refId="feature2" loginConnRefId="Connection2"/>
)で更新します。「認証を要求するようにアプリケーション機能を設定する方法」を参照してください。Oracle Mobile Application Frameworkタグ・リファレンスも参照してください。
デバイス機能へのアクセスは、MAFアプリケーションに組み込まれているCordovaプラグインによって定義されます。MAFで提供されるコア・プラグインの1つを有効にすると、そのアプリケーションに必要なすべてのデバイス・アクセス権限が有効になります。
MAFアプリケーションに組み込まれている他のCordovaプラグインも、必要なデバイス・アクセス権限を有効にします。MAFアプリケーションの大多数ではネットワーク・アクセスが必要なため、ネットワークにアクセスする権限はデフォルトで有効になっています(デフォルトで有効になっている唯一のデバイス機能)。
ネットワーク情報: アプリケーションによるネットワーク・ソケットのオープンを許可します。少なくとも1つのデバイス機能のセキュリティが有効な場合、ネットワーク・アクセス機能は有効にしておく必要があります。
デバイス機能の有効化または制限が可能なため、デプロイメント・フレームワークによって更新されるプラットフォーム固有の様々な構成ファイルやマニフェスト・ファイルでは、使用中のデバイス機能(または、MAFアプリケーションに使用が登録されているプラグイン)のみがリストされます。これらのファイルにより、MAFはこれらの機能の使用に関する情報を他のアプリケーションと共有できます。たとえば、AppStoreやGoogle Playに対して、MAFアプリケーションで場所ベースの機能が(搭載されていても)使用されていないことを通知できます。
MAFアプリケーション内の選択したアプリケーション機能がネイティブ・コンテナにアクセスすること、および拡張機能によってMAFアプリケーションがデバイス機能にアクセスすることを防止できます。たとえば、自分のMAFアプリケーションに、リモート・コンテンツを参照する、信頼できないWebアプリケーションからのアプリケーション機能が含まれているとします(リモートURLコンテンツのアプリケーション機能)。このシナリオでは、次の例に示すように、この特定のアプリケーション機能がネイティブ・コンテナにアクセスすることを防止します。
<adfmf:featureReference refId="remoteAppfeature1" id="fr1" allowNativeAccess="false"/>
allowNativeAccess
プロパティのデフォルト値はtrue
です。
MAFアプリケーションのCordovaプラグインの詳細は、「MAFアプリケーションでのプラグインの使用方法」を参照してください。
ユーザーが、保護されているコンテンツを含むアプリケーション機能からログアウトするとき、または制約によって制限されているときは、MAFはアプリケーション機能を終了せず、またユーザーはアプリケーション内でログイン状態を維持し、セキュアでないコンテンツおよび機能に匿名ユーザーとしてアクセスできます。
MAFでは、制約を再初期化できるため、ユーザーは、同じアイデンティティを使用して、アプリケーションに繰り返しログインできます。また、MAFは、ユーザーに別のアイデンティティを使用したログインを許可することで、複数のアイデンティティでアクセスを共有できます。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を使用すると、エンド・ユーザーがデバイスを共有しているシナリオで役立つ場合があります。
次の例は、実装クラスからのコードのスニペットを示しており、AuthenticationPlatform
のインスタンスはそのgetToken()
APIを使用して認可ヘッダー情報を取得します。
例27-1 認証プラットフォームからの認可ヘッダーの取得
import oracle.maf.api.authentication.AuthenticationPlatform; import oracle.maf.api.authentication.AuthenticationUtility; … AuthenticationPlatform ap = AuthenticationUtility.getInstance().lookupByCredentialStoreKey("credentialStoreKey"); String authorization = ap.getToken("Authorization"); …
これらの認証クラスの詳細は、Oracle Mobile Application Framework Java APIリファレンスを参照してください。
MAFのcacerts
ファイルにより、信頼できるソースからの証明書を識別することでデプロイメントが可能になります。タスク内の手順に従って、MAFのcacerts
ファイルにプライベート証明書を追加します。この手順は、自己署名証明書を使用しているサーバーのリソースにアプリケーションがアクセスする必要がある場合や、アプリケーションがカスタムの証明書を必要とする場合に実行します。
MAFは、cacerts
証明書ファイル(HTTPSハンドシェークのためのクライアント・アプリケーションおよびサーバー間のJavaメカニズム)を提供します。JDeveloperは、アプリケーション・リソースのSecurity
フォルダ内にこのファイルを作成します(JDeveloper\mywork\application name\resources\Security\cacerts
にあります)。MAFのcacerts
ファイルにより、信頼できる既知のソースからの一連の証明書がJVMに対して識別され、デプロイメントが可能になります。
サーバーが自己署名証明書を使用しているサーバー・リソースにアプリケーションがアクセスする必要がある場合は、プライベート証明書をMAFのcacerts
ファイルに追加する必要があります。アプリケーションでカスタム証明書が必要な場合(RSA暗号化が使用されていない場合など)も、プライベート証明書を追加する必要があります。アプリケーションをデプロイする前に、プライベート証明書を追加します。MAFアプリケーションのユーザーは、「MAFアプリケーションでのSSL証明書のファイル拡張子の登録」で説明するように、証明書のインストールを容易にするようアプリケーションを構成してある場合に証明書をインストールできます。
始める前に:
cacerts
ファイルの内容を理解しておくと役立ちます。『Oracle Mobile Application Frameworkのインストール』のMAFの新しいSSL用cacertsファイルへの移行に関する項を参照してください。
JDeveloperによるcacerts
ファイルの作成方法についても理解しておくと役立ちます。「アプリケーション・コントローラ・プロジェクト・レベルのリソースについて」を参照してください。
cacerts
ファイルおよびkeytoolユーティリティの使用方法については、Java SEテクニカル・ドキュメント(http://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
各証明書に対して同じ手順を繰り返します。表27-4は、keytoolのオプションを示しています。
表27-4 証明書の追加に関するオプション
オプション | 説明 |
---|---|
|
証明書をインポートします。 |
|
インポートされた証明書のファイルの場所を特定します。 |
|
新しい証明書を含むファイルを特定します。 |
|
|
- |
証明書を信頼するかどうかを( |
新しいcacerts
ファイルの内容を目で見て調べて、すべてのフィールドが正しいことを確認します。次のコマンドを使用します。
keytool -list -v -keystore cacerts | more
証明書が指定のホスト名に対するものであることを確認します。
注意:
証明書の共通名(CN)は、ホスト名と正確に一致している必要があります。
JVMが読み取れるようにするために、カスタマイズされた証明書ファイルはSecurity
ディレクトリ(JDeveloper\mywork\
application name
\resources\Security
)に確実に配置してください。
アプリケーションをデプロイします。
注意:
デプロイメント時、証明書ファイルがSecurity
ディレクトリに存在している場合、MAFは、それをAndroidまたはXcodeテンプレート・プロジェクトにコピーし、cacerts
ファイルのデフォルト・コピーを置き換えます。
保護されているリソースにSSL経由でアクセスできることを確認します。
MAFアプリケーションのエンド・ユーザーは、SSL通信での使用のために、デジタル証明書を自分のアプリケーションのキーストアにインストールできます。これらの証明書のインストールを容易にするために、ファイル拡張子を登録します。
MAFアプリケーションは、デバイス上でファイル拡張子を登録してある唯一のアプリケーションである場合、エンド・ユーザーに配布される証明書ファイル(電子メールの添付ファイルまたはダウンロードURLによって配布される)を開くためにデバイスのオペレーティング・システムがエンド・ユーザーに対して提示するアプリケーションとなります。他のアプリケーションがファイル拡張子を登録している場合、デバイスのオペレーティング・システムはアプリケーションのリストを提示し、エンド・ユーザーはそこからMAFアプリケーションを選択して、自分のアプリケーションのキーストアに証明書をインストールする必要があります。
MAFアプリケーションが実行するサポートされているプラットフォームのバージョンによっては、ファイルがBase64テキスト形式(.PEM
など)で保存されている場合、証明書ファイルをテキスト・ファイルとして扱い、エンド・ユーザーに証明書をインストールするように要求するのではなく、テキスト・ファイルとして開くことがあります。この問題を避けるために、Base64テキスト形式ではなく、バイナリ形式(.DER
など)を使用することをお薦めします。
MAFでは、サーバーSSL証明書およびクライアントSSL証明書の両方のファイル拡張子の登録がサポートされています。ユーザーは、証明書をインストールした後に、MAFアプリケーションの再起動が必要になることがあります。
サーバーSSL証明書の拡張子
サーバーSSL証明書によって、MAFアプリケーションが接続するリモートHTTPSサーバーが識別されます。サーバーSSL証明書のファイル拡張子を登録して、MAFアプリケーションの作成時にMAFによって提供されるcacerts
ファイル内にない証明書のインストールを容易にします。このシナリオは、MAFアプリケーションが接続するHTTPSサーバーで、ルート認証局で発行された証明書ではなく自己署名による証明書が使用される場合によく起こります。MAFでは、現在、AndroidプラットフォームとiOSプラットフォームにデプロイされたMAFアプリケーションでのサーバーSSL証明書のインストールがサポートされています。これは、ユニバーサルWindowsプラットフォームにデプロイされたMAFアプリケーションではサポートされていません。このプラットフォームの場合は、SSL用の自己署名証明書を使用するサーバーにアクセスするための証明書の作成で説明するように、証明書をMAFアプリケーションのcacerts
ファイルに追加します。
クライアントSSL証明書の拡張子
クライアント証明書は、リモート・サーバーに対してMAFアプリケーションを識別します。ユーザーに、クライアント証明書をMAFアプリケーションのキーストアにインストールして、双方向SSL、相互認証または双方向認証として知られるプロセスを使用して認証することを可能にする場合に、クライアントSSL証明書の拡張子を登録します。ユーザーがクライアント証明書をインストールすると、MAFアプリケーションはその証明書をサーバーに提示できるため、双方向SSL通信セッションによりクライアントとサーバー間の認証が実行されます。
iOSプラットフォームでは、サード・パーティ製アプリケーションがクライアント証明書のデフォルトの拡張子(.p12
)を使用してファイルを開くことが許可されていません。この制限を回避するために、アプリケーション開発者は別の証明書拡張子(.cert
など)を登録する必要があります。証明書を配布する管理者は、別の拡張子を使用するようにクライアント証明書の名前を変更して、MAFアプリケーションのユーザーが電子メール添付ファイル、またはクライアント証明書の配布に使用するURLから直接クライアント証明書を開くことができるようにします。
SSL証明書のファイル拡張子の登録方法
証明書のファイル拡張子をアプリケーションに登録するには、maf-application.xml
ファイルの概要エディタの「アプリケーション」ページの適切なフィールド(ユース・ケースによって異なる)にそのファイル拡張子を入力します。
双方向SSLを有効にするためにMAFアプリケーションを構成するには:
「アプリケーション」ウィンドウで、「アプリケーション・リソース」パネルを展開します。
「アプリケーション・リソース」パネルで「ディスクリプタ」を展開し、「ADF META-INF」を展開します。
maf-application.xmlファイルをダブルクリックし、表示される概要エディタで「アプリケーション」ナビゲーション・タブをクリックします。
「アプリケーション」ページで、適切なオプションを選択します。
双方向SSLセッションでの使用のためのクライアント証明書のインストールを容易にする場合は、「クライアントSSL証明書の拡張」フィールドにファイル拡張子を入力します。
MAFアプリケーションでHTTPSサーバーへの接続に使用される、サーバー証明書のインストールを容易にする場合は、「サーバーSSL証明書の拡張」フィールドにファイル拡張子を入力します。
SSL証明書のファイル拡張子の登録時に起こること
入力フィールドに入力した値がJDeveloperによってmaf-application.xml
ファイルに書き込まれます(例27-2を参照)。
実行時に、ユーザーは、証明書を管理者が配置した場所からデバイスにダウンロードするか、または電子メール添付ファイルから自動的に開きます。サーバーの場所からのダウンロード動作は、ユーザーのデバイスのオペレーティング・システムによって異なります。たとえば、Androidデバイスを使用するMAFアプリケーション・エンド・ユーザーは、証明書をAndroidのDownload
ディレクトリにダウンロードします。ダウンロードすると、ユーザーはMAFアプリケーションのキーストアにインストールするために証明書を抽出します(開きます)。クライアント証明書についてこのステップを完了するには、ユーザーは、クライアント証明書を配布した管理者が提供したパスワードを入力する必要があります。ユーザーがアプリケーションのキーストアに証明書をインストールすると、MAFアプリケーションはその証明書をサーバーに提示して、双方向SSLセッションを確立できます。ユーザーがインストールしたサーバー証明書は、HTTPSサーバーとのSSLセッションを確立するためにMAFで使用できます。
例27-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="ssltest" id="com.company.ssltest" appControllerFolder="ApplicationController" listener-class="application.LifeCycleListenerImpl" client-ssl-certificate-extension="clientcert" server-ssl-certificate-extension="servercert"> ….