はじめに

SAML 2.0 (Security Assertion Markup Language) ↗ は、Foundry などのサービスプロバイダー（略称 SP）と、Azure AD や Okta などのIDプロバイダー（略称 IdP）との間で認証および認可データを交換するために使用される、XML ベースのデータ形式です。SAML 2.0 の最も一般的なユースケースは、Web ブラウザーからのシングルサインオン（SSO）です。

概念

このセクションでは、Foundry で一般的に使用される認証の概念について説明します。

SAML 統合メタデータ

SAML 統合メタデータは、サービスプロバイダーメタデータとも呼ばれ、IDプロバイダーに渡す必要がある Foundry に関する情報です。この情報には、次のものが含まれます。

• エンティティID： IDプロバイダーが Foundry を識別するための一意の ID で、URN ↗ 形式の urn:uuid:[$UUID] です。
• Assertion Consumer Service (ACS) URL： アサーションに基づいてセッションを確立するために、SAML レスポンスメッセージを受け付ける Foundry のエンドポイントです。
• シングルログアウト URL： IDプロバイダーからの SAML シングルログアウトリクエストを受け付ける Foundry のエンドポイントです。
• 証明書： IDプロバイダーに送信する SAML メッセージへの署名に使用されます。

この情報は自動生成される XML ファイルとしてエンコードされ、顧客はその全体をコピーして IDプロバイダーにアップロードできます。また、Control Panel は情報を抽出して個別のフィールドに表示するため、それぞれを個別にコピーできます。

IDプロバイダーメタデータ

IDプロバイダーメタデータは、Foundry に渡す必要がある IDプロバイダーに関する情報です。この情報には、IDプロバイダーのエンティティID、シングルサインオン（SSO）およびシングルログアウトの URL、証明書が含まれます。

IDプロバイダーメタデータは XML ファイルとしてエンコードされ、次の方法で Control Panel にアップロードできます。

• アップロード：IDプロバイダーから XML ファイルを保存し、Control Panel にアップロードします。
• 取得：メタデータ検出 URI を指定します。Foundry はこの URI から、IDプロバイダーのエンティティID、シングルサインオン（SSO）およびシングルログアウト（SLO）の URL、証明書など、IDプロバイダーに関する情報を取得できます。また、指定したメタデータ検出 URI に Foundry がアクセスできるようにするには、ネットワークエグレスポリシーを設定する必要があります。

SAML 証明書には有効期限があり、有効期限が切れると、ユーザーにログインの問題が発生する場合があります。IDプロバイダーに関連付けられた証明書の有効期限が30日以内に切れる場合、Control Panel に警告バナーが表示されます。

メールドメインの照合

メールドメインは、どの IDプロバイダー統合をログインの選択肢としてユーザーに表示するかを決めるために使用されます。ユーザーがログイン画面にメールアドレスまたはユーザー名を入力すると、Foundry は設定済みのすべての IDプロバイダーのメールドメインを確認して、表示する IDプロバイダー統合を決定します。設定済みの IDプロバイダー統合のうち、ユーザーのメールドメインに一致するものだけが表示されます。

メールドメインには正規表現を使用できますが、通常は @example.com のような単純な形式を使用します。この形式は自動的に .*@example\.com に変換されます。IDプロバイダー統合をすべてのユーザーに表示する場合は、.* を使用します。

サポート対象ホスト

サポート対象ホストは、次の目的で使用されます。

• SAML 統合メタデータ内の ACS およびシングルログアウトの URL を構成します。
• これらのホストを使用してログインするユーザーにのみ統合が表示されるようにします。

エンロールメントに設定されているホストから選択できます。

属性をマッピングする

SAML レスポンスを Foundry にマッピングして、十分かつ正しいユーザー属性が渡されるようにします。

ユーザー属性

SAML ログインプロセス中にユーザーが IDプロバイダーで認証されると、SAML レスポンスが Foundry に送信されます。この SAML レスポンスには、名前、メールアドレス、利用可能な追加情報などのユーザー属性（「クレーム」とも呼ばれます）が含まれます。これらの属性は、属性キーと値（例：email → user@example.com）または複数の値を対応付けるマップとして送信されます。

Foundry に正しいユーザー属性値を設定するには、IDプロバイダーの属性（または「クレーム」）を、対応する Foundry の属性にマッピングする必要があります。Foundry では、次のマッピングが必要です。

• ID：デフォルトでは NameID に設定されますが、別の安定した識別子に変更できます。Foundry はこの値を使用して、ログインを既存のアカウントに照合します。この値は空であってはならず、SAML アサーションに常に含まれ、大文字と小文字の区別を含めて一貫した形式である必要があります。アカウントの存続期間中は変わらず、1人のユーザーを永続的かつ一意に識別する必要があります。メールアドレスやユーザー名など、変更される可能性のある値は使用しないでください。値の変更によってアカウントへのアクセスに支障が生じる可能性があります。
• ユーザー名：デフォルトでは NameID に設定されますが、別の人が読んで理解できる属性に変更できます（例：Azure AD の場合は http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name）。
• メール：メール属性にマッピングする必要があります（例：Azure AD の場合は http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress）。
• 名：名の属性にマッピングする必要があります（例：Azure AD の場合は http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname）。
• 姓：姓の属性にマッピングする必要があります（例：Azure AD の場合は http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname）。

