認証およびセキュリティー

概説

MobileFirst セキュリティー・フレームワークは、OAuth 2.0 プロトコルに基づいています。 このプロトコルに従って、リソースは、そのリソースにアクセスするために必要な許可を定義するスコープによって保護されます。 保護リソースにアクセスするために、クライアントは一致するアクセス・トークンを提供する必要があります。アクセス・トークンは、クライアントに付与される許可のスコープをカプセル化したものです。

OAuth プロトコルは、許可サーバーのロールと、リソースがホストされているリソース・サーバーのロールを分離します。

• 許可サーバーは、クライアント許可およびトークン生成を管理します。
• リソース・サーバーは、許可サーバーを使用して、クライアントから提供されたアクセス・トークンを検証し、要求されたリソースの保護スコープに一致しているか確認します。

セキュリティー・フレームワークは、OAuth プロトコルを実装する許可サーバーに基づいて構築され、クライアントがアクセス・トークンを取得するために対話する OAuth エンドポイントを公開します。 セキュリティー・フレームワークは、許可サーバーと基礎となる OAuth プロトコルをベースとしたカスタム許可ロジックを実装するためのビルディング・ブロックを提供します。 デフォルトでは、MobileFirst Server が許可サーバーとしても機能します。 しかし、IBM WebSphere DataPower アプライアンスを許可サーバーとして機能するように構成し、MobileFirst Server と対話するように構成することもできます。

クライアント・アプリケーションは、その後、これらのトークンを使用してリソース・サーバー上のリソースにアクセスできます。リソース・サーバーには、MobileFirst Server 自体または外部サーバーを使用できます。 リソース・サーバーはトークンの妥当性をチェックし、要求されたリソースへのアクセスをクライアントに認可していいかを検査します。 リソース・サーバーと許可サーバーを分離することで、MobileFirst Server の外部で稼働するリソースに対してセキュリティーを適用することが可能になります。

アプリケーション開発者は、各保護リソースに必要なスコープを定義し、セキュリティー検査およびチャレンジ・ハンドラーを実装することで、リソースへのアクセスを保護します。 サーバー・サイドのセキュリティー・フレームワークとクライアント・サイド API は、OAuth メッセージ交換と許可サーバーとの対話を透過的に処理し、開発者が許可ロジックにのみ焦点を当てることができるようにします。

ジャンプ先:

• 許可エンティティー
• リソースの保護
• 許可フロー
• 次に使用するチュートリアル

許可エンティティー

アクセス・トークン

MobileFirst アクセス・トークンは、クライアントの許可アクセス権を記述したデジタル署名済みエンティティーです。 特定のスコープについてクライアントの認証要求が許可され、クライアントが認証されると、許可サーバーのトークン・エンドポイントは、要求されたアクセス・トークンを含む HTTP 応答をクライアントに送信します。

構造

MobileFirst アクセス・トークンには、以下の情報が含まれます。

• クライアント ID: クライアントの固有 ID。
• スコープ: トークンが適用される有効範囲 (OAuth スコープを参照)。 このスコープには、必須アプリケーション・スコープは含まれません。
• トークンの有効期限: トークンが無効 (期限切れ) になる時間 (秒数)。

トークンの有効期限

付与されたアクセス・トークンは、有効期限時刻が経過するまで有効になります。 アクセス・トークンの有効期限時刻は、スコープ内のすべてのセキュリティー検査の有効期限時刻の中で最短の有効期限時刻に設定されます。 ただし、最短の有効期限時刻までの期間が、アプリケーションの最大トークン有効期限期間よりも長い場合、トークンの有効期限時刻は現在時刻に最大有効期限期間を加算したものに設定されます。 デフォルトのトークンの最大有効期間は 3,600 秒 (1 時間) ですが、maxTokenExpiration プロパティーの値を設定することで、期間を構成できます。 『アクセス・トークンの最大有効期間の構成』を参照してください。

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache
{
    "token_type": "Bearer",
    "expires_in": 3600,
    "access_token": "yI6ICJodHRwOi8vc2VydmVyLmV4YW1",
    "scope": "scopeElement1 scopeElement2"
}

