Okta · Cloudflare One ドキュメント

Okta は、最新のアプリケーションへのユーザー認証を管理・保護するためのクラウドソフトウェアを提供します。開発者はアプリケーション、ウェブサイトの Web サービス、デバイスに ID 制御を組み込めます。Okta を Cloudflare One と統合し、ユーザー ID とグループメンバーシップに基づくルールを作成できます。Cloudflare One は、OIDC（デフォルト）または SAML プロトコルによる Okta 統合に対応します。

さらに、Cloudflare One のユーザーリスクスコアから得たリスク情報を Okta で使い、SSO レベルのポリシーを作成できます。詳細はリスクスコアを Okta に送信するを参照してください。

前提条件

任意のサブスクリプション層（Free を含む）の Zero Trust Organization
Access Edit 権限を持つ Cloudflare One 管理者ロール

対応機能

SP 開始 SSO: ユーザーが Access アプリケーションにアクセスすると、Access は Okta でのサインインへリダイレクトします。
SCIM プロビジョニング: Okta グループを同期し、ユーザーを自動でデプロビジョニングします。SCIM には現在、別のカスタム OIDC アプリケーションが必要です。

Okta を OIDC プロバイダーとして設定する（Okta App Catalog）

Okta Integration Network（OIN）App Catalog で Okta 統合を設定する手順は次のとおりです。

Okta の管理ダッシュボードにログインします。
Applications > Applications を開きます。
Browse App Catalog を選びます。
Cloudflare を検索し、Cloudflare One アプリを選びます。
Add integration を選びます。
Application label にアプリケーション名を入力します（例: Cloudflare Access）。
Team domain に Cloudflare Zero Trust のチーム名を入力します（サブドメインのプレフィックスのみ。.cloudflareaccess.com は含めません）。
```
<your-team-name>
```
チーム名は、Cloudflare ダッシュボード ↗ の Settings > Team name and domain > Team name で確認できます。
Sign On タブで Client ID と Client secret をコピーし、App ID と Client secret に貼り付けます。
Okta の Account URL（-admin を含まない値）をコピーし、Cloudflare の Okta セットアップ欄に貼り付けます。

Okta を OIDC プロバイダーとして設定する（Custom App Integration）

Okta の管理ダッシュボードにログインし、Applications > Applications を開きます。
Create App Integration を選びます。
Sign-in method で OIDC - OpenID Connect を選びます。
Application type で Web Application を選び、Next を選びます。
アプリケーション名を任意で入力します。Sign-in redirect URIs フィールドに次の URL を入力します。
```
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback
```
チーム名は、Cloudflare ダッシュボード ↗ の Settings > Team name and domain > Team name で確認できます。
希望する Assignment オプションを選び、Save を選びます。
アプリケーション画面で Sign On タブを開きます。
Token claims までスクロールし、Show legacy configuration > Edit を選びます。
Groups claim filter を Matches regex に設定し、値を .* にします。

General タブで Client ID と Client secret をコピーします。

Cloudflare ダッシュボード ↗ で、Zero Trust > Integrations > Identity providers を開きます。
Your identity providers で Add new identity provider を選びます。IdP として Okta を選びます。
次の情報を入力します。
- Name: IdP の名前を付けます。
- App ID: Okta のクライアント ID を入力します。
- Client secret: Okta のクライアントシークレットを入力します。
- Okta account URL: Okta ドメイン ↗ を入力します。例: https://my-company.okta.com。
（任意）Okta API トークンを作成し、Cloudflare ダッシュボード ↗ の Zero Trust > Integrations > Identity providers に入力します（トークンは読み取り専用でも構いません）。Okta テナントのグループが 100 を超える場合に API トークンを使います。ユーザーの OIDC トークンにグループがない、または Okta の 100 グループ上限に達した場合、Cloudflare はこのトークンを認証中に使って、ユーザーの完全なグループメンバーシップを取得します。この設定は Okta 固有で、SCIM の一部ではありません。API トークンは Access ポリシービルダーにグループを追加しません。ポリシービルダーのグループ選択肢は、SCIM でプロビジョニングされたグループから来ます。

