SAML アクセスコントロール

ユーザーが SAML SSO を通じてサインインすると、EK は SAML メタデータ属性（例：department、group、role）を受信します。アクセスコントロール機能は、これらの属性を使用して、ユーザーがアプリケーションへのアクセスを許可されるかどうかを判断します。

注意

アクセスコントロールと自動チーム管理は独立した機能ですが、通常は一緒に使用されます。詳細については、チームとプロジェクトの自動割り当てを参照してください。

前提条件

アクセスコントロールを有効にする前に：

• SAML SSO が設定済みで、ログイン時にメタデータ属性が送信されていること
• SAML アサーションに照合対象となる安定した属性が含まれていること

ヒント

制限を有効にする前に、いくつかの成功した SSO ログインから属性名と値を検証してください。スーパーアドミンのユーザービューには、各 SSO ユーザーの保存された SAML メタデータが表示されます。ルールを作成する際の信頼できる情報源としてご活用ください。

アクセスモード

スーパーアドミン → セキュリティとアクセス → アクセスコントロールに移動して、モードを選択します。

モード	動作
すべての新規ユーザーを許可	デフォルト。メール/パスワード、Google OAuth、SSO のサインアップがすべて許可されます。
SAML メタデータに制限	SAML 属性が設定済みルールの少なくとも1つに一致する SSO ユーザーのみが許可されます。

ルールマッチングの仕組み

ルールは属性名と1つ以上の属性値で定義されます。

メンタルモデル：すべてはセット

ルールと受信したユーザー属性の両方がトークンのセットに還元され、サブセットセマンティクスで比較されます：

• ルールは、必要なトークンがユーザーのトークンのサブセットである場合に一致します
• ルール間のロジックは OR です — 1つのルールが一致すればアクセスが許可されます
• すべての比較は大文字・小文字を区別せず、先頭および末尾の空白も無視されます

マルチトークンルール（ルール内の AND 条件）

属性値フィールドのカンマはトークン区切り文字です。UI は各カンマ区切りエントリをチップに変換し、ルールはすべてのリストされたトークンが存在することを要求します。

• engineering — 1つのトークンを要求：ユーザーの属性に engineering が含まれること
• Accounting, US — 2つのトークンを要求：ユーザーの属性に accounting と us の両方が含まれること

異なる SAML ワイヤフォーマットの処理

SAML 属性は2つのフォーマットで到着する可能性があります：

ネイティブマルチ値 — IdP が1つの <Attribute> 内に複数の <AttributeValue> 要素を送信します：

<Attribute Name="memberOf">
  <AttributeValue>Accounting</AttributeValue>
  <AttributeValue>US</AttributeValue>
</Attribute>

EK はこれを常にセットとして処理します。追加の設定は不要です。これは推奨されるフォーマットです。

CSV 対応の単一値 — IdP がカンマ区切りトークンを含む1つの <AttributeValue> を送信します：

<Attribute Name="memberOf">
  <AttributeValue>Accounting,US</AttributeValue>
</Attribute>

これは曖昧です（2つのグループなのか、カンマを含む1つのリテラル値なのか）。ルールごとのトグルを使用して解決します：

トグル：「IdP がマルチ値を1つの文字列にパック」	動作
オフ（デフォルト）	ユーザーの文字列は1つのリテラルトークンとして処理されます
オン	ユーザーの文字列はカンマで分割され、セットとしてマッチングされます

注意

このトグルはユーザーの属性の解釈方法にのみ影響します。ルール側のカンマは常にトークン区切り文字です。

マッチング動作マトリクス

ユーザー属性（ワイヤフォーマット）	トグル	ルール値	一致？
ネイティブ ["A","B","C"]	オフ	A	✓
ネイティブ ["A","B","C"]	オフ	A, B	✓
単一 "A,B,C"	オフ	A	✗
単一 "A,B,C"	オフ	A, B	✗
単一 "A,B,C"	オン	A	✓
単一 "A,B,C"	オン	A, B	✓
単一 "A"	オフ	A	✓