リフレッシュ・トークン

リフレッシュ・トークンは特殊なタイプのトークンであり、アクセス・トークンの有効期限が切れたときに新しいアクセス・トークンを取得するために使用できます。 新しいアクセス・トークンを要求するには、有効なリフレッシュ・トークンを提示します。 リフレッシュ・トークンは存続期間が長いトークンであり、アクセス・トークンと比較してより長い期間有効です。

リフレッシュ・トークンは、ユーザーが永続的に認証済みのままになることができるため、アプリケーションでは注意して使用する必要があります。 アプリケーション・プロバイダーがユーザーを定期的に認証しないソーシャル・メディア・アプリケーション、e-commerce アプリケーション、製品カタログ・ブラウズ・アプリケーションなどのユーティリティー・アプリケーションでは、リフレッシュ・トークンを使用できます。 頻繁なユーザー認証を要求するアプリケーションでは、リフレッシュ・トークンの使用を避ける必要があります。

MobileFirst リフレッシュ・トークン

MobileFirst リフレッシュ・トークンは、クライアントの許可アクセス権を記述したアクセス・トークンのような、デジタル署名されたエンティティーです。 リフレッシュ・トークンは、同じスコープの新しいアクセス・トークンを取得するために使用できます。 特定のスコープについてクライアントの認証要求が許可され、クライアントが認証されると、許可サーバーのトークン・エンドポイントは、要求されたアクセス・トークンとリフレッシュ・トークンを含む HTTP 応答をクライアントに送信します。 アクセス・トークンの有効期限が切れると、クライアントは、新しいアクセス・トークンとリフレッシュ・トークンのセットを取得するために、許可サーバーのトークン・エンドポイントにリフレッシュ・トークンを送信します。

構造

MobileFirst アクセス・トークンと同様、MobileFirst リフレッシュ・トークンには以下の情報が含まれています。

• クライアント ID: クライアントの固有 ID。
• スコープ: トークンが適用される有効範囲 (OAuth スコープを参照)。 このスコープには、必須アプリケーション・スコープは含まれません。
• トークンの有効期限: トークンが無効 (期限切れ) になる時間 (秒数)。

トークンの有効期限

リフレッシュ・トークンのトークン有効期間は、一般的なアクセス・トークンの有効期間よりも長くなっています。 付与されたリフレッシュ・トークンは、有効期限時刻が経過するまで有効になります。 この有効期間内に、クライアントはリフレッシュ・トークンを使用して、新しいアクセス・トークンとリフレッシュ・トークンのセットを取得できます。 リフレッシュ・トークンには、30 日の固定の有効期間があります。 クライアントが新しいアクセス・トークンとリフレッシュ・トークンのセットを正常に受信するたびに、リフレッシュ・トークンの有効期限がリセットされるため、クライアントではトークンの有効期限が切れることはありません。 アクセス・トークンの有効期限ルールは、アクセス・トークンのセクションで説明されているものと同じです。

            <jndiEntry jndiName="mfp/mfp.security.refreshtoken.enabled.apps" value='"com.sample.android.myapp1;com.sample.android.myapp2"'/>
            

        HTTP/1.1 200 OK
        Content-Type: application/json
        Cache-Control: no-store
        Pragma: no-cache
        {
            "token_type": "Bearer",
            "expires_in": 3600,
            "access_token": "yI6ICJodHRwOi8vc2VydmVyLmV4YW1",
            "scope": "scopeElement1 scopeElement2",
            "refresh_token": "yI7ICasdsdJodHRwOi8vc2Vashnneh "
        }
        

注: リフレッシュ・トークンの存続期間は、アクセス・トークンと比較して長くなります。 そのため、リフレッシュ・トークン機能は注意して使用する必要があります。 定期的なユーザー認証が必要ないアプリケーションが、リフレッシュ・トークン機能を使用する場合に理想的な候補となります。

