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

システムの管理者が、会社で使っている認証の仕組み(Azure AD や Google Workspace など)に一度ログインすれば、このシステムにも続けてログインできるようにするときに使います。

SAML 2.0 対応の Identity Provider（IdP）と連携し、シングルサインオン（SSO）でログインできるようにします。 Azure AD（Entra ID）、Google Workspace、Okta などとの連携が可能です。 設定は「システム管理」→「SAML/SSO」で行います。システム管理は、左パネルの一番下の自分の名前をクリックして開くメニューの「システム管理」から開きます (システム管理者・オーナーにだけ表示されます)。

設定項目

項目
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の設定ミス