制限モードが有効な場合の動作

ブロックされるもの

• 新規メール/パスワード登録
• 新規 Google OAuth 登録
• SAML 属性がどのルールにも一致しない新規 SSO ユーザー

引き続き許可されるもの

• 少なくとも1つのルールに一致する既存の SSO ユーザー（毎回のサインイン時に再チェック）
• 既存のアカウントにサインインする既存のローカルユーザー
• 一致するルールがなくても SSO 経由のスーパーアドミンアカウント（緊急時のアクセス用）
• スーパーアドミンに属する API キーまたは関連するユーザーレコードのないプロジェクトレベルのキー

注意

SAML 制約付きユーザーからの API キーリクエストも、制限モード下では制御されます。EK は、API アクセスを許可する前に、ユーザーの保存された SAML メタデータ（最後の SSO サインイン時）をアクセスルールと照合します。

警告

フェイルオープン動作： 制限モードがオンでも SAML アクセスルールが存在しない場合、EK はすべての SSO ユーザーを許可します。これにより誤ったロックアウトを防げますが、厳格なガバナンスを有効にする前に、少なくとも1つのルールを定義すべきです。

アクセスコントロールの設定

1. アクセスコントロールを開く

   スーパーアドミン → セキュリティとアクセス → アクセスコントロールに移動します。

2. 制限モードを選択

   SAML メタデータに制限を選択します。

3. SAML アクセスルールを追加

   SAML アクセスルールの下に1つ以上のルールを追加します。例：

   department = engineering
   memberOf = ekb-users
   memberOf = ekb-users, us   （両方のトークンが必要）

   ユーザー側の属性がカンマ区切りの単一文字列として到着する場合は、IdP がマルチ値を1つの文字列にパックをトグルします。

4. 保存と検証

   ルールを保存し、広範囲に展開する前に代表的な SSO アカウントでテストします。

推奨される展開アプローチ

1. モードがまだすべての新規ユーザーを許可に設定されている間にルールを作成する
2. スーパーアドミンのユーザービューでパイロット SSO アカウントの保存された SAML メタデータを確認して検証する
3. SAML メタデータに制限に切り替える
4. サインインとアクセス拒否の結果を監視する

テストチェックリスト

設定後、各シナリオを確認します：

• 許可されるべき SSO ユーザーがサインインできること
• 許可されるべきではない SSO ユーザーがアクセス拒否エクスペリエンスにリダイレクトされること
• 拒否されたユーザーが期待通りのアクセス拒否エクスペリエンスを確認すること
• ポリシードリフトを防ぐために、少なくとも1つの有効なルールがアクティブであること

トラブルシューティング

ユーザーが意図せず拒否された場合

• アクセスモードが意図せず制限に設定されていないことを確認する
• ルールが正しい属性名と期待される正確な値を使用していることを確認する
• IdP がそのユーザーにその属性を送信していることを確認する
• マルチトークンルールの場合、リストされたすべてのトークンがユーザーの属性に存在する必要がある — スーパーアドミンのユーザービューで保存された SAML メタデータを確認する
• 属性が CSV 対応の単一文字列として到着する場合、ルールで IdP がマルチ値を1つの文字列にパック が有効になっていることを確認する
• 制限モードが有効な間にユーザーがメール/パスワードまたは Google OAuth ログインを試みているかどうかを確認する

スーパーアドミンがロックアウトされた場合

スーパーアドミンアカウントは、一致するルールがなくても SSO 経由で常に許可されます。ロックアウトされた場合は、スーパーアドミンアカウントを使用して SSO 経由でサインインし、アクセスを回復してください。

運用ガイド

• アクセスルールをセキュリティ上重要な設定として扱う
• 本番環境への更新には変更管理プロセスを使用する
• IdP のクレーム変更後は再テストする
• 定期的にルールをレビューし、古いマッピングを削除する
• 意図しないフェイルオープン状態を防ぐために、少なくとも1つの有効なルールをアクティブに保つ