MobileFirst は、CD update 3 から iOS でリフレッシュ・トークンをサポートしています。

セキュリティー検査

セキュリティー検査は、サーバー・サイドのアプリケーション・リソースを保護するためのセキュリティー・ロジックを実装するサーバー・サイド・エンティティーです。 セキュリティー検査の簡単な例として、ユーザーの資格情報を受け取り、ユーザー・レジストリーに照らして資格情報を検査する、ユーザー・ログイン・セキュリティー検査があります。 別の例として、事前定義されている MobileFirst アプリケーション認証性セキュリティー検査があります。これは、モバイル・アプリケーションの認証性を検査することで、アプリケーションのリソースへの不正なアクセスから保護します。 同じセキュリティー検査を使用して、複数のリソースを保護することもできます。

セキュリティー検査は通常、クライアントが検査に合格するために特定の方法で応答する必要がある、セキュリティー・チャレンジを発行します。 このハンドシェークは、OAuth アクセス・トークン獲得フローの一部として発生します。 クライアントはチャレンジ・ハンドラーを使用して、セキュリティー検査のチャレンジを処理します。

組み込みセキュリティー検査

以下の事前定義セキュリティー検査を使用できます。

• アプリケーション認証性
• LTPA ベースのシングル・サインオン (SSO)
• ダイレクト・アップデート

チャレンジ・ハンドラー

クライアントは、保護リソースにアクセスしようとするとき、チャレンジを提示されることがあります。 チャレンジは、クライアントがそのリソースへのアクセスを許可されていることを検査するためにサーバーが出す質問、セキュリティー・テスト、またはプロンプトです。 一般的に、このチャレンジは、ユーザー名とパスワードなどの資格情報を要求することです。

チャレンジ・ハンドラーは、クライアント・サイド・セキュリティー・ロジックおよびそれに関連したユーザーとの対話を実装する、クライアント・サイド・エンティティーです。 重要: チャレンジを受け取ると、それを無視することはできません。 応答するか、あるいはキャンセルしなければなりません。 チャレンジを無視すると、予期しない動作が発生するおそれがあります。

セキュリティー検査について詳しくは、セキュリティー検査の作成チュートリアルを参照してください。また、チャレンジ・ハンドラーについては、資格情報の検証チュートリアルを参照してください。

スコープ

アダプターなどのリソースにスコープを割り当てることにより、そのリソースを無許可アクセスから保護できます。

スコープは、スペースで区切った 1 つ以上のスコープ・エレメントからなるストリング (「scopeElement1 scopeElement2 …」) として定義することも、ヌルとして定義してデフォルトのスコープ (RegisteredClient) を適用することもできます。 MobileFirst セキュリティー・フレームワークでは、リソースにスコープが割り当てられていない場合でも、そのリソースのリソース保護を無効にしない限り、あらゆるアダプター・リソースにアクセス・トークンが必要です。 アダプター・リソースの保護を参照してください。

スコープ・エレメント

スコープ・エレメントには、以下のいずれかを指定できます。

• セキュリティー検査の名前。
• そのリソースで必要とされるセキュリティーのレベルを定義した任意のキーワード (access-restricted、deletePrivilege など)。 このキーワードが後でセキュリティー検査にマップされます。

スコープ・マッピング

デフォルトで、スコープ内に記述するスコープ・エレメントは、同じ名前を持つセキュリティー検査にマップされます。 例えば、PinCodeAttempts というセキュリティー検査を作成した場合、同じ名前のスコープ・エレメントをスコープ内に使用できます。

スコープ・マッピングは、スコープ・エレメントからセキュリティー検査へのマップを可能にします。 クライアントがスコープ・エレメントを要求すると、この構成によって、適用されるセキュリティー検査が定義されます。 例えば、スコープ・エレメント access-restricted を PinCodeAttempts セキュリティー検査にマップできます。

