Windows 8.1 Universal アプリケーションおよび Windows 10 UWP アプリケーションでのチャレンジ・ハンドラーの実装

improve this page | report issue

概説

前提条件: CredentialsValidationSecurityCheck チャレンジ・ハンドラー実装のチュートリアルをお読みください。

このチャレンジ・ハンドラーのチュートリアルでは、プリエンプティブ LoginLogout、および ObtainAccessToken など、いくつかの追加機能 (API) を例示します。

ログイン

この例では、UserLoginSecurityCheckusernamepassword という key:value を必要とします。 オプションで、ブール型の rememberMe キーも受け入れます。これは、このユーザーを長期間記憶しておくようにセキュリティー検査に指示するためのものです。 サンプル・アプリケーションの場合、この情報はログイン・フォームのチェック・ボックスからブール値を使用して収集されます。

credentials 引数は、usernamepassword、および rememberMe を含んでいる JSONObject です。

public override void SubmitChallengeAnswer(object answer)
{
    challengeAnswer = (JObject)answer;
}

チャレンジを何も受け取っていない場合でもユーザーのログインを可能にする必要がある場合があります。 例えば、アプリケーションの最初の画面としてログイン画面を表示したり、ログアウト後やログイン失敗後にログイン画面を表示したりできます。 このようなシナリオをプリエンプティブ・ログインと呼びます。

応答すべきチャレンジが存在しない場合、challengeAnswer API を呼び出すことはできません。 そのようなシナリオ用に、Mobile Foundation SDK には Login API が組み込まれています。

WorklightResponse response = await Worklight.WorklightClient.CreateInstance().AuthorizationManager.Login(String securityCheckName, JObject credentials);

資格情報に問題がある場合、セキュリティー検査はチャレンジを返信します。

アプリケーションのニーズに応じて、どのような場合に challengeAnswer でなく Login を使用するかを判断することは開発者の責任です。 これを実現する方法の 1 つとして、ブール値のフラグ (例えば、isChallenged) を定義し、HandleChallenge に到達したときにフラグを true に設定し、それ以外のケース (失敗、成功、初期設定時など) では false に設定する方法があります。

ユーザーが「ログイン」ボタンをクリックした時点で、使用すべき API が動的に選択されます。

public async void login(JSONObject credentials)
{
    if(isChallenged)
    {
        challengeAnswer= credentials;
    }
    else
    {
        WorklightResponse response = await Worklight.WorklightClient.CreateInstance().AuthorizationManager.Login(securityCheckName, credentials);
    }
}

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

このセキュリティー検査は RememberMe 機能 (rememberMe ブール・キー) をサポートしているため、アプリケーションの開始時に、クライアントがログインしているかどうかをチェックすると役立ちます。

Mobile Foundation SDK は、サーバーに有効なトークンを尋ねるための ObtainAccessToken API を提供しています。

WorklightAccessToken accessToken = await Worklight.WorklightClient.CreateInstance().AuthorizationManager.ObtainAccessToken(String scope);

if(accessToken.IsValidToken &&  accessToken.Value != null &&  accessToken.Value != "")
{
  Debug.WriteLine("Auto login success");
}
else
{
  Debug.WriteLine("Auto login failed");
}

クライアントが既にログインしているか、記憶されている 状態である場合、API は成功をトリガーします。 クライアントがログインしていない場合、セキュリティー検査はチャレンジを返信します。

ObtainAccessToken API は、スコープを受け入れます。 スコープは、セキュリティー検査の名前にできます。

スコープについて詳しくは、許可の概念チュートリアルを参照してください。

認証済みユーザーの取得

チャレンジ・ハンドラー HandleSuccess メソッドは、JObject identity をパラメーターとして受け取ります。 セキュリティー検査が AuthenticatedUser を設定した場合、このオブジェクトにはユーザーのプロパティーが含まれます。 現行ユーザーを保存するには、HandleSuccess を使用できます。

public override void HandleSuccess(JObject identity)
{
    isChallenged = false;
    try
    {
        //Save the current user
        var localSettings = Windows.Storage.ApplicationData.Current.LocalSettings;
        localSettings.Values["useridentity"] = identity.GetValue("user");

    } catch (Exception e) {
        Debug.WriteLine(e.StackTrace);
    }
}

ここで、identity には user というキーがあり、これ自身も AuthenticatedUser を表す JObject を含んでいます。

{
  "user": {
    "id": "john",
    "displayName": "john",
    "authenticatedAt": 1455803338008,
    "authenticatedBy": "UserLogin"
  }
}

ログアウト

Mobile Foundation SDK は、特定のセキュリティー検査からログアウトするための Logout API も提供しています。

WorklightResponse response = await Worklight.WorklightClient.CreateInstance().AuthorizationManager.Logout(securityCheckName);

サンプル・アプリケーション

このチュートリアルには、以下の 2 つのサンプルが関連付けられています。

  • PreemptiveLoginWin: プリエンプティブ Login API を使用して、常にログイン画面から開始するアプリケーション。
  • RememberMeWin: 「ユーザーを記憶する (Remember Me)」チェック・ボックスがあるアプリケーション。 ユーザーは、次にアプリケーションを開くとき、ログイン画面をバイパスできます。

両方のサンプルが、SecurityCheckAdapters アダプター Maven プロジェクトに含まれる同じ UserLoginSecurityCheck を使用します。

ここをクリック して SecurityCheckAdapters Maven プロジェクトをダウンロードします。
ここをクリック して Remember Me Win8 プロジェクトをダウンロードします。
ここをクリック して Remember Me Win10 プロジェクトをダウンロードします。
ここをクリック して PreemptiveLogin Win8 プロジェクトをダウンロードします。
ここをクリック して PreemptiveLoginWin10 プロジェクトをダウンロードします。

サンプルの使用法

サンプルの README.md ファイルの指示に従ってください。 アプリケーションのユーザー名/パスワードは一致しなければなりません (すなわち、”john”/”john”)。

サンプル・アプリケーション

Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.
Last modified on July 17, 2018