（任意）カスタム OIDC クレームを設定するには:
1. Okta でカスタム認可サーバー ↗ を作成し、groups スコープが有効であることを確認します。
2. Cloudflare ダッシュボード ↗ で、Okta から取得した Authorization Server ID を入力します。
3. Optional configurations で、ユーザーの ID に追加したいクレームを入力します。
（任意）Proof of Key Exchange（PKCE） ↗ を有効にします。PKCE はすべてのログイン試行で実行されます。
Save を選びます。

接続が動いていることをテストするには、Test を選びます。

ユーザーとグループを同期する

Okta 統合では、SCIM を使って IdP グループを同期し、ユーザーを自動でデプロビジョニングできます。Access と Okta の間で SCIM プロビジョニングを有効にするには、Okta に 2 つのアプリ統合が必要です。

ID プロバイダーとして Okta を追加したときに作成した OIDC アプリケーション。Okta App Catalog または Custom App Integration で作成できます。
種類が SCIM 2.0 Test App (Header Auth) の 2 つ目の Okta アプリケーション。技術的には SAML アプリですが、ユーザーとグループ情報を SCIM 経由で送信します。

SCIM が Access と Gateway のポリシー評価に与える影響は異なります。

Access は、認証時にアイデンティティプロバイダーが返す SAML アサーションまたは OIDC トークンから、ユーザーの ID とグループ所属を評価します。SCIM は Access のポリシービルダーに読みやすいグループ名を提供しますが、Access はログイン評価に SCIM のグループ所属を使いません。Enable user deprovisioning をオンにすると、SCIM アプリケーションからユーザーを削除した時点で、そのユーザーのアクティブな Access セッションが取り消されます。グループ所属の変更後にセッションを取り消すよう、SCIM を設定することもできます。Access は、ユーザーが再度認証したときに、更新後のアイデンティティプロバイダーデータを評価します。

Gateway は、User Registry の ID に対してアイデンティティベースのポリシーを評価します。ユーザーまたはグループ所属が変わると、SCIM はこの ID を更新します。ユーザーの再認証を待つ必要はありません。Cloudflare One Client のデバイスプロファイルも、同じ同期済み ID を使います。

1. Cloudflare One で SCIM を有効にする

Cloudflare ダッシュボード ↗ で Zero Trust > Integrations > Identity providers を開きます。
Okta 連携を探し、Edit を選択します。
Enable SCIM をオンにします。
（任意）次の設定を行います。

Enable user deprovisioning: Okta の SCIM アプリケーションからユーザーが削除されたときに、ユーザーのアクティブセッションを取り消します。アクティブな Access セッションはすべて無効になり、Cloudflare One Client のセッションポリシーでは再認証が求められます。
Remove user seat on deprovision: Okta の SCIM アプリケーションからユーザーが削除されたときに、Cloudflare One アカウントからユーザーのシートを削除します。
SCIM identity update behavior: Okta でユーザーの ID が更新されたときの、Cloudflare One 側の動作を選びます。
- Automatic identity updates: Okta が SCIM 経由で更新された ID またはグループ所属を送ると、User Registry の ID を自動更新します。この ID は Gateway ポリシーと Cloudflare One Client のデバイスプロファイルに使われます。Access は再認証時に更新後の ID を読み取ります。
- Group membership change reauthentication: Okta でグループ所属が変わったときに、ユーザーのアクティブセッションを取り消します。アクティブな Access セッションはすべて無効になり、Cloudflare One Client のセッションポリシーでは再認証が求められます。Access は再認証時に更新後のグループ所属を読み取ります。
- No action: 次回、Access または Cloudflare One Client に再認証したときにユーザーの ID を更新します。

Regenerate Secret を選択します。SCIM Endpoint と SCIM Secret をコピーします。これらの値を Okta に入力します。
Save を選択します。

SCIM シークレットに有効期限はありません。ただし、いつでも手動で再生成できます。

2. Okta で SCIM を設定する