どのアプリケーションがリソースにアクセスしようとしているかに応じてリソースを保護する方法を変える必要がある場合、スコープ・マッピングが便利です。 同じスコープをゼロ個以上のセキュリティー検査のリストにマップすることもできます。

例: scope = access-restricted deletePrivilege

• アプリケーション A
  • access-restricted は PinCodeAttempts にマップされます。
  • deletePrivilege は空ストリングにマップされます。
• アプリケーション B
  • access-restricted は PinCodeAttempts にマップされます。
  • deletePrivilege は UserLogin にマップされます。

スコープ・エレメントを空ストリングにマップするには、「新しいスコープ・エレメント・マッピングの追加」ポップアップ・メニューでセキュリティー検査を何も選択しないでください。

必要な構成を指定してアプリケーションの構成 JSON ファイルを手動で編集し、変更を MobileFirst Server にプッシュして戻すこともできます。

1. コマンド・ライン・ウィンドウから、プロジェクトのルート・フォルダーにナビゲートし、mfpdev app pull を実行します。
2. [project-folder]\mobilefirst フォルダーにある構成ファイルを開きます。

3. ファイルを編集して、scopeElementMapping プロパティーを定義します。このプロパティーには、データ・ペアを定義します。各ペアは、選択したスコープ・エレメントの名前と、そのエレメントのマップ先となるゼロ個以上のセキュリティー検査をスペースで区切ったストリングとで構成されます。 例えば、次のとおりです。

    "scopeElementMapping": {
        "UserAuth": "UserAuthentication",
        "SSOUserValidation": "LtpaBasedSSO CredentialsValidation"
    }
   

4. コマンド mfpdev app push を実行することで、更新済み構成 JSON ファイルをデプロイします。

更新済み構成をリモート・サーバーにプッシュすることもできます。 MobileFirst CLI を使用した MobileFirst 成果物の管理チュートリアルを確認してください。

リソースの保護

OAuth モデルでは、保護リソースは、アクセス・トークンを必要とするリソースです。 MobileFirst セキュリティー・フレームワークを使用して、MobileFirst Server のインスタンス上にホストされたリソースと外部サーバー上のリソースの両方を保護できます。 リソースを保護するには、リソースのアクセス・トークンを取得するために必要な許可を定義するスコープをリソースに割り当てます。

リソースはいろいろな方法で保護できます。

必須アプリケーション・スコープ

アプリケーション・レベルでは、アプリケーションによって使用されるすべてのリソースに適用されるスコープを定義できます。 セキュリティー・フレームワークは、要求されたリソース・スコープのセキュリティー検査に加えて、これらの検査 (存在する場合) を実行します。

注:

• 必須アプリケーション・スコープは、無保護リソースにアクセスする場合は適用されません。
• リソース・スコープに対して許可されたアクセス・トークンに、必須アプリケーション・スコープは含まれません。

MobileFirst Operations Console で、ナビゲーション・サイドバーの「アプリケーション」セクションからアプリケーションを選択した後、「セキュリティー」タブを選択します。 「必須アプリケーション・スコープ」の下で、「スコープに追加」を選択します。

必要な構成を指定してアプリケーションの構成 JSON ファイルを手動で編集し、変更を MobileFirst Server にプッシュして戻すこともできます。

1. コマンド・ライン・ウィンドウから、プロジェクトのルート・フォルダーにナビゲートし、mfpdev app pull を実行します。
2. project-folder\mobilefirst フォルダーにある構成ファイルを開きます。

3. mandatoryScope プロパティーを定義し、選択したスコープ・エレメントのスペース区切りリストが入ったスコープ・ストリングをプロパティー値に設定することで、ファイルを編集します。 例えば、次のとおりです。

   "mandatoryScope": "appAuthenticity PincodeValidation"
   

4. コマンド mfpdev app push を実行することで、更新済み構成 JSON ファイルをデプロイします。

更新済み構成をリモート・サーバーにプッシュすることもできます。 MobileFirst CLI を使用した MobileFirst 成果物の管理チュートリアルを確認してください。

