Factoryは、SAML/OIDCプロトコルを使用したSingle Sign-On（SSO）と、Directory Sync（SCIM）による自動ユーザープロビジョニングを通じて、包括的なエンタープライズアイデンティティ管理を提供します。このガイドでは、これらのシステムがどのように連携してユーザーアイデンティティ、認証、アクセス制御を管理するかについて説明します。Documentation Index
Fetch the complete documentation index at: https://factory-docs-auto-sync-jp-docs.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
概要
FactoryはWorkOSを使用してエンタープライズアイデンティティ管理を処理し、以下をサポートします：- ドメイン検証: アイデンティティガバナンスのためのメールドメインの所有権を確立
- SSO/SAML: Identity Provider（IdP）を通じたユーザー認証
- Directory Sync/SCIM: ディレクトリからのユーザーの自動プロビジョニングと管理
- Just-In-Time（JIT）プロビジョニング: SSO経由の初回ログイン時にユーザーを作成
- グループベースアクセス制御: ディレクトリグループを通じた権限管理
仕組み
ドメイン検証（最初に必要）
SSOやDirectory Syncを有効にする前に：- 所有権を検証 - DNS検証を通じてメールドメインの所有権を確認
- 既存ユーザーを取得 - あなたのドメインを持つすべてのユーザーが自動的に組織に参加
- ポリシーを設定 - MFA、セッション管理、アクセス制御を構成
- SSO/SCIMを有効化 - エンタープライズアイデンティティ管理の準備完了
SSOを使った認証
SSOが有効な場合：- ユーザーはパスワードを入力する代わりに「SSOでサインイン」をクリック
- 企業のIdentity Provider（Okta、Azure ADなど）にリダイレクト
- 企業の認証情報で認証した後、Factoryにログイン
- JITプロビジョニングが有効な場合、初回ユーザーは自動的に作成される
Directory Syncを使ったユーザープロビジョニング
Directory Sync（SCIM）が有効な場合：- ディレクトリへのユーザー追加により、Factoryで自動的にユーザーが作成
- ユーザー情報の更新がFactoryにリアルタイムで同期
- ディレクトリからのユーザー削除により、FactoryのアクセスがRevoke
- グループの変更により、ユーザー権限が自動的に更新
データの優先度
ユーザーが複数のソース（SSO、Directory Sync、手動招待）から存在する場合、Factoryは以下の優先度に従います：- Directory Syncデータが常に優先 - ディレクトリからの情報が他のソースを上書き
- ユーザーはメールでマッチング - メールアドレス（大文字小文字を区別しない）で既存ユーザーを検索
- カスタムデータは保持 - ディレクトリに存在しないFactory固有の設定は維持
- 論理削除 - 削除されたユーザーは無効化され、削除されず、作業履歴を保持
前提条件
Domains、SSO、SCIMを設定する前に：- エンタープライズSSO支援を含むプランを利用している
- 組織のメールドメインが検証済みである（以下のドメイン検証を参照）
- IdPへの管理者アクセスがある（またはITの協力者がいる）
- Factory側の設定を調整できるFactory管理者がいる
- 設定プロセスを開始するためにFactoryの担当者に連絡
設定プロセスの概要
初期設定フロー
Factoryに問い合わせる
Factoryの担当者またはsupport@factory.ai経由でSSO/SCIM設定を依頼します
設定オプション
設定中に以下を構成します：接続タイプ
接続タイプ
- SAML 2.0 - エンタープライズIdPに推奨
- OIDC - モバイルサポートに優れたモダンなプロトコル
- 両方 - 一部のプロバイダーは両プロトコルをサポート
ユーザープロビジョニング
ユーザープロビジョニング
- Just-In-Time (JIT) - 初回ログイン時にユーザーを作成
- Directory Sync (SCIM) - ディレクトリから自動プロビジョニング
- 手動 - 管理者がユーザーを個別に招待
- ハイブリッド - 複数の方式を組み合わせる
ロールマッピング
ロールマッピング
- 属性ベース - SAML/OIDCクレームからロールを取得
- グループベース - ディレクトリグループからロールを取得
- デフォルトロール - すべてのユーザーに同じ初期ロールを付与
- カスタムマッピング - 高度なルールエンジン
MFA要件
MFA要件
- IdP強制 - MFAをIdPで処理
- Factory強制 - 追加のMFAレイヤー
- 条件付き - ユーザーのロールまたは場所に基づく
- 任意 - ユーザーが選択
ドメイン検証
ドメイン検証が重要な理由
ドメイン検証は、SSOを有効にし、Factoryで組織のアイデンティティガバナンスを確立するための必須の前提条件です。これにより、組織が特定のメールドメインを所有・制御していることが証明され、エンタープライズアイデンティティ管理の安全な基盤が作成されます。ドメイン検証で可能になること
ドメインが検証されると、組織は強力な管理制御を獲得します：アイデンティティガバナンス
- 必須SSO実行 - あなたのドメインを持つすべてのユーザーにSSO経由での認証を要求
- 自動ユーザー取得 - あなたのドメインを持つ既存のFactoryユーザーが自動的に組織に参加
- メールドメイン制限 - 未承認のアカウントがあなたのドメインを使用することを防止
- ゲストユーザーポリシー - 外部協力者があなたの組織にアクセスする方法を定義
セキュリティポリシー
- MFA要件 - すべてのドメインユーザーに多要素認証を強制
- パスワードポリシー - SSO以外の認証方法の複雑さ要件を設定
- セッション管理 - セッション期間とアイドルタイムアウト設定を制御
- IP制限 - 特定のIP範囲やVPNエンドポイントへのアクセス制限
コンプライアンス制御
- 監査ログ - ドメインユーザーのすべての認証イベントを追跡
- データ居住性 - ユーザーデータを指定された地理的地域内に保持
- アクセスレビュー - ユーザーアクセス権の定期的な認定
- プロビジョニング解除ワークフロー - ユーザーが退職時のアクセス自動削除
ドメイン検証の構成
ドメイン検証はWorkOSを通じて自動的に処理されます。 2つのオプションがあります:
- 自動セットアップ - Factory管理者がプロセス全体を代行します
- セルフサービスセットアップ - WorkOSダッシュボードを使用して自分でドメインを検証します
- 検証するドメインを追加します（例:
yourcompany.com） - DNS検証用の一意のTXTレコードを受け取ります
- そのレコードをドメインのDNS設定に追加します
- WorkOSがレコードを自動検出して検証します
- 検証後にドメインポリシーを設定します
検証後に起こること
ドメインが検証されると：- 即座の効果 - あなたのドメインメールを持つすべての既存ユーザーが組織に関連付け
- 自動取得 - あなたのドメインを持つ新しいユーザーがデフォルトで組織に参加
- ポリシー実行 - 構成されたセキュリティポリシーが即座に適用
- SSO準備完了 - 検証されたドメインでSSO設定を進められる
複数ドメインサポート
組織では多くの場合、複数のドメインの検証が必要です：- プライマリドメイン - メインの企業メールドメイン
- 子会社ドメイン - 買収した会社や地域オフィス
- レガシードメイン - まだ使用されている過去のドメイン
- エイリアスドメイン - 代替スペルや短縮版
ドメイン検証のベストプラクティス
計画
計画
- 従業員が使用するすべてのメールドメインを棚卸しします
- 取得すべきでないドメイン（例: 個人メールドメイン）を特定します
- 開始前にDNS管理者と調整します
- 子会社や買収シナリオを計画します
実装
実装
- 最初にプライマリドメインを検証します
- 組織全体への展開前に小さなパイロットグループでテストします
- 各ドメインのDNSを管理するチームを文書化します
- 検証完了後も検証記録を保管します
メンテナンス
メンテナンス
- 検証済みドメインを四半期ごとに確認します
- 使用されていないドメインを削除します
- ドメイン移行時に検証を更新します
- 不正なドメイン使用の試みを監視します
一般的な問題と解決策
| 問題 | 原因 | 解決策 |
|---|---|---|
| 24時間後に検証が失敗 | DNSレコードが正しく追加されていない | TXTレコードの正確なフォーマットと配置を確認 |
| 検証後にユーザーがアクセスできない | ドメインポリシーが過度に制限的 | 実行設定を確認し調整 |
| 子会社ユーザーが含まれていない | ドメインが検証されていない | すべての子会社ドメインを追加し検証 |
| 外部協力者がブロックされる | 厳格なドメイン実行 | ゲストユーザー例外を設定 |
ドメイン検証はドメインごとに一度だけのセットアップですが、そのメリットは
そのドメインのメールアドレスを持つ現在および将来のすべてのユーザーに適用されます。
シングルサインオン（SSO）
SSOの仕組み
- ユーザーがFactoryにログインを試行
- Identity Provider（IdP）にリダイレクト
- ユーザーが企業認証情報で認証
- IdPがFactoryにSAMLアサーションを送信
- ユーザーが認証され、必要に応じてプロビジョニング（以下のJITを参照）
サポートされているSSOプロバイダー
FactoryはWorkOSを通じてすべての主要Identity Providerとの統合をサポートします。設定時にプロバイダーを選択してください：人気のSSOプロバイダー
- SAMLプロバイダー
- OIDCプロバイダー
- エンタープライズプラットフォーム
- 汎用オプション
- Okta - SAML 2.0とSCIMを完全サポート
- Microsoft Azure AD / Entra ID - SCIM付きSAML/OIDC
- Google Workspace - Google Groupsマッピング付きSAML 2.0
- OneLogin - SAML 2.0とSCIMプロビジョニング
- Ping Identity / PingOne - エンタープライズSAMLフェデレーション
- JumpCloud - クロスディレクトリ対応SAML
- CyberArk - 特権アクセス管理付きSAML
- Duo (Cisco) - MFA連携付きSAML
マジックリンクの代替案
組織がSSOを使用しない場合、Factoryは以下もサポートします：- Magic Link認証 - メールベースのパスワードレスログイン
- 外部協力者向けにSSOと併用可能
Just-In-Time（JIT）プロビジョニング
SSOがJITプロビジョニングで有効な場合：- 初回ログイン成功時にユーザーが自動作成
- ユーザープロファイルがSAML属性から入力
- 組織メンバーシップが自動作成
- 手動ユーザー招待不要
SSOの構成
準備する必要があるもの
SSO設定を開始する前に：- Identity Providerへの管理者アクセス
- テストユーザー - 組織全体の展開前にテストするパイロットグループ（例：
factory-pilot-users）を作成 - グループ戦略 - どのIdPグループがFactoryロールにマップするかを決定：
- 管理者グループ（例：
factory-admins） - メンバーグループ（例：
factory-developers） - 読み取り専用グループ（例：
factory-viewers）
- 管理者グループ（例：
設定の仕組み
WorkOSが技術的な設定を自動的に処理します。 Factoryからセットアップリンクを受け取ったら:
- リンクをクリックしてアイデンティティプロバイダーを選択します
- IdP固有のガイド付きセットアップウィザードに従います
- WorkOSがすべてのSAML/OIDC設定を自動構成します
- パイロットグループで接続をテストします
- 組織に展開します
グループからロールへのマッピング
設定中に、IdPグループがFactoryロールにどのようにマップするかを構成します：| あなたのIdPグループ | Factoryロールにマップ | 権限 |
|---|---|---|
factory-admins | 管理者 | フルアクセス、ユーザーと設定の管理 |
factory-developers | メンバー | コンテンツの作成・編集、全機能の使用 |
factory-viewers | ビューアー | 読み取り専用アクセス |
factory-contractors | メンバー | 開発者と同様だが、追跡しやすい |
統合のテスト
設定後、パイロットグループでテスト：- テストユーザーにFactoryログインページからSSO経由でサインインしてもらう
- Factory サインインページから「SSOでサインイン」/あなたのIdPボタンを使用してログインを開始
- 以下を確認：
- ユーザーがIdPにリダイレクトされ、認証し、Factoryに戻る
- ユーザーが期待されるロールで正しい組織/チームに配置される
Directory Sync（SCIM）プロビジョニング
SSOはユーザーの認証方法を制御し、SCIMはどのユーザーとグループが存在するかをFactoryで制御します。 SCIMが有効な場合：- 関連するIdPグループの新入社員が自動的にFactoryにアクセス可能になる
- これらのグループから削除されたユーザーは自動的にアクセスを失う
- グループメンバーシップの変更が手動更新なしにFactoryに伝播される
サポートされているDirectory Syncプロバイダー
FactoryはこれらのディレクトリプロバイダーからのSCIM 2.0プロビジョニングをサポートします：- SCIM完全サポート
- 部分サポート
- カスタム連携
完全なSCIM 2.0実装を備えたプロバイダー:
- Okta - Okta Universal Directoryによるリアルタイムプロビジョニング
- Microsoft Azure AD / Entra ID - エンタープライズディレクトリ同期
- OneLogin - ユーザーとグループのプロビジョニング
- JumpCloud - クロスプラットフォームのディレクトリサービス
- Google Workspace - Google Groupsと組織部門
- PingOne - PingDirectory連携
- CyberArk - 特権アクセスのプロビジョニング
プロバイダー別SCIM機能
| プロバイダー | ユーザー | グループ | リアルタイム | ネストグループ | カスタム属性 |
|---|---|---|---|---|---|
| Okta | ✅ | ✅ | ✅ | ✅ | ✅ |
| Azure AD / Entra ID | ✅ | ✅ | ✅ | ✅ | ✅ |
| Google Workspace | ✅ | ✅ | ✅ | ❌ | 部分的 |
| OneLogin | ✅ | ✅ | ✅ | ❌ | ✅ |
| JumpCloud | ✅ | ✅ | ✅ | ✅ | ✅ |
| Rippling | ✅ | 部分的 | ✅ | ❌ | 部分的 |
| 汎用SCIM | ✅ | ✅ | 可変 | 可変 | 可変 |
Directory Syncの構成
準備する必要があるもの
SCIMを有効にする前に：- 同期するグループを決定 - すべてのIdPグループがFactoryアクセスを必要とするわけではない
- グループ構造を計画 - チーム、ロール、アクセスレベルを考慮
- サービスアカウントを特定 - 人間のユーザーとCI/CDアカウントを分離
- 既存ユーザーを確認 - SCIMが引き継ぐ際にどう影響されるかを理解
SCIM設定の仕組み
WorkOSがSCIM設定を自動的に処理します。 Factoryからセットアップリンクを受け取ったら:
- WorkOSがSCIMエンドポイントURLとBearerトークンを提供します
- それらをIdPのSCIM設定に入力します
- 同期するグループを選択します（例:
factory-*グループのみ） - WorkOSが以下を自動的に処理します:
- ユーザー属性マッピング（メール、名前など）
- グループ同期
- Webhookによるリアルタイム更新
- 既存ユーザーとの競合解決
IdPでのSCIM構成
FactoryアプリケーションのIdPのSCIM設定で：- 自動プロビジョニングを有効化
- FactoryからのSCIM ベースURLとSCIMトークンを貼り付け
- 同期するユーザーとグループを選択（例：
factory-*グループのみ） - 必要に応じて属性マッピングを設定（例：
userName→ email、displayName→ name）
SCIMが有効化された時に起こること
SCIMが設定されると、グループ管理はIdPでのみ行うべきです。 以下のようなグループ命名とマッピングルールを使用：factory-org-owners→ Factory組織オーナーfactory-org-admins→ Factory組織管理者factory-users→ Factoryメンバーfactory-ci-bots→ 制限された権限を持つマシン/サービスアカウント
データ管理とマージ
ユーザーアイデンティティソース
Factoryユーザーは複数のソースから生成可能：- Directory Sync: SCIMにより自動プロビジョニング
- SSO JIT: 初回SSOログイン時に作成
- 手動招待: 管理者により追加
- API: プログラム的に作成
マージ戦略
ユーザーが複数のソースから存在する場合、Factoryは以下のルールに従います：- ディレクトリデータが優先 - SCIM属性が他のすべてのソースを上書き
- メールベースマッチング - メール（大文字小文字を区別しない）でユーザーをマッチ
- 論理削除のみ - ユーザーは無効化され削除されず、監査証跡を保持
- プロファイル保持 - 更新中に非ディレクトリフィールドを保持
競合解決
SSOとDirectory Syncの比較
両方が有効な場合、潜在的な競合は以下を含みます： シナリオ: ディレクトリがプロビジョニングする前にユーザーがSSO経由でログイン 解決: 次回同期時にディレクトリ同期がSSOユーザーとマージ ベストプラクティス: 一つの主要な方法を選択：- ディレクトリファースト: JITを無効化、ディレクトリプロビジョニングを要求
- SSOファースト: 作成にJITを使用、更新にディレクトリを使用
メール大文字小文字の区別
すべてのメールマッチングは大文字小文字を区別しません：John.Doe@company.com=john.doe@company.com- 大文字小文字のバリエーションによる重複ユーザーを防止
- 比較のためメールは小文字に正規化
トラブルシューティングとベストプラクティス
一般的な問題と推奨事項：-
ログインループまたは失敗
- ACS / リダイレクトURLがFactoryが提供したものと正確に一致することを確認
- 証明書や署名キーが期限切れまたはFactoryの更新なしにローテーションされていないことを確認
-
ユーザーが間違った組織やロールに配置
- グループメンバーシップとマッピングルールを確認
- 意図されたグループがSAMLアサーションまたはIDトークンに含まれていることを確認
-
プロビジョニングが動作しない
- FactoryとIdPの両方でSCIMが有効になっていることを確認
- IdPのSCIMログでエラー（無効なトークン、URL、またはスキーマ）を確認
- 初期展開と将来の変更に小さなパイロットグループを維持
- 明確で接頭辞ベースのグループ名（例：
factory-*）を使用してIdP設定を保守しやすくする - 既存のガバナンスプロセスを活用するために、すべてのロール変更とアクセスレビューをIdPで管理