はじめに

会社のIAMを持とうという話が上がったひとつの要因として、「今日日、社内にいないと仕事できないって意味わからん」っていう文句要望があったことが挙げられます。要するに、何らかの理由で社外にいる人にも会社のアプリを使わせたいという話です。一部、これらの要望をVPN製品で代替していたりもしますが、デバイスの多様化にはついてこれないですし、何より腰を据えないと使えないっていうのは、なかなか利用されづらい仕組みになると思っています。

ゆえに、社外にいるという状態の社員をちゃんと認証出来ているのであれば、~~いいかげんな~~寛容なアプリ（≒機密性のある情報をあまり含まないアプリ）は使えればいいのでは？いいでしょ！

今日やること

今日はそんな文句に応える実装の一例としてリスクベース認証という機能を使い、社内のユーザー、社外のユーザー双方の認証をするようなチェーンを実装します。

イメージはこんな感じです。

リスクベースってなに？

ググると、銀行のページがよくでてきますね！たとえば、イオン銀行さんのページを参照しますと、

件名：リスクベース認証とは何ですか。
お客さまがインターネットバンキングにログインした際のご利用環境を分析し普段のご利用環境と異なると判断した場合に、追加でお客さましか知らない情報の入力により、お客さまご本人であることを確認する仕組です。
第三者のなりすましによる不正利用を防ぐために導入しています。

とあります。
ここでの普段のご利用環境と異なるというのはいろいろな情報から判定することができます。例えば、

これまでの送信元IPアドレスの履歴
ブラウザの種別（User Agent）
位置情報

といった感じです。

リスクベース認証の設定

では、設定していきましょう。

OpenAMの管理者アカウント（ユーザー名はamadmin）でサインインし、管理者コンソールにアクセスします。

モジュールの追加

リスクベース認証モジュールも前回のTOTP認証モジュールと同様、OpenAMではデフォルトで使用することができます。

Authentication => Modules => Add Moduleをクリックします。

以下のパラメータを入力してモジュールを追加します。

Name
- Risk-basedAuthentication
Type
- アダプティブリスク

こんな感じです。

モジュールのパラメータを設定します。ここでのパラメータはご利用環境と異なるという判定を何の情報を以って行うのかを設定します。設定可能なパラメーターは以下の通りです。

認証失敗チェック
- ユーザーが過去に認証失敗をしているかをチェックします
IP レンジチェック
- IP アドレスのリストに対するクライアントの IP アドレスチェックを有効にします
IP 履歴チェック
- 過去の IP アドレスのリストに対するクライアント IP アドレスのチェックを有効にします
Cookie 値チェック
- クライアントリクエストの既知の Cookie 値のチェックを有効にします
最終ログインからの経過時間チェック
- ユーザーが最後に認証した時刻から経過時間チェックを有効にします
プロファイルのリスク属性チェック
- ユーザープロファイルの一致する属性と値のチェックを有効にします
デバイス登録 Cookie チェック
- クライアントリクエストのデバイスCookie チェックを有効にします
位置情報国コードチェック
- 位置情報データベースに反するクライアントの IP アドレスチェックを有効にします
リクエストヘッダーチェック
- 既知のヘッダー名と値に対するクライアントリクエストのチェックを有効にします

各チェックを有効にすると、判定がされる設定となります。チェックには、スコアを設定することができ、スコアが閾値を超えるとリスクがある！と判断され、認証に失敗する（＝追加の認証を要求される）という仕組みです。

今回はシンプルに以下のパラメータを設定します。

IPレンジチェック
- ONにする
IPレンジ
- 192.168.33.0/24
スコア
- 1
スコアの閾値
- 1

こんな感じです。

チェーンの設定

認証モジュールを追加したので、チェーンに追加します。今回、提供したいチェーンは、

IDとパスワードの認証（モジュール名：DataStore）は成功する必要がある
リスクベース認証（モジュール名：`Risk-basedAuthentication）は成功（リスクがないと判定）したら、そこで認証成功とし、失敗したら追加の認証とする
追加の認証はTOTPとする

となります。以下のように設定します。

確認

内勤ユーザーでアクセス

まず、送信元のIPアドレスが192.168.33.1のクライアントから、Policy Agentが導入されたWebサーバー（本記事ではhttps://web.example.com）にアクセスします。

OpenAMの認証画面が表示されるので、本記事における検証アカウント（ユーザー名はjohnd）でサインインします。

その後、追加の認証を求められることなく、おなじみのApacheの画面が表示されます。

営業ユーザーでアクセス

続いて、送信元のIPアドレスが192.168.33.0/24外のクライアントからアクセスを行います。先ほどと同様のアカウントでサインインします。

先ほどとは異なり、追加の認証としてTOTP認証が要求されました。

〆

今回のまとめは

OpenAMでリスクベース認証を設定できる
何を以ってリスクがあるのか？というポリシーは柔軟にデザインできる
簡単にやるなら送信元IPアドレスで判定したらよい

という感じですかね～。企業の従業員を認証するってユースケースですと、送信元IPアドレスの判定のほかに、普段使っているブラウザか？とか、外からアクセスを許可されているユーザーか？あたりがよく使われるのかなぁと思いました。

あしたは何しよう～？

ばい！