アダプター・リソースの保護

以下の Java セクションと JavaScript セクションで概説されているように、アダプターでは、Java メソッドまたは JavaScript リソース・プロシージャーに対して、あるいは Java リソース・クラス全体に対して保護スコープを指定できます。 スコープは、スペースで区切った 1 つ以上のスコープ・エレメントからなるストリング (「scopeElement1 scopeElement2 …」) として定義することも、ヌルとして定義してデフォルトのスコープ (スコープを参照) を適用することもできます。

デフォルトの MobileFirst スコープは RegisteredClient です。これは、リソースにアクセスするためにアクセス・トークンを必要とし、そのリソース要求が MobileFirst Server に登録されたアプリケーションから出されたものであることを検証します。 この保護は、リソース保護を無効にした場合を除き常に適用されます。 そのため、リソースのスコープを設定しない場合でも、リソースは引き続き保護されます。

注: RegisteredClient は、予約済みの MobileFirst キーワードです。 カスタム・スコープ・エレメントやセキュリティー検査をこの名前で定義することはしないでください。

Java アダプター・リソースの保護

保護スコープを JAX-RS メソッドまたはクラスに割り当てるには、@OAuthSecurity アノテーションをこのメソッドまたはクラスの宣言に追加し、このアノテーションの scope エレメントを希望のスコープに設定します。 以下の YOUR_SCOPE は、1 つ以上のスコープ・エレメントからなるストリング (「scopeElement1 scopeElement2…」) で置き換えてください。

@OAuthSecurity(scope = "YOUR_SCOPE")

クラス・スコープは、独自の @OAuthSecurity アノテーションが設定されているメソッドを除き、クラス内のすべてのメソッドに適用されます。

注: @OAuthSecurity アノテーションの enabled エレメントが false に設定されている場合、scope エレメントは無視されます。 Java リソース保護の無効化を参照してください。

例

以下のコードは、スコープ・エレメントとして UserAuthentication および Pincode が含まれているスコープを使用して helloUser メソッドを保護します。

@GET
@Path("/{username}")
@OAuthSecurity(scope = "UserAuthentication Pincode")
public String helloUser(@PathParam("username") String name){
    ...
}

以下のコードは、事前定義の LtpaBasedSSO セキュリティー検査を使用して WebSphereResources クラスを保護します。

@Path("/users")
@OAuthSecurity(scope = "LtpaBasedSSO")
public class WebSphereResources {
    ...
}

JavaScript アダプター・リソースの保護

保護スコープを JavaScript プロシージャーに割り当てるには、adapter.xml ファイルで、<procedure> エレメントの scope 属性を希望のスコープに設定します。 以下の PROCEDURE_NANE はプロシージャーの名前で、YOUR SCOPE は 1 つ以上のスコープ・エレメントからなるストリング (「scopeElement1 scopeElement2 …」) で置き換えてください。

<procedure name="PROCEDURE_NANE" scope="YOUR_SCOPE">

注: <procedure> エレメントの secured 属性が false に設定されている場合、scope 属性は無視されます。 JavaScript リソース保護の無効化を参照してください。

例

以下のコードは、スコープ・エレメントとして UserAuthentication および Pincode が含まれているスコープを使用して userName プロシージャーを保護します。

<procedure name="userName" scope="UserAuthentication Pincode">

リソース保護の無効化

特定の Java アダプター・リソースまたは JavaScript アダプター・リソースに対して、あるいは Java クラス全体に対して デフォルトの MobileFirst リソース保護を無効にすることができます。それは、以下の Java セクションと JavaScript セクションで概説されています。 リソース保護が無効になっている場合、MobileFirst セキュリティー・フレームワークでは、リソースにアクセスするためにトークンは必要ありません。 保護されていないリソース (Unprotected resources) を参照してください。

Java リソース保護の無効化

Java リソース・メソッドまたはクラスの OAuth 保護を完全に無効にするには、以下のように、@OAuthSecurity アノテーションをこのリソースまたはクラスの宣言に追加し、enabled エレメントの値を false に設定します。

