はじめに

皆さんは認証のテストを行う際、どのようにテストしますか？おそらく、実際の環境で認証を実施し、アクセス可否を検証することが一般的だと思います。

Oktaでは、Access Testing Toolを利用することで、実際の端末やネットワーク環境を用意しなくても、アプリケーションへのアクセス可否を検証することができます。

今回は、そんなAccess Testing Toolを使って検証してみたのでご紹介します。

想定ケース

アクセス先アプリケーション

今回は、Microsoft Office 365アプリへのSSO(シングルサインオン)を想定し、Access Testing Toolを用いてアクセステストを行います。

認証ポリシー設定

今回は、以下のような認証ポリシールールを設定のうえ、検証を行います。

• 社内ネットワークからのアクセスを許可するルール(ルール名：「社内NW許可ルール」)
• 社内ネットワーク以外からのアクセスを拒否するルール(ルール名：「社外NW拒否ルール」)

• 社内ネットワークを定義するIPを設定
  「社内NW(test)」というIP Zoneを定義します。

• 認証ポリシーとして①、②のルールを設定
  上記で定義したIP Zoneをルール内で指定し、「社内NW(test)」のIPからのアクセスは許可 (Allow)し、それ以外のIPからのアクセスは拒否 (Deny)するルールを設定します。

Access Testing Toolを用いたアクセステスト

Okta管理画面のReports > Access Testing Toolにて、各項目にアクセスする際の想定の条件を入力します。

《入力項目》

• アプリケーション名
• デバイスの状態(Oktaに登録されているか)
• ネットワークゾーン(どのネットワークからアクセスするか)
• ユーザ名(アクセスするユーザ)
• デバイスプラットフォーム(アクセスするデバイスのOS)
• リスクスコア
• その他指定項目(Okta独自のカスタム関数であるExpression Languageを利用して入力します。検証時はまだサポートされておりませんでしたが、今後サポート予定です。
  Expression Languageについてのブログも公開しているので、併せてご参照ください。)

社内ネットワークからのアクセステスト

ネットワークゾーンの指定にて、先に設定した「社内NW(test)」というIP Zoneを指定します。これにより、社内ネットワークからのアクセスについてテストできます。

Resultsを見ると、アクセスが許可されていることが分かります。また、ページ下部にて、適用されているポリシールールを確認でき、「社内NW許可ルール」によって許可されていることが分かります。

社外ネットワークからのアクセステスト

次に、「社内NW(test)」に含まれないIPを指定し、アクセステストを行います。

Resultsを見ると、アクセスが拒否されていることが分かり、「社外NW拒否ルール」によって拒否されていることが分かります。

Access Testing Toolでチェックできるのはアクセス可否だけではない！

Access Testing Toolでは、上記アクセス可否だけでなく、登録が許可/拒否されている認証要素や対象ユーザが現在登録している認証要素、必須属性やセルフサービスユーザ登録可否、対象ユーザが現在持っている属性についても確認することができます。

• 認証要素の確認

• 必須属性、セルフサービスユーザ登録可の確認

まとめ

今回はOktaのAccess Testing Toolについてご紹介しましたが、いかがでしたでしょうか。
本機能を利用することで、面倒な検証環境の準備なくテストができるため、検証にかける時間を大幅に削減できます。

Oktaにご興味のある方、その他Oktaに関するお問い合わせなどある方は、是非弊社までご連絡ください。