汎用 SAML 2.0

Cloudflare One は、SAML 2.0 に対応する任意の IdP と連携できます。Cloudflare One のログイン方法の連携一覧に IdP がない場合は、SAML 2.0（OIDC ベースなら OpenID）で設定できます。連携一覧にある IdP でも、追加の SAML ヘッダーやクレームを渡したい場合は汎用 SAML を使えます。

前提条件

IdP の最低要件は次のとおりです。

IdP が SAML 2.0 に準拠していること。
IdP が Single sign-on URL、Entity ID or Issuer URL、Signing certificate を提供すること。
IdP が SAML レスポンスに署名用の公開鍵を含めること。

1. IdP でアプリケーションを作成する

多くの IdP では、ユーザーが Application を作成できます。この文脈では、アプリケーションは IdP が Cloudflare へ渡して連携を確立するためのパラメーター一式です。

一般的な設定要件は次のとおりです。

IdP で、タイプを SAML にした新しい連携を作成します。
Entity/Issuer ID と Single sign-on URL の両方を次に設定します。
```
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback
```
チーム名は、Cloudflare ダッシュボード ↗ の Settings > Team name and domain > Team name で確認できます。
Name ID/Email format を emailAddress に設定します。
（任意）署名ポリシーを Always Sign に設定します。

（任意）SAML メタデータをアップロードする

IdP がメタデータファイルによる設定に対応している場合は、デフォルトまたは IdP 固有のメタデータエンドポイントを使えます。

デフォルト: https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/saml-metadata
IdP 固有: https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/<identity-provider-id>/saml-metadata。<identity-provider-id> は List Access identity providers から取得した id の値です。デフォルトのメタデータファイルにない構成が IdP で必要な場合に、このエンドポイントを使います。

SAML メタデータファイルをダウンロードするには、メタデータエンドポイントを Web ブラウザーにコピーして開き、ページを .xml ファイルとして保存します。この XML ファイルを IdP にアップロードします。

2. Cloudflare One に SAML IdP を追加する

Cloudflare ダッシュボード ↗ で、Zero Trust > Integrations > Identity providers を開きます。
Add new identity provider を選び、SAML を選びます。
IdP のわかりやすい名前を付けます。
IdP から取得した Single Sign on URL、IdP Entity ID or Issuer URL、Signing certificate を入力します。
（任意）SCIM を有効にする場合は、ユーザーとグループを同期するを参照してください。
（任意）Optional configurations で、追加の SAML オプションを設定します。
Save を選びます。

cloudflare_api_token ↗ に次の権限を追加します。
- Access: Organizations, Identity Providers, and Groups Write

cloudflare_zero_trust_access_identity_provider ↗ リソースを設定します。

resource "cloudflare_zero_trust_access_identity_provider" "generic_saml_example" {
	account_id = var.cloudflare_account_id
	name       = "Generic SAML example"
	type       = "saml"
	config 		 = {
		sso_target_url = "https://example.com/1234/sso/saml"
		issuer_url = "https://example.com/1234"
		idp_public_certs = ["-----BEGIN CERTIFICATE-----\nXXXXX\n-----END CERTIFICATE-----"]
		sign_request = false
		email_attribute_name = "email"
		attributes = ["employeeID", "groups"]
	}
}

3. 接続をテストする

これで IdP 連携をテストできます。成功レスポンスでは、設定した SAML 属性が返されます。

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

汎用 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 を使います。

前提条件

IdP が SCIM バージョン 2.0 に対応している必要があります。

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

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

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

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

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

2. IdP で SCIM を設定する

設定手順は IdP によって異なります。IdP では、元の SSO アプリケーションを編集するか、新しい SCIM アプリケーションを作成する必要があります。詳細は IdP のドキュメントを参照してください。手順の例は、Okta または JumpCloud のガイドを参照してください。

IdP グループ

IdP グループに基づいてポリシーを作成する場合:

IdP が groups フィールドを送信することを確認します。名前は完全一致である必要があります（大文字小文字は区別しません）。それ以外の値は SAML 属性として送信されます。
IdP で新しい SCIM アプリケーションが必要な場合は、そのグループが元の SSO アプリケーションのグループと一致することを確認します。グループを一致させると、ユーザーが Access に認証したときに IdP が返すグループと、Gateway の ID が同期されたままになります。

3. SCIM プロビジョニングを確認する

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

任意の設定

SAML 連携は、追加のセキュリティと設定オプションに対応しています。

SAML アサーションを暗号化する

SAML アサーションの暗号化は、IdP から Cloudflare Access へ送る SAML アサーションをエンドツーエンドで暗号化します。