Okta の管理ダッシュボードで、Applications > Applications を開きます。
Browse App Catalog を選びます。
SCIM Header Auth を検索し、SCIM 2.0 Test App (Header Auth) を選びます。
Add Integration を選びます。
General Settings タブでアプリケーション名を付け、Next を選びます。
Sign-on Options タブで SAML 2.0 が選ばれていることを確認します。
Credential Details で、Application username format を Okta Username または Email に設定します。この値は SCIM の userName 属性に使われます。

Note
userName 属性は、Cloudflare One のユーザーのメールアドレスと一致する必要があります。
Done を選び、統合を作成します。
Provisioning タブで Configure API Integration を選びます。
Enable API integration を選びます。
Base URL フィールドに、Cloudflare One から取得した SCIM Endpoint を入力します。
API Token フィールドに、Cloudflare One から取得した SCIM Secret を入力します。
Test API Credentials を選び、資格情報が正しく入力されていることを確認します。Save を選びます。
Provisioning タブで Edit を選び、次を有効にします。
- Create Users
- Update User Attributes
- Deactivate Users
Assignments タブで、Cloudflare Access と同期したいユーザーを追加します。グループを割り当てると、ユーザーをまとめて追加できます。直接のユーザー割り当て、またはアプリに割り当てたグループからの削除により、アプリケーション割り当てからユーザーが外れると、Okta から Cloudflare へデプロビジョニングイベントが送られます。
Push Groups タブで、Cloudflare Access と同期したい Okta グループを追加します。これらのグループは Access のポリシービルダーに表示されます。Okta でメンバーシップが変わると、追加と削除が行われます。

Note
この SCIM アプリの Push Groups 統合のグループは、ベースの OIDC アプリ統合のグループと一致させてください。グループを一致させると、ユーザーが Access に認証したときに Okta が返すグループと、Gateway の ID が同期されたままになります。

統合を確認するには、Okta SCIM アプリケーションで View Logs を選びます。

Cloudflare One でユーザー ID が更新されたかを確認するには、SCIM プロビジョニングログを表示します。

API 設定の例

{
	"config": {
		"client_id": "<your client id>",
		"client_secret": "<your client secret>",
		"okta_account": "https://dev-abc123.oktapreview.com"
	},
	"type": "okta",
	"name": "my example idp"
}

トラブルシューティング

Failed to fetch user/group information from the identity

Failed to fetch user/group information from the identity というエラーが出る場合は、Okta の設定を再確認します。

Okta テナントのグループが 100 を超える場合は、ID プロバイダー設定に Okta API トークンを含めます。ユーザーの OIDC トークンにグループが含まれない場合、または Okta の 100 グループ上限に達した場合、Cloudflare は認証時に API トークンを使い、ユーザーの完全なグループメンバーシップを取得します。この設定は Okta 固有であり、SCIM の一部ではありません。API トークンは Access ポリシービルダーのグループ選択肢を埋めません。ポリシービルダーの選択肢は、SCIM 経由でプロビジョニングされたグループから来ます。
ユーザーの OIDC トークンで Okta が 100 を超えるグループを返す場合、Okta は一部のグループメンバーシップをトークンから省略することがあります。これは Okta のトークンクレーム制限であり、Cloudflare の制限ではありません。必要なグループが省略されると、Cloudflare はそのグループに依存するポリシーを評価できません。これを避けるには、Okta の groups claim filter を絞り、Cloudflare ポリシーで使うグループだけを含めます。詳細は Okta の group functions と dynamic allowlists のドキュメント ↗ を参照してください。
リクエストが Okta 内の ThreatInsights 機能 ↗ によってブロックされている可能性があります。

ポリシービルダーで Okta Groups セレクターが空、またはグループが足りない

Access ポリシービルダーの Okta Groups セレクターは、任意の Okta API トークンではなく、SCIM 経由でプロビジョニングされたグループで埋められます。セレクターにグループがない場合:

Okta で SCIM アプリケーションの Push Groups タブを開き、Access ポリシーで使いたいグループをプッシュします。詳細は Okta で SCIM を設定するを参照してください。
SCIM 経由でプッシュするグループが、OIDC の groups クレームで返されるグループと一致していることを確認します。
Okta API トークンを追加しても、セレクターにグループは追加されません。API トークンは認証時にユーザーのグループメンバーシップを取得するためだけに使われます。