多要素認証(MFA)をトリガする

多要素認証のサポートは、以下の3つのタイプのトリガをインストールすることにより提供されます。

• auth-pre-2fa: 認証方法のリストをユーザに提供します
• auth-init-2fa: 選択した認証方法のフローを開始します
• auth-check-2fa: パスワードが有効かどうかをチェックします

タイプごとに1つのトリガのみを定義可能で、3つのトリガがすべて存在する必要があります。

これらのトリガはサーバにJSON結果を返します。インストールしてサーバを再起動すると、セキュリティレベルが暗黙的に3に設定されますが、明示的に高いレベルに設定できます。

ユーザがMFAを実行するように設定するには、そのユーザのユーザ仕様のAuthMethodフィールドをperforce+2faまたはldap+2faに変更する必要があります。このためには、そのユーザがp4 login2コマンドを実行して、2つ目の認証ステップを行う必要があります。自動ログインが有効になっている場合、このステップは通常のパスワードベースの認証を行うと自動的に実行されます。p4 help login2コマンドラインのヘルプを参照してください。

MFAには3つのフェーズがあり、各フェーズはそのフェーズのトリガの実行に基づいています。

list-methodsフェーズ(auth-pre-2fa)

このフェーズは使用可能なMFA方法のリストをユーザに示します。例えば、ユーザはSMS認証アプリケーションやモバイル認証アプリケーションを使用するように設定されている場合があります。対話モードでは、ユーザの認証方法が1つのみの場合、その認証方法が自動的に選択されます。これらの方法はauth-pre-2faトリガによって返されます。また、このトリガはユーザに追加の認証が必要のないこと、またはアクセスが許可されていないことを示します。このトリガは成功時に0を返し、サーバにはSTDOUT経由でJSON文字列を返します。

JSON応答は以下のような形式になります。

{
    "status" : 0,
    "methodlist" : [
        [ "method1" , "method description1" ],
        [ "method2" , "method description2" ]
    ],
    "message" : "Error message"
}

statusフィールドは必須であり、成功時には0を表示し、methodlistには認証のディレクトリを表示します。キーは認証方法の名前で、値は認証方法の説明になります。

statusが2に設定されている場合、この時点でこのホスト上のこのユーザにMFAは必要ありません。この他のstatus値は認証が拒否されたことを意味します。このような場合、methodlistは必要ないため、代わりにユーザに対してメッセージが表示されます。

以下に例を示します。

{
    "status" : 2,
    "message" : "Second factor authentication not required"
}

init-authフェーズ(auth-init-2fa)

このフェーズは選択した方法の2つ目の認証フローを開始します。auth-init-2faトリガを呼び出し、status(成功時は0)とスキームを返します。エラーの場合、statusはゼロ以外を表示し、スキームは表示されません。どちらの場合も、ユーザに対してメッセージが表示される場合があります。

ユーザに対してオプションのチャレンジを表示するように設定できます。initとcheckの間にstateが必要な認証フローの場合は、トークンを設定できます。このトークンはサーバに保存されますが、ユーザには表示されません。このトークンは次回のトリガ時にトリガ変数経由で使用できます。

以下にJSON応答の例を示します。

{
    "status" : 0,
    "scheme" : "challenge",
    "message" : "Please enter your response",
    "challenge" : "ABBACD",
    "token" : "REQID:20003339189"
}

以下はスキームに使用される4つの値です。

• otp-generated - ユーザのデバイスで生成されたワンタイムパスワード
• otp-requested - ユーザに送信されたワンタイムパスワード
• challenge - ユーザに対して表示されたトークンに基づくチャレンジ/応答
• external - アプリケーションベースのプッシュ通知など、サードパーティのプロンプト方法に対する要求

check-authフェーズ(auth-check-2fa)

このフェーズはinit-authによって開始された認証フローの検証ステップを実行します。スキームが「external」である場合、auth-2fa-checkトリガが呼び出され、認証プロバイダのプロンプトのステータスが照会されます。または、ワンタイムパスワードかチャレンジへの応答が求められます。応答はSTDIN経由でauth-2fa-checkトリガに渡され、2要素認証プロバイダによって検証されます。このトリガの応答はJSONのstatusフィールドにオプションのメッセージとして表示されます。status値は成功時には0、失敗時(認証が拒否された場合)にはゼロ以外の値になります。

スキームが「external」である場合、認証プロバイダがユーザの応答を待機し続ける可能性があります。status値2を返すと、認証を承諾も拒否もしないようにサーバに指示できます。以下に例を示します。

{
    "status" : 2,
    "message" : "A token was sent to your phone"
}

変数

3つすべてのトリガ固有の変数は次のとおりです。

%user% - ユーザのユーザ名

%fullname% - ユーザのフルネーム

%email% - ユーザの電子メールアドレス

%host% - ユーザのホストのIPアドレス

%method% - list-methodsの認証方法(「unknown」に設定できます)

%scheme% - init-authで設定した認証スキーム(「unknown」に設定できます)

%token% - init-authフェーズで保存されたトークン(空になっている場合があります)

デフォルトで変更可能なユーザ仕様のフィールドの値が%fullname%フィールドと%email%フィールドに表示される場合、これらの値を使用する際はdm.user.allowselfupdate=0を設定し、ユーザがこれらのフィールドの値を変更しないようにすることをお勧めします。