iOS アプリケーションでのチャレンジ・ハンドラーの実装

improve this page | report issue

概説

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

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

ログイン

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

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

self.submitChallengeAnswer(credentials);

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

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

WLAuthorizationManagerSwift.sharedInstance().login(securityCheck: self.securityCheckName, credentials: credentials) { (error) in
    if(error != nil){
        print("Login Preemptive Failure: " + String(error!));
    }
    else{
        print("Login Preemptive Success");
    }
}

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

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

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

if(!self.isChallenged){
  WLAuthorizationManagerSwift.sharedInstance().login(securityCheck: self.securityCheckName, credentials: credentials) { (error) -> Void in}
}
else{
  self.submitChallengeAnswer(credentials)
}

注: WLAuthorizationManager login() API には、独自の完了ハンドラーがあり、関連するチャレンジ・ハンドラーの handleSuccess メソッドまたは handleFailure メソッド呼び出されます。

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

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

Mobile Foundation SDK は、有効なトークンをサーバーに要求するための obtainAccessToken API を提供します。

WLAuthorizationManagerSwift.sharedInstance().obtainAccessToken(forScope : scope) { (token, error) -> Void in
  if(error != nil){
    print(obtainAccessTokenForScope failed: , error!)
  }
  else{
    print(obtainAccessTokenForScope success " + (token?.value)!);
  }
}

注: WLAuthorizationManagerSwift obtainAccessToken() API には、独自の完了ハンドラーがあり、関連するチャレンジ・ハンドラーの handleSuccess または handleFailure 呼び出されます。

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

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

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

認証済みユーザーの取得

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

override open func handleSuccess(successResponse: [NSObject : AnyObject]!) {
  self.isChallenged = false
  self.defaults.setObject(successResponse![user"]!["displayName"]! as! String, forKey: "displayName")
}

ここで、success には user というキーがあり、これ自身も AuthenticatedUser を表すディクショナリーを含んでいます。

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

ログアウト

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

WLAuthorizationManagerSwift.sharedInstance().logout(securityCheck: self.securityCheck){ (error) -> Void in
    if(error != nil){
        print("Logout Failure: " , error!)
    }
}

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

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

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

両方のサンプルが、SecurityCheckAdapters アダプター Maven プロジェクトに含まれる同じ UserLogin セキュリティー検査を使用します。

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

サンプルの使用法

サンプルの 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 November 27, 2019