SAML認証（シングルサインオン）

SAML 2.0 対応の Identity Provider（IdP）と連携し、シングルサインオン（SSO）でログインできるようにします。 Azure AD（Entra ID）、Google Workspace、Okta などとの連携が可能です。

設定項目

項目
IdPエンティティID
説明
Identity Provider の識別子
項目
SSO URL
説明
IdPのログインエンドポイント
項目
X.509証明書
説明
SAMLレスポンスの署名検証用
項目
メールアドレス属性名
説明
SAMLレスポンスからメールを取得する属性名（例: NameID, email）
項目
名前属性名
説明
ユーザー名を取得する属性名

設定の流れ

  • Identity Provider 側で Raxel 用のアプリケーションを作成
  • Raxel の ACS URL（SAMLレスポンス受信先）を IdP に登録
  • IdP から取得した情報（エンティティID・SSO URL・証明書）を Raxel に設定
  • 属性マッピングを調整（メール・名前）
  • テストログインで動作確認

動作モード

  • 併用モード — SAML SSO と通常のパスワードログインの両方が使用可能
  • SAML専用モード — パスワードログインを無効化し、SAML経由のみ許可

管理者を SAML 専用モードに切り替える場合、ロックアウトを避けるため必ず併用モードでテストログインに成功させてから切り替えてください。

ユーザープロビジョニング

  • SAMLログイン時、既存ユーザーは自動的にログインできる
  • 未登録のメールアドレスは、管理者設定によって自動作成または拒否

nameID によるユーザー紐付け

Raxel は SAML レスポンスの NameID を そのユーザーの安定識別子 として保存します (SamlIdentity テーブル)。 これにより以下のメリットがあります:

  • IdP 側でメールアドレスを変更しても同じ User として扱われる — 結婚や姓変更で tanaka@example.com → sato@example.com に変えても、 IdP の NameID (sub claim / immutable ID) は変わらないため、 Raxel 側の権限・所属・履歴は全部維持される
  • 初回ログイン時に nameID とユーザーを紐付け — 既存ユーザー (email で照合) と nameID をバインドし、 2 回目以降は nameID で直接ユーザー特定
  • email を別人が再利用してもアカウント乗っ取りにならない — 同じ email でも別の nameID なら別ユーザー扱い (Raxel 側で email 重複が起きないよう自動的に「使えない」 と表示)

IdP 側の推奨設定:

  • NameID Format は persistent または unspecified で IdP 内部 ID (Azure AD なら objectId、 Okta なら user.id) を返す
  • emailAddress 形式の NameID を使うと email 変更時にユーザーが分断するので非推奨
  • NameID は SAML 設定後の運用中は変更しないこと。 変更すると Raxel 側で「別人」 と判定され、 元のユーザーがログインできなくなる

対応IdPの例

  • Microsoft Entra ID（旧Azure AD）
  • Google Workspace
  • Okta
  • OneLogin
  • その他SAML 2.0準拠のIdP

トラブルシューティング

  • 署名検証エラー — 証明書が正しくない、または期限切れの可能性
  • 属性マッピング不一致 — メール属性名の設定を見直す
  • ログイン後にリダイレクトループ — ACS URLの設定ミス