@OAuthSecurity(enabled = false)

アノテーションの enabled エレメントのデフォルト値は true です。 enabled エレメントが false に設定されている場合、scope エレメントは無視され、リソースまたはリソース・クラスは保護されません。

注: 無保護クラスのメソッドにスコープを割り当てた場合、リソースのアノテーションの enabled エレメントを false に設定しない限り、クラスのアノテーションに関係なくそのメソッドは保護されます。

例

以下のコードは、helloUser メソッドのリソース保護を無効にします。

    @GET
    @Path("/{username}")
    @OAuthSecurity(enabled = "false")
    public String helloUser(@PathParam("username") String name){
        ...
    }

以下のコードは、MyUnprotectedResources クラスのリソース保護を無効にします。

    @Path("/users")
    @OAuthSecurity(enabled = "false")
    public class MyUnprotectedResources {
        ...
    }

JavaScript リソース保護の無効化

JavaScript アダプター・リソース (プロシージャー) の OAuth 保護を完全に無効にするには、adapter.xml ファイルで、<procedure> エレメントの secured 属性を false に設定します。

<procedure name="procedureName" secured="false">

secured 属性が false に設定されている場合、scope 属性は無視され、リソースは保護されません。

例

以下のコードは、userName プロシージャーのリソース保護を無効にします。

<procedure name="userName" secured="false">

無保護リソース

無保護リソースは、アクセス・トークンを必要としないリソースです。 MobileFirst セキュリティー・フレームワークは、無保護リソースへのアクセスを管理せず、また該当するリソースにアクセスするクライアントの ID を検証および検査しません。 そのため、無保護リソースでは、ダイレクト・アップデート、デバイス・アクセスのブロック、リモート側でのアプリケーションの無効化などの機能はサポートされません。

外部リソースの保護

外部リソースを保護するには、アクセス・トークン検証モジュールとともにリソース・フィルターを外部リソース・サーバーに追加します。 トークン検証モジュールは、セキュリティー・フレームワークの許可サーバーのイントロスペクション・エンドポイントを使用して、リソースに対するアクセス権限を OAuth クライアントに付与する前に、MobileFirst アクセス・トークンを検証します。 MobileFirst ランタイム用の MobileFirst REST API を使用して、任意の外部サーバー用のアクセス・トークン検証モジュールを独自に作成できます。 あるいは、外部リソースの保護チュートリアルで概要を示しているように、外部 Java リソースを保護するために提供されているいずれかの MobileFirst 拡張機能を使用します。

許可フロー

許可フローには、以下の 2 つのフェーズが含まれます。

1. クライアントがアクセス・トークンを取得する。
2. クライアントがトークンを使用して、保護リソースにアクセスする。

アクセス・トークンの取得

このフェーズで、クライアントはアクセス・トークンを受け取るためにセキュリティー検査を受けます。

アクセス・トークンを要求する前に、クライアントは、自身を MobileFirst Server に登録します。 登録の一部として、クライアントは、その ID 認証に使用される公開鍵を提供します。 このフェーズは、モバイル・アプリケーション・インスタンスの存続期間で 1 回実行されます。 アプリケーション認証性セキュリティー検査が有効である場合、アプリケーションの登録時にアプリケーションの認証性が検証されます。

1. クライアント・アプリケーションが、指定したスコープのアクセス・トークン取得要求を送信します。

   クライアントは、特定のスコープを持つアクセス・トークンを要求します。 要求するスコープは、クライアントがアクセスを希望する保護リソースのスコープと同じセキュリティー検査にマップされる必要があり、オプションで追加のセキュリティー検査にマップされる場合もあります。 クライアントに保護リソースのスコープに関する予備知識がない場合、クライアントはまず空のスコープを持つアクセス・トークンを要求し、取得したトークンでリソースにアクセスすることができます。 クライアントは、エラー 403 (禁止) の応答を受け取り、要求したリソースに必要なスコープを受け取ります。

