テクニカルトピックス

【2021.6.8】Mobile AppのProvisioningが必ず失敗する条件

　Mobile AppをProvisioningするためには、QRコードによる方法、URLをクリックする方法、ユーザが各項目をMobile App画面で直接入力する方法があります。いずれの場合もSwivelサーバが自動生成したProvisioning Codeを使用します。

※Mobile AppのProvisioningのための設定については下記ページをご参照下さい。
http://www.securitystrings.com/resource/sw_tech/20201208_2.html

Provisioning Codeは対象ユーザに1回限り有効なワンタイムコードです。Provisioning Codeの生成アルゴリズムの詳細は非公開ですが、ユーザ情報、ユーザPIN、ユーザ鍵情報を元に生成されます。



　そのため、Provisioning Codeを生成してユーザに送信した後、Provisioningを行う前にユーザがPINを変更してしまうと、生成済みのProvisioning Codeが無効になり、Provisioningに失敗します。
特にイニシャルPIN（Initial PIN）を使用して、初期のユーザ登録を行った場合、ユーザは最初にPINを変更しようとしますが、システムはユーザ生成と同時にProvisioning Codeを生成しますので、注意が必要です。
例えば、下記の運用手順の場合、Mobile AppのProvisioningが必ず失敗してしまいます。

  1. ユーザを新規作成（ユーザにメールを送信）
  2. ユーザがUserportalから初期PINを変更
  3. メールのURLやQRコードを使用してProvisioningを実施

この運用の場合、下記のように動作しています。

  1. ユーザを新規作成
    →ユーザのその時点でのPINを元にユーザ暗号Key（Key-A）が生成されます。
    その時点で送信されるProvisioningコードはKey-Aをベースにしています。
  2. Userportalより初期PINを変更
    →ユーザのPINが変更されたのでユーザ暗号KeyがKey-Bに変わります。
  3. メールのURLよりProvisioningを実施
    →この時点ではKey-Bをベースにしているべきにもかかわらず、ProvisioningコードはKey-Aをベースにしているのでエラーとなります。
    （Provisioningコードを再送すると、新しいProvisioningコードはKey-Bをベースにしているので成功します。）

　したがって、Provisioningエラーを回避するためには下記の例で運用を行う必要があります。いずれの場合も、Provisioning Code生成した後、ユーザがPINを変更する前にMobile AppのProvisioningを行います。

＜運用例１＞

  1. ユーザを新規作成
  2. ユーザはすぐにMobile AppのProvisioningを実施
  3. ユーザは、Mobile Appの認証をせずに、UserportalでPINの変更を実施
  4. Mobile Appを利用開始
＜運用例２；ユーザ生成時にはProvisioning用のメールを送信しない＞
  1. ユーザを新規作成
  2. ユーザがUserportalでPIN変更を実施
  3. ユーザがUserportalでMobile AppのProvisioning送信を指示
  4. ユーザがProvisioningを実施
という手順もあり得ます。（こちらの方がスマートかもしれません）

以上となります。

新規にMobile Appを使用し、かつ初期PINを使用する場合に陥りやすい例ですので、ご注意下さい。