暗号化なしでは、SAML アサーションは TLS 終端のあと平文で転送されます。ブラウザー拡張機能やクライアント側マルウェアから見える可能性があります。暗号化をオンにすると、IdP は Cloudflare の公開証明書でアサーションを暗号化し、対応する秘密鍵で復号できるのは Access だけです。

SAML アサーションの暗号化をオンにするには:

Cloudflare ダッシュボード ↗ で、Zero Trust > Integrations > Identity providers を開きます。
SAML IdP を選び、Edit を選びます。
SAML encryption で、Enable SAML encryption トグルをオンにします。Access は暗号化証明書を自動生成します。
表示された証明書（PEM 形式）または証明書セット ID をコピーします。
IdP に Cloudflare の暗号化証明書をアップロードし、アサーション暗号化をオンにします。正確な設定手順は IdP のドキュメントを参照してください。
Save を選びます。

暗号化をオンにしたあと、Access は設定済み IdP からの暗号化されていないアサーションを拒否します。暗号化をオフにすると、暗号化を再度オンにするまで、Access は暗号化されたアサーションを拒否します。

対応する暗号化アルゴリズム

Access は次の暗号化アルゴリズムに対応しています。

アルゴリズムの種類	対応する値
コンテンツ暗号化	AES-128-CBC、AES-256-CBC、AES-128-GCM、AES-256-GCM
鍵輸送	RSA-OAEP（XML Encryption 1.0 および 1.1）、RSA-1.5

暗号化証明書をローテーションする

暗号化証明書の有効期間は 1 年です。証明書の期限切れ 30 日前に、Access は置換用の証明書を自動生成します。期限切れ前の証明書は有効期限まで有効なままなので、新しい証明書を IdP にアップロードする時間が取れます。

証明書を手動でローテーションするには:

Cloudflare ダッシュボード ↗ で、Zero Trust > Integrations > Identity providers を開きます。
SAML IdP を選び、Edit を選びます。
SAML encryption で Rotate certificate を選びます。
新しい証明書を IdP にアップロードします。

SAML 認証リクエストに署名する

この任意の設定は、Access JWT を Cloudflare Access の公開鍵で署名し、JWT が正当な送信元から来ていることを保証します。Cloudflare の公開鍵は https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/certs で取得できます。

IdP で毎回新しい認証を要求する

SAML 認証リクエストごとに、IdP にユーザーの再認証を求められます。このオプションは、リクエストが署名付きか未署名かに関係なく適用されます。

この設定は API から利用できます。まず Access identity provider エンドポイントから IdP の現在の構成を取得します。次に、完全な構成を update identity provider エンドポイントに送り、config オブジェクトの force_authn を true にします。デフォルト値は false です。

このオプションをオンにすると、Access は各 SAML 認証リクエストで ForceAuthn を true に設定します。セキュリティチェックでユーザーの再認証が必要な場合、force_authn が false でも Access が ForceAuthn を true にすることがあります。

メール属性名

多くの Access ポリシーは、ユーザーのメールアドレスに依存します。IdP によっては、メールアドレス属性の名前が異なります（例: Email、e-mail、emailAddress）。通常は IdP の SAML テストオプションで確認できます。

Okta での例:

SAML ヘッダーと属性

Cloudflare Access は、すべての SAML IdP 連携で SAML（Security Assertion Markup Language）属性と SAML ヘッダーに対応しています。

SAML 属性 は、IdP が認証済みユーザーについて共有する特定のデータポイントまたは特性です。メールアドレス、名前、ロールなどの詳細を含むことが多く、認証成功後にサービスプロバイダーへ渡されます。

SAML ヘッダー は、SAML プロトコル通信内のメタデータです。送信者、受信者、メッセージ自体に関する情報を伝えます。これらのヘッダーを使って、通信に追加のコンテキストや制御を与えられます。

SAML 属性

SAML 属性は Access JWT に追加されます。これらの属性は、Access に接続したセルフホストまたは SaaS アプリケーションが利用できます。SAML 連携で設定した SAML 属性は、IdP からも送信する必要があります。

Okta での例:

Cloudflare でこれらの SAML 属性を受け取る方法:

SAML ヘッダー

サインイン時にアプリケーションが SAML 属性を特に必要とする場合は、属性をヘッダーとして渡せます。Attribute name は IdP から来る値にしてください（例: department）。属性には任意の Header name を割り当てられます。ヘッダー名は、Access が初期認可リクエストを https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback に送るときのレスポンスヘッダーに表示されます。

複数レコードの SAML 属性

Cloudflare Access は、グループなどの複数レコード SAML 属性にも対応しています。これらの属性は解析され、ポリシーから個別に参照できます。この機能により、アプリケーションでの細かいアクセス制御と正確なユーザー認可が可能になります。

Cloudflare Access は現在、属性値の部分参照には対応していません。