自動管理とアクセスコントロールは独立した機能ですが、通常は一緒に使用されます。詳細については、SAML アクセスコントロールを参照してください。
前提条件
自動管理を有効にする前に：- SAML SSO が設定済みで、ログイン時にメタデータ属性が送信されていること
- SAML アサーションに照合対象となる安定した属性が含まれていること
- 対象チームが EK に既に存在していること。チームの作成方法については、チーム管理を参照してください。
ルール構造
スーパーアドミン → ユーザーとワークスペース → チーム → 自動管理に移動してルールを設定します。各ルールには以下が含まれます：| フィールド | 必須 | 説明 |
|---|---|---|
| SAML 属性名 | はい | SAML アサーションの属性キー |
| 属性値 | はい | 1つ以上のカンマ区切りトークン — リストされたすべてのトークンが一致する必要があります（AND ロジック） |
| 対象チーム | はい | ユーザーを割り当てるチーム |
| デフォルトチームメンバーシップロール | オプション | Member（デフォルト）または Admin |
| チームプロジェクトに自動追加 | オプション | チーム内のすべての非デフォルトプロジェクトにユーザーを追加 |
| デフォルトプロジェクトロール | オプション | Admin、Editor、または Viewer |
| 強制的な継続チーム再割り当て | オプション | 初回ログインだけでなく、毎回のサインイン時にユーザーを移動 |
- 条件付きチームロールオーバーライド — 追加の SAML 属性に基づいてチームメンバーシップロールを変更
- 条件付きプロジェクトロールオーバーライド — 追加の SAML 属性に基づいてプロジェクトロールを変更（自動追加が有効な場合にのみ適用）
ルールマッチングの仕組み
属性マッチングはアクセスコントロールと同じエンジンを使用します。ルールとユーザー属性の両方がトークンのセットとして扱われ、サブセットセマンティクスで比較されます — ルールは必要なトークンがユーザーのトークンのサブセットである場合に一致します。- 属性値のカンマはトークン区切り文字です。
Accounting, USはユーザーが両方のトークンを持っていることを要求します（1ルール内の AND ロジック）。 - 特異性はルールが要求するトークンの数に等しいです。複数のルールが一致する場合、最も特異な（トークン数の多い）ルールが優先されます。
異なる SAML ワイヤフォーマットの処理
SAML 属性は2つのフォーマットで到着する可能性があり、各ルールにはそれらを処理するトグルが用意されています： ネイティブマルチ値 — IdP が複数の<AttributeValue> 要素を送信します。EK はこれを自動的にセットとして扱います。
CSV 対応の単一値 — IdP が値をカンマ区切りの文字列にパックします。ルールごとのトグルを使用します：
| トグル：「IdP がマルチ値を1つの文字列にパック」 | 動作 |
|---|---|
| オフ（デフォルト） | ユーザーの文字列は1つのリテラルトークンとして処理されます |
| オン | ユーザーの文字列はカンマで分割され、セットとしてマッチングされます |
チーム割り当て動作
毎回の SSO サインイン時に、EK は設定済みルールをユーザーの SAML メタデータに対して評価し、最も特異な一致ルールを選びます。| ユーザーステート | 結果 |
|---|---|
| チームに未所属 | 対象チームに割り当て |
| 対象チームに既に所属 | 変更なし |
| 異なるチームに所属 | 強制的な継続チーム再割り当てが有効な場合のみ移動 |
| メンバー複数のチームのオーナー | 強制的に移動されない（オーナーシップの孤立を防止） |
| チームの唯一のメンバー/オーナー | 移動；空になったチームは削除 |
初回の SSO オンボーディングでは、正しい配置を確立するために再割り当ては常に強制されます。
チームメンバーシップロール
ユーザーがチームに追加されるロールは、以下の順序で解決されます：- 条件付きチームロールオーバーライド — ユーザーのトークンにサブセット一致する最も特異なオーバーライド
- デフォルトチームメンバーシップロール — ルールで設定された
MemberまたはAdmin（レガシーデフォルト：Member）
チームロールは追加時のみ適用されます。ユーザーが既に対象チームにいる場合、既存のロールは保持されます — 以降のサインインでは変更されません。既存のメンバーの昇格や降格には、管理者の明示的な操作が必要です。
条件付きチームロールオーバーライド
各オーバーライドには属性名、属性値、オプションのis_csv_value トグル、およびチームロール（Member または Admin）を指定します。最も特異な一致オーバーライドが優先されます；同点の場合は警告がログに記録されます。
プロジェクトへの自動追加
ルールでチームプロジェクトに自動追加が有効な場合、EK は対象チームの非デフォルトプロジェクトにユーザーを追加します。ユーザーは既にメンバーではないプロジェクトにのみ追加されます。 ロール割り当ての優先順位：- 一致する条件付きプロジェクトロールオーバーライド（最も特異な一致）
- チームルールで定義されたデフォルトプロジェクトロール
プロジェクト割り当ては非同期で実行されます。チームメンバーシップはすべてのプロジェクトメンバーシップの完了前に表示される場合があります。
プロジェクトロールは追加時のみ適用されます。既存のプロジェクトメンバーシップは、以降のサインインで再評価や変更が行われることはありません。
条件付きプロジェクトロールオーバーライド
ロールオーバーライドにより、追加の SAML 属性に基づいて異なるプロジェクトロールを割り当てることができます。 例：- チームルール：
department = engineering、デフォルトロール →Viewer - ロールオーバーライド：
level = manager→Admin
- すべての
engineeringユーザーがチームに追加 level = managerも持つユーザーは自動追加プロジェクトでAdminを受け取る- マネージャーでないユーザーは
Viewerを維持
複数の条件付きロールオーバーライドが同じユーザーに一致する可能性がある場合、最も特異な（トークン数の多い）ものが優先されます。同点の場合は警告がログに記録され、最初に作成されたオーバーライドにフォールバックします — 同点を避けるためにオーバーライドを再構成してください。
チーム再割り当て制限
スーパーアドミン → チーム → 自動管理 → チーム再割り当て制限にあるこれらの設定は、ユーザーがチーム間を移動した場合のプロジェクトメンバーシップへの影響を制御します。3つすべてのデフォルトはオフ（非破壊的）です。
| 設定 | 説明 |
|---|---|
| 1. 旧チームのプロジェクトからユーザーを削除 | マスタースイッチ。再割り当て時に旧プロジェクトメンバーシップを削除します。 |
| 2. ユーザーが所有するプロジェクトはフォローする | 設定1に依存。所有プロジェクトは新しいチームに移動します。 |
| 3. フォローされたプロジェクトから旧チームメンバーを削除 | 設定1と2に依存。移動されたプロジェクトの旧チームアクセスをクリーンアップします。 |
- 設定1のみ — ユーザーは旧チームのプロジェクトから削除されます；所有プロジェクトは旧チームに残り、所有権は旧チームのオーナーに移譲されます
- 設定1 + 2 — ユーザーが所有するプロジェクトは新しいチームに移動します；既存のメンバーはそのまま残ります
- 設定1 + 2 + 3 — オーナーと一緒に移動したプロジェクトから旧チームメンバーも削除されます
自動管理ルールの設定
SAML 照合条件を入力
SAML 属性名、属性値、対象チームを指定します。マルチトークンルールの場合、各トークンを入力してカンマを押してチップを作成します（例：
accounting + us で両方を要求）。必要に応じて IdP がマルチ値を1つの文字列にパック をトグルします。チームメンバーシップロールを設定
デフォルトチームメンバーシップロール（
Member または Admin）を選択し、必要に応じて追加の属性に基づいて異なるチームロールを必要とするユーザー向けの条件付きチームロールオーバーライドを追加します。ルール設計のベストプラクティス
- 安定したアイデンティティプロバイダー属性を使用する — 変動しやすい値や頻繁に変更される値を避ける
- 属性名を正確な SAML クレーム名と一致させる（一部の IdP ではクレームレベルで大文字・小文字を区別）
- IdP がサポートしている場合は、ネイティブマルチ値 SAML 属性を推奨 — 曖昧さがなく
is_csv_valueトグルが不要 - 同等の特異性で重複するルールを避ける — 「Ambiguous match」警告が表示される場合は、ルールにトークンを追加して厳密により特異にする
- 最小権限（
Memberチームロール、Viewerプロジェクトロール）から開始し、条件付きオーバーライドで必要な場合のみ昇格 - ルールの所有権を文書化し、定期的なレビューをスケジュールする
テストチェックリスト
設定後、各シナリオを確認します：- 許可されたユーザーが正しいチームロールで正しいチームに配置されること
- 条件付きチームロールオーバーライドが正しいユーザーに適用されること
- プロジェクト自動追加が正しいロールで完了すること（非同期処理に数秒かかる場合があります）
- 条件付きプロジェクトロールオーバーライドが正しいユーザーに適用されること
- 強制再割り当てが期待通りに動作すること（有効な場合）
- チーム移動時に再割り当て制限設定が正しく動作すること
トラブルシューティング
ユーザーがサインインしたが期待されるチームに割り当てられなかった場合
ユーザーがサインインしたが期待されるチームに割り当てられなかった場合
- 一致するチーム割り当てルールが存在することを確認
- 対象チームがまだ存在することを確認
- ルールの属性/値トークンがユーザーの実際の SAML メタデータのサブセットであることを確認（スーパーアドミンのユーザービューを確認）
- ユーザーが別のチームに既に所属しており移動が必要な場合は強制的な継続チーム再割り当てを有効にする
- ユーザーがメンバー複数のチームのオーナーの場合、自動的に移動されません — これは意図的な動作です
- ログに
Ambiguous match警告が含まれている場合、2つのルールが同等の特異性で同点です。重複を排除するために再構成する
ユーザーがチームに割り当てられたが、正しいチームロールでない場合
ユーザーがチームに割り当てられたが、正しいチームロールでない場合
- 条件付きチームロールオーバーライドが存在し、ユーザーに一致するかどうかを確認
- チームロールは追加時のみ適用されます — オーバーライドが追加される前にユーザーが既にチームにいた場合、既存のロールは保持されます。手動で昇格または降格してください
- オーバーライド間の同点の場合、ログを確認し、意図したオーバーライドにトークンを追加して厳密により特異にする
ユーザーがチームに割り当てられたが、プロジェクトに割り当てられなかった場合
ユーザーがチームに割り当てられたが、プロジェクトに割り当てられなかった場合
- 一致したルールでチームプロジェクトに自動追加が有効であることを確認
- チームに非デフォルトプロジェクトが存在することを確認
- 有効なプロジェクトロール（
Admin、Editor、またはViewer）が設定されていることを確認 - 非同期バックグラウンド処理に短い遅延を許容する
ロールオーバーライドが適用されなかった場合
ロールオーバーライドが適用されなかった場合
- ロールオーバーライドが正しいチーム割り当てルールにアタッチされていることを確認
- 追加の属性/値がユーザーの SAML メタデータに実際に存在することを確認
- デフォルトロールが適用されている場合、条件付きオーバーライドが一致しなかったことを意味します
- 属性が CSV 対応の単一文字列として到着する場合、オーバーライドで IdP がマルチ値を1つの文字列にパック が有効であることを確認
ログに「Ambiguous match」警告が表示される場合
ログに「Ambiguous match」警告が表示される場合
同等の特異性を持つ2つ以上のルール（またはオーバーライド）が同じユーザーに一致しました。EK はDeterministicに最初に作成されたルールを選びましたが、設定は脆弱です。ログ行には同点のルール ID がリストされます。1つを編集して追加のトークンを追加し、厳密により特異にするか、重複を完全に削除してください。
運用ガイド
- 割り当てルールをセキュリティ上重要な設定として扱う
- 本番環境への更新には変更管理プロセスを使用する
- IdP のクレーム変更後（例：CSV 対応からネイティブマルチ値への切り替え、クレームの名前変更）は再テストする
- 定期的にルールをレビューし、古いマッピングを削除する
- 新しいルールを作成する前に、スーパーアドミンのユーザービューで保存された SAML メタデータを確認する