> ## Documentation Index
> Fetch the complete documentation index at: https://ai-kb.automationanywhere.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SAML アクセスコントロール

> SAMLメタデータ属性を使用して、EKへのサインインまたは登録を許可するユーザーを制御します。

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

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

## 前提条件

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

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

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

## アクセスモード

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

<img src="https://mintcdn.com/automationanywhere/P9UkIpAqpipG-xbe/img/sa/access-mode.png?fit=max&auto=format&n=P9UkIpAqpipG-xbe&q=85&s=221e1cef0569afded822f8a5d8115b26" alt="アクセスモードの選択" width="834" height="263" data-path="img/sa/access-mode.png" />

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

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

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

<img src="https://mintcdn.com/automationanywhere/AnqQHTb8za_1axzx/img/sa/saml-access-rules-v2.png?fit=max&auto=format&n=AnqQHTb8za_1axzx&q=85&s=0ff76c9da8d4c415e10bd1b8476cceee" alt="SAML アクセスルール" width="1744" height="1038" data-path="img/sa/saml-access-rules-v2.png" />

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

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

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

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

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

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

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

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

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

```xml theme={null}
<Attribute Name="memberOf">
  <AttributeValue>Accounting</AttributeValue>
  <AttributeValue>US</AttributeValue>
</Attribute>
```

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

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

```xml theme={null}
<Attribute Name="memberOf">
  <AttributeValue>Accounting,US</AttributeValue>
</Attribute>
```

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

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

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

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

| ユーザー属性（ワイヤフォーマット）     | トグル | ルール値   | 一致？ |
| --------------------- | --- | ------ | --- |
| ネイティブ `["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`    | ✓   |

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

<AccordionGroup>
  <Accordion title="ブロックされるもの">
    * 新規メール/パスワード登録
    * 新規 Google OAuth 登録
    * SAML 属性がどのルールにも一致しない新規 SSO ユーザー
  </Accordion>

  <Accordion title="引き続き許可されるもの">
    * 少なくとも1つのルールに一致する既存の SSO ユーザー（毎回のサインイン時に再チェック）
    * 既存のアカウントにサインインする既存のローカルユーザー
    * 一致するルールがなくても SSO 経由のスーパーアドミンアカウント（緊急時のアクセス用）
    * スーパーアドミンに属する API キーまたは関連するユーザーレコードのないプロジェクトレベルのキー
  </Accordion>
</AccordionGroup>

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

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

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

<Steps>
  <Step title="アクセスコントロールを開く">
    **スーパーアドミン → セキュリティとアクセス → アクセスコントロール**に移動します。
  </Step>

  <Step title="制限モードを選択">
    **SAML メタデータに制限**を選択します。
  </Step>

  <Step title="SAML アクセスルールを追加">
    **SAML アクセスルール**の下に1つ以上のルールを追加します。例：

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

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

  <Step title="保存と検証">
    ルールを保存し、広範囲に展開する前に代表的な SSO アカウントでテストします。
  </Step>
</Steps>

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

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

## テストチェックリスト

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

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

## トラブルシューティング

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

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

## 運用ガイド

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