IdP 選定

選定: Auth0

選定理由:

1. エンタープライズSSO（SAML/OIDC）が標準機能として提供
2. Organizations機能でマルチテナントのSSO管理が容易
3. SCIM対応で自動プロビジョニングが実現可能
4. 豊富なSDKとドキュメントで開発速度が高い

MFA 戦略

API 認証設計

認可モデル: RBAC + テナント分離（ABAC的要素を含む）

選定根拠:

• PayConnectの権限体系は4ロールで比較的シンプル → RBACが適切
• テナント分離が最優先課題 → ABAC的なテナントID属性チェックを追加
• ReBAC（Google Zanzibar型）は現時点でオーバースペック

ロール/権限体系

テナント分離の実装方針

多層防御によるテナント分離:

Layer 1: API Gateway
├── JWTのtenant_idクレームを検証
└── リクエストヘッダーにtenant_idを付与

Layer 2: アプリケーションミドルウェア
├── OPAにtenant_id + role + actionを送信
└── DENY の場合は 403 を返す

Layer 3: データベース（最後の砦）
├── PostgreSQL Row Level Security（RLS）
├── SET app.current_tenant = :tenant_id
└── RLSポリシーで自動フィルタリング

Layer 3 の設定:
  ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
  CREATE POLICY tenant_isolation ON invoices
    USING (tenant_id = current_setting('app.current_tenant')::uuid);

認可エンジン: OPA（Open Policy Agent）

選定理由:

1. Kubernetes統合が容易（サイドカーデプロイ可能）
2. Rego言語でテナント分離 + RBAC のポリシーを表現可能
3. OSSでコスト0円
4. 将来的にABAC/ReBACに拡張可能

SSO対応フロー

エンタープライズSSO対応フロー:

[ユーザー] ──→ PayConnect ログイン画面
                    │
                    │ メールアドレス入力: user@enterprise.com
                    │
               ┌────┴────┐
               │ ドメイン  │ enterprise.com を検索
               │ ルック   │
               │ アップ   │
               └────┬────┘
                    │
         ┌──────────┼──────────┐
         │          │          │
    SSO設定あり  SSO設定なし  ドメイン未登録
    （SAML/OIDC） │          │
         │       パスワード   エラー
         │       ログイン     「組織に問い合わせ」
         ↓
    IdPにリダイレクト
    （SAML or OIDC）
         │
         ↓
    認証成功 → テナント特定 → ロールマッピング → セッション作成

テナントSSO設定管理

フォールバック戦略