一般的な SAML 2.0
Cloudflare Zero Trust は、SAML 2.0 をサポートする任意のアイデンティティプロバイダーと統合します。アイデンティティプロバイダーが Zero Trust のログイン方法の統合リストに表示されていない場合は、SAML 2.0（または OIDC ベースの場合は OpenID）を使用して構成できます。統合リストの IdP に追加の SAML ヘッダーやクレームを渡したい場合は、一般的な SAML を使用することもできます。
アイデンティティプロバイダーの最小要件：
- IdP は SAML 2.0 に準拠している必要があります。
- IdP は シングルサインオン URL、エンティティ ID または発行者 URL、および 署名証明書を提供する必要があります。
- IdP は SAML 応答に署名公開鍵を含める必要があります。
ほとんどのアイデンティティプロバイダーは、ユーザーが アプリケーションを作成することを許可しています。この文脈では、アプリケーションはアイデンティティプロバイダーが Cloudflare に渡す一連のパラメータです。
典型的なセットアップ要件は次のとおりです：
- アイデンティティプロバイダーで SAML タイプとして新しい統合を作成します。
- エンティティ/発行者 ID と シングルサインオン URL の両方を次のように設定します：
チーム名は Zero Trust の 設定 > カスタムページ で見つけることができます。https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback
- Name ID/Email フォーマット を
emailAddressに設定します。 - （オプション）署名ポリシーを Always Sign に設定します。
アイデンティティプロバイダーがメタデータファイルの構成をサポートしている場合、デフォルトまたはアイデンティティプロバイダー固有のメタデータエンドポイントを使用できます：
- デフォルト：
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/saml-metadata - アイデンティティプロバイダー固有：
https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/<identity-provider-id>/saml-metadata、ここで<identity-provider-id>は アクセスアイデンティティプロバイダーのリスト から取得したid値です。IdP がデフォルトのメタデータファイルに定義されていない構成を必要とする場合は、このエンドポイントを使用してください。
SAML メタデータファイルをダウンロードするには、メタデータエンドポイントをウェブブラウザにコピー＆ペーストし、ページを .xml ファイルとして保存します。この XML ファイルをアイデンティティプロバイダーにアップロードします。
- Zero Trust ↗ に移動し、設定 > 認証 > ログイン方法 に進みます。
- 新規追加 を選択し、SAML を選択します。
- アイデンティティプロバイダーのための説明的な名前を選択します。
- アイデンティティプロバイダーから取得した シングルサインオン URL、IdP エンティティ ID または発行者 URL、および 署名証明書 を入力します。
- （オプション）オプションの構成を入力します。
- 保存 を選択します。
これで IdP 統合をテスト できます。成功した応答は、構成された SAML 属性を返す必要があります。
SAML 統合では、アプリケーションに追加のヘッダーやクレームを渡すことができます。
このオプションの構成は、Cloudflare Access の公開鍵で Access JWT に署名し、JWT が正当なソースから来ていることを確認します。Cloudflare の公開鍵は https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/certs で取得できます。
多くの Access ポリシー は、ユーザーのメールアドレスに依存しています。一部のアイデンティティプロバイダーは、メールアドレス属性に異なる名前を付けています（例：Email、e-mail、emailAddress）。これは通常、アイデンティティプロバイダーの SAML テストオプションで確認できます。
Okta の例：
Cloudflare Access は、すべての SAML IdP 統合に対して SAML（Security Assertion Markup Language）属性と SAML ヘッダーをサポートしています。
SAML 属性 は、IdP が認証されたユーザーに関して共有する特定のデータポイントまたは特性を指します。これらの属性には、メールアドレス、名前、役割などの詳細が含まれ、成功した認証後にサービスプロバイダーに渡されます。
SAML ヘッダー は、送信者、受信者、およびメッセージ自体に関する情報を伝える SAML プロトコル通信のメタデータです。これらのヘッダーは、通信に対する追加のコンテキストや制御を提供するために活用できます。
SAML 属性は Access JWT に追加されます。これらの属性は、Access に接続された自己ホスト型または SaaS アプリケーションによって消費されることができます。SAML 統合で構成された任意の SAML 属性は、IdP からも送信される必要があります。
Okta の例：
Cloudflare でこれらの SAML 属性を受信する方法：
アプリケーションがサインイン時に特に SAML 属性を必要とする場合、属性はヘッダーとして渡すことができます。属性名は、IdP からの値（例：department）である必要があります。属性に任意の ヘッダー名 を割り当てることができます。ヘッダー名は、Access が最初の認可リクエストを https://<your-team-name>.cloudflareaccess.com/cdn-cgi/access/callback に行うときに、応答ヘッダーに表示されます。
Cloudflare Access は、グループなどのマルチレコード SAML 属性をサポートしています。これらの属性は解析され、ポリシーで個別に参照できます。この機能により、アプリケーション内での詳細なアクセス制御と正確なユーザー認可が可能になります。
Cloudflare Access は、現在部分的な属性値の参照をサポートしていません。