2. クライアント・アプリケーションが、要求したスコープに従ってセキュリティー検査を受けます。

   MobileFirst Server は、クライアントの要求のスコープがマップされた先のセキュリティー検査を実行します。 許可サーバーは、そのような検査の結果に基づいて、クライアントの要求を許可または拒否します。 必須アプリケーション・スコープが定義されている場合、要求されているスコープの検査に加えて、そのスコープのセキュリティー検査が実行されます。

3. チャレンジ・プロセスが正常に完了した後、クライアント・アプリケーションが、要求を許可サーバーに転送します。

   正常に許可された後、クライアントは、許可サーバーのトークン・エンドポイントにリダイレクトされ、クライアント登録の一部として提供された公開鍵を使用して認証されます。 認証が成功すると、許可サーバーは、クライアントの ID、要求されたスコープ、およびトークンの有効期限時刻をカプセル化したデジタル署名済みアクセス・トークンをクライアントに発行します。

4. クライアント・アプリケーションがアクセス・トークンを受け取ります。

トークンを使用した保護リソースへのアクセス

以下のダイアグラムに示すような、MobileFirst Server 上で実行されるリソースと、MobileFirst Server を使用した外部リソースの認証チュートリアルで説明しているような、外部リソース・サーバー上で実行されるリソースの両方にセキュリティーを適用できます。

クライアントは、アクセス・トークンを取得した後に、取得したトークンを後続の要求にアタッチして保護リソースにアクセスします。 リソース・サーバーは許可サーバーのイントロスペクション・エンドポイントを試用して、トークンを検証します。 この検証では、トークンのデジタル署名を使用したクライアントの ID の検査、スコープが許可されている要求スコープに一致していることの検査、およびトークンの有効期限が切れていないことの確認が行われます。 トークンが検証されると、クライアントに対してリソースへのアクセスが許可されます。

1. クライアント・アプリケーションが、受け取ったトークンを付けて要求を送信します。
2. 検証モジュールがトークンを検証します。
3. MobileFirst Server が、アダプター呼び出しに進みます。

次に使用するチュートリアル

サイドバー・ナビゲーションにあるチュートリアルを順に追いながら、MobileFirst Foundation での認証について、引き続きお読みください。

• セキュリティー検査の作成
  • セキュリティー検査コントラクト
• CredentialsValidationSecurityCheck
  • Ionic アプリケーションでのチャレンジ・ハンドラーの実装
  • CredentialsValidationSecurityCheck クラスの実装
  • JavaScript (Cordova、Web) アプリケーションでのチャレンジ・ハンドラーの実装
  • iOS アプリケーションでのチャレンジ・ハンドラーの実装
  • Android アプリケーションでのチャレンジ・ハンドラーの実装
  • Windows 8.1 Universal アプリケーションおよび Windows 10 UWP アプリケーションでのチャレンジ・ハンドラーの実装
• UserAuthenticationSecurityCheck
  • UserAuthenticationSecurityCheck クラスの実装
  • JavaScript (Cordova、Web) アプリケーションでのチャレンジ・ハンドラーの実装
  • iOS アプリケーションでのチャレンジ・ハンドラーの実装
  • Android アプリケーションでのチャレンジ・ハンドラーの実装
  • Windows 8.1 Universal アプリケーションおよび Windows 10 UWP アプリケーションでのチャレンジ・ハンドラーの実装
• ExternalizableSecurityCheck の実装
• ステップアップ認証
• 登録
• LTPA ベースのシングル・サインオン (SSO) セキュリティー検査
• アプリケーション認証性
• 機密クライアント
• デバイス・シングル・サインオン (SSO) の構成
• MobileFirst Server を使用した外部リソースの認証
  • Java トークン・バリデーター
  • トラスト・アソシエーション・インターセプター
  • Node.js バリデーター
  • Windows .NET メッセージ・インスペクター
• 証明書ピン留め
• MobileFirst Server 鍵ストアの構成