制限付きアクセスを活用しデバイスの状態をアプリケーションへ伝達
Okta Workforce Identityで認証の際には、アクセス元の様々な情報をもとにアクセス制御を行うことができます。多要素認証（MFA）の強制、追加のMFAを要求、あるいは認証拒否といった制御を可能とします。Okta Workforce Identityでは、判断材料とする情報をコンテキストと呼びます。Okta Workforce Identityが直接収集するコンテキストや、端末にインストールしたOkta Verifyが収集する端末の情報、サードパーティソリューションから収集することも可能です。こちらについては、以前の高度なポスチャチェックをご紹介したブログの前半で詳細をご紹介しております。あわせて御覧ください。
そのなかでも、多くのお客様に活用頂いているDevice Trustの機能に着目します。端末にストアされたデバイス証明書をOkta Verifyで取得し、それに応じてアクセス制御を行います。例えば、アプリケーションの利用には社給端末や、私用の端末であるがMDM管理下の端末に限定して利用を許可するようなケースで活用します。Device Trust機能の利用にはAdaptive MFAライセンスが必要です。
Device Trustを利用する際には、対象のアプリケーションに対して「証明書を持つ端末からのアクセスは許可」、「証明書を持たない端末からはアクセス拒否」といった、アプリケーションの利用可否を制限するユースケースで多く活用されています。言い換えるならば、これまではアプリケーション単位での利用可否しか制御することが出来ませんでした。
今回ご紹介する機能、Device Trustを拡張する機能となる制限付きアクセスでは、Device Trustの状態をアプリケーションへ伝達することが可能になります。これにより、アプリケーション側でその状態に応じて、アプリケーションの権限などを制御するといったきめ細かな制御が可能となります。
目次
制限付きアクセスとは？
制限付きアクセスでは、Okta Workforce Identityで認証に成功し発行する際のSAMLアサーションの属性にデバイスの状態を記載し、アプリケーションへ伝達します。Okta Workforce Identityのアプリケーションで指定するSAML属性にドキュメント記載の通り device.profile.managed と指定することで、この属性は動的な値となり、証明書のある端末（管理対象／Managed）からの場合はtrue、証明書のない端末（非管理対象／Unmanaged）からはfalseが記載されます。この属性をキーとしてアプリケーション側で判定することにより、指定された端末（証明書がある端末）からのアクセスではアプリケーションの特権など高度な権限が利用可能となり、それ以外の端末からのアクセスの場合（証明書がない端末）は限定的な権限でのみアプリケーションを利用するといった、一段上のきめ細かな制御を可能とします。本機能については、アプリケーション側がSAML属性による制御に対応していることが必要になります。従ってOkta Workforce Identityに加えて対象とするアプリケーション双方の対応と設定の調整が必要です。
Okta Workforce Identityで属性にデバイス状態を記載するためには、PCからアクセスする際にデバイス状態を判定する認証方式でログインを実施する必要があります。つまり、Okta FastPassによるログイン試行を行った際にOkta Verifyは証明書の確認を行うこととなります。認証方式にパスワードやワンタイムパスワード、FIDO2などのAuthenticatorを用いた場合にはデバイス状態の判定は行われませんので、Okta FastPassが実行されるよう適切な認証ポリシーを構成し、アプリケーションに適用する必要があります。Okta FastPassについてはこちらの説明もご参照ください。
以降では、アプリケーション側でSAML属性による制御が可能な例として、Amazon Web ServicesのAWS IAM Identity Centerとの統合を例に設定例をご紹介したいと思います。
ユースケース
AWS IAM Identiy Centerでは、属性をもとにアクセスコントロールを行うことが可能です。IAM Identity Centerの認証をOkta Workforce Identityで実施する際に記載されるSAML属性をPrincipalTagとし、そのPrincipalTagをIAM属性として渡すことで、各種AWSリソースに対するアクセスコントロールを実施することが可能です。今回シンプルなユースケースを実際に設定してみます。
Okta Workforce IdentityとAWS IAM Identity Centerの統合で
1．Okta Verifyがない端末、PC-Aからの認証は拒否
2．Okta Verifyがあり証明書がない端末、PC-Bからは対応するAWSアカウントのAdministratorAccess許可セットが利用不可
3．Okta Verifyがあり証明書がある端末、PC-Cからのみ対応するAWSアカウントに対してAdministratorAccess許可セットで利用可能
このユースケースの場合、Okta Workforce Identityから見た場合はフェデレーション連携先として、AWS IAM Identiy Centerのインスタンス全体となるため、通常のOkta Workforce Identityで設定するDevice Trustのみの制御では実現することが出来ません。AWS IAM Identiy Center全体に対しての認証可否の制御のみとなります。ここで、今回の制限付きアクセスを利用してAWS IAM Identiy Centerと紐づくAWSアカウント、許可セット毎の動作をコントロールします。
つまり、PC-BとPC-C両方ともOkta FastPass認証は成功しますが、その後AdministratorAccess許可セットが利用可能な端末は、PC-Cのみです。
前提条件
・Okta Workforce IdentityとAWS IAM Identity CenterのSAML設定、プロビジョニング設定は正しく設定済みの状態からスタートします。
・Okta Workforce IdentityのユーザーとグループはAWS IAM Identity Centerへプロビジョニング済になります。
・Device Trustは既に設定済みでPC-Cには正しい証明書を保持し、Okta Workforce Identityでは管理対象／Managedの状態です。
・Okta Workforce Identityの制限付きアクセス利用にはAdaptive MFAライセンスが必要です。
・画面キャプチャ、スクリーンショットは2025年8月現在のものとなり、OktaとAWS双方とも将来変更の可能性があります。
Okta Workforce Identityの設定
それではここからOkta Workforce Identityの設定を開始します。前提条件の通り、既にOkta Workforce IdentityとAWS IAM Idenity Centerの設定は完了していることから、SAML属性を追加設定します。Okta Admin Consoleから [アプリケーション] -> [アプリケーション] -> [AWS IAM Idenity Center] を選択し [サインオン] または [認証] タブをクリックします。
設定済みのSAML2.0を [編集] すると以下の通り属性を設定する矢印をクリックすることで入力画面が表示されます。
属性ステートメントの設定欄では以下の値の通り設定します。
- 名前：https://aws.amazon.com/SAML/Attributes/AccessControl:DeviceStateManaged
- 名前のフォーマット： URI参照
- 値： device.profile.managed
スクロールダウンし [保存] を押してOkta Workforce Identity側設定はこれで完了になります。
一旦この時点の確認として、一度テストユーザーでそれぞれPC-BとPC-C端末からAWS IAM Identity CenterにOkta FastPassでログインしてみます。その際のSAML属性は以下の通りとなりました。正しく動作していることがわかります。Google Chrome拡張機能のSAML Tracerなどでキャプチャしてみると簡単に確認できます。
AWS IAM Idenity Centerの設定
AWS IAM Identity Centerの設定に移ります。まずはIAM Idenityt Centerのダッシュボードから [設定に移動] をクリックします。
すると [アクセスコントロールの属性] の有効化を促すウインドウが表示されていますので、そのまま [有効にする] をクリックします。
有効化されると [アクセスコントロールの属性] タブが表示されますのでこちらで設定完了です。
SAMLアサーションによって渡される属性を使用する場合については、こちらのアクセスコントロールの属性設定でのマッピング設定は必要としません。AWSのドキュメントにおいても要求がないことから、属性の追加はせずこのままとします。
最後に許可セットを作成します。
今回はAdministratorAccessをコントロールするため、事前定義された許可セット、AWSマネージドポリシーから AdministratorAccess を選択します。許可セット名は Limited_AdministratorAccess と名付けて一旦作成完了します。
次に作成した Limited_AdministratorAccess を選択し [許可] タブをスクロールダウンすると [インラインポリシー] の設定欄がありますので、[編集]をクリックし追加します。
インラインポリシーには以下のJSONで記述します。aws:PrincipalTag/DeviceStateManaged": "true"であればAllow、aws:PrincipalTag/DeviceState": "true"でなければDenyするというシンプルな記述です。これにより仮にOkta Workforce IdentityからのDeviceStateManaged属性が存在しない場合（万一Okta FastPassを認証に使用しない場合）AdminstratorAccessは拒否するというセーフガードになります。こちらのインラインポリシーはサンプルをZennの記事に掲載していますので、コピーし自身の環境に応じて編集して活用ください。
Okta Workforce IdentityからAWS IAM Identity Centerにプッシュしたグループに対してAWSアカウント、また今作成した許可セットを紐づけ設定完了になります。
動作確認
実際の動作の様子は本ブログ記事内の画像では分かりにくいかと思いますので、こちらもZennの記事にPC-A, PC-B, PC-Cそれぞれのユーザー体験を撮影した動画を紹介しています。あわせてこちらも御覧ください。
PC-B、Unmanaged端末からOkta FastPassでアクセスを試みます。Okta Workforce Identityの認証完了後、AWS IAM Identity Centerのログインは問題なく完了します。ここから作成した許可セットを用いてアクセスを継続してみます。
マネジメントコンソール自体はアクセス可能ですが、試しにEC2インスタンスの操作を試みたところ一切の操作ができない動作が確認できました。
次に、PC-C、証明書のあるManaged端末からのアクセスを試みます。認証に成功するところまでは同様ですが、マネジメントコンソールにおいてもフルアクセスが可能でありEC2インスタンスの起動が可能であることが確認できました。
最後にCroudTrailのログからPrincipalTagの状態を見てみます。イベント履歴からイベント名で AssumeRoleWithSAML のレコードを確認するのが簡単です。これはAWS IAM Identity CenterのアクセスポータルからAWSアカウントにフェデレーションされる際の認証情報です。
・Unmanaged端末からのイベントレコード
・Managed端末からのイベントレコード
以上より、Okta Workforce Identityで判定したデバイス状態がSAML属性としてAWS IAM Identity Centerに渡り、AWSアカウントに対してもPrincipalTagとして正しく引き継がれていることが確認できました。
まとめ
今回はOkta Workforce Identityの制限付きアクセス機能について解説しました。これは、アプリケーションへの利用可否を制御する従来のDevice Trust機能を拡張し、デバイスの状態を動的にアプリケーション自体に伝達することを可能にします。AWS IAM Identity Centerを例にご紹介しましたが、他にもこんなアプリケーションと連携することで、制御することができたなどがあればぜひ共有して頂けると幸いです。
この他にもOkta Workforce Identityからアプリケーションに対して動的にSAML属性やクレームとして伝達可能なものに、Authentication Methods References（AMR）といった方法もありますが、また別の機会で紹介したいと思います。
制限付きアクセス機能はOkta Workforce Identityのフリートライアルにおいてもデフォルトで有効化されています。30日間利用可能なフリートライアル環境はこちらからお申し込み下さい。
Follow 南野 要