Azure AD および Okta のマッピング例を参照してください。

属性の登録を追加をクリックすると、追加のマッピングを設定して Foundry にユーザー属性を追加できます。左側の項目に Foundry での属性名を、右側の項目に IDプロバイダーでの属性名を入力します。

各マッピングには、SAML レスポンス内の属性に複数の値がある場合の動作を選択できる切り替えがあります。この切り替えは、最初（最初に受信した値を属性に設定）またはすべて（受信したすべての値を属性に設定）に設定できます。

プロバイダーグループ

IDプロバイダーの属性に基づいてグループ（「プロバイダーグループ」と呼ばれます）を作成するように Foundry を設定することもできます。これにより、既存のグループメンバーシップを Foundry に反映できます。SAML レスポンスにグループ属性を含めるために、プロバイダー側で追加の設定が必要になる場合があります。

プロバイダーグループのマッピングを設定するには、IDプロバイダからユーザーグループをインポートチェックボックスをオンにし、SAML クレームとともに送信される属性キーをグループ属性マッピング項目に入力します。ユーザーがログインすると、設定された属性のすべての値がプロバイダーグループとして反映され、ユーザーがそのメンバーとして登録されます。このチェックボックスがオフの場合、ログイン時にプロバイダーグループのメンバーシップは最新の状態に更新されません。オフのままにする場合は、対話型ログインを必要とせずにプロバイダーグループのメンバーシップを更新できるよう、SCIM を有効にすることを推奨します。

必要に応じて、ユーザーグループの属性パターン項目に正規表現パターンを設定し、設定された属性の各値からグループ名を抽出できます。パターンに一致したテキストが Foundry でのグループ名になるため、パターンはグループ名全体に一致する必要があります。

各値にグループ名だけが含まれている場合は、この項目を空のままにします。たとえば、Engineering、Analysts、Admins の3つの値は、それぞれの名前を持つ3個のプロバイダーグループを作成します。1つの値に複数のグループ名が含まれている場合は、パターンを設定します。たとえば、属性が Engineering,Analysts,Admins という1つの値として渡される場合、パターン [^,]+ を使用すると、同じ3個のプロバイダーグループが作成されます。

詳細設定

非同期ユーザーマネージャー

非同期ユーザーマネージャー (AUM) は、ログインフローに追加できる設定可能なステップです。非同期ユーザーマネージャー（AUM） を展開すると、利用可能な AUM が表示されます。

Checkpoint ログイン

ログイン Checkpoint を作成すると、ユーザーはログイン時に設定可能なプロンプトにリダイレクトされます。このプロンプトでは、ログインを許可する前に理由の入力を求めることができます。ログイン Checkpoint を有効にするには、まず Checkpoints ログイン AUM をオンにしてから、Checkpoint を作成する手順に沿って進めます。

SAML 2.0 統合を設定する

新しい SAML 統合を設定するには、以下の該当する IDプロバイダーの手順を参照してください。

• Azure
• Okta
• その他の IDプロバイダー

トラブルシューティング

「適切な認証プロバイダーが見つからなかったため、ログインに失敗しました。詳細については、管理者にお問い合わせください。」エラー

このエラーは、ユーザーが入力したユーザー名が、Control Panel で設定され、許可リストに登録された認証プロバイダーのメールドメインのいずれにも一致しないことを示します。また、ユーザーがログインを試みているホストが、設定済みの認証プロバイダーのサポート対象ホストとして追加されていないことを意味する場合もあります。

「30日以内に証明書の有効期限が切れるプロバイダーが x 個あります。」

この警告バナーは、IDプロバイダーのメタデータに含まれる証明書の有効期限が30日以内に切れることを示します。認証の中断を避けるため、IDプロバイダーは新しい証明書に切り替える必要があります。手動アップロードまたは自動更新によって、この問題を解決できます。

手動アップロード

1. IDプロバイダーで新しい証明書を生成します。古い証明書が引き続き存在し、アクティブであることを確認してください。 これにより、新しいメタデータが Control Panel に渡されるまで、ログインは引き続き機能します。
2. Control Panel でアップロード方式を使用して、プロバイダーに新しい XML ファイルをアップロードし、有効期限が近づいている証明書と新しい証明書の両方が抽出され、表示できることを確認します。
3. 保存すると、IDプロバイダーは新しい証明書の使用に切り替え、古い証明書を削除できます。有効期限が近づいている証明書を削除した後に、メタデータを再アップロードする必要はありません。

新しい XML ファイルを Control Panel にアップロードする前に、IDプロバイダーが新しい証明書で署名を開始すると、ユーザーにログインの問題が発生します。

自動更新

前述の取得方式を設定する際に、プロバイダーメタデータ URI を使用してアイデンティティプロバイダーのメタデータを自動的に更新するを選択できます。IDプロバイダーが新しい証明書に切り替えると、次のログイン試行は最初に失敗します。これを受けて、Foundry はメタデータ検出 URI から更新済みのメタデータを自動的に取得し、リクエストを再試行するため、ユーザーのログイン操作は中断されません。

証明書のローテーション中に IDプロバイダーがメタデータ URI を変更した場合、メタデータの自動更新は機能しません。この場合は、既存の証明書の有効期限が切れる前に、Control Panel でメタデータ検出 URI を手動で更新する必要があります。