OIDC シングルサインオン

このページで解決すること

組織が使っているシングルサインオンで入れるようにします。ひとつの OIDC 実装で Azure AD、Okta、Google など 仕様に沿ったプロバイダーを扱え、複数のプロバイダーを並べて使えます。ログイン画面には有効なプロバイダーごとにボタンが出ます。 自動では飛ばさず、ローカルのフォームは常に残ります。

必要なもの

• .env の PUBLIC_BASE_URL。コールバックアドレスはこの値から組み立てます。この値が無いプロバイダーは設定が未完了と示され、ログイン画面にも出ません。
• ID プロバイダー側でのアプリ登録と、そこで得る Issuer、Client ID、Client Secret。
• ローカルパスワードでログインできる管理者アカウントを最低ひとつ残すこと。マスター鍵の封印解除はローカル管理者の資格情報だけを受け付けます。

設定のしかた

ディレクトリとシングルサインオンは外部グループのマッピングにまとめてあります。グループ claim はソースの詳細で設定し、ロールとユーザーグループのルールは外部グループのマッピングページで管理します。古い「OIDC プロバイダー」のアドレスでもまだ開けます。「アイデンティティソース」で「プロバイダーを追加」を押します。

1. 表示名：ログイン画面のボタンに出る名前です。たとえば Azure AD です。
2. Issuer：https である必要があります。作成後は変えられません。
3. Client ID：作成後は変えられません。同じ Issuer と Client ID の組み合わせは一件だけです。
4. Client Secret：エンベロープ暗号化して保存します。更新のときに空欄にすると既存の値を引き継ぎます。
5. 追加の scope：openid は常に付きます。ほかに profile と email を足せます。

Microsoft Entra ID

Issuer が login.microsoftonline.com のとき、設定画面はテナント、クライアント情報、グループクレーム名と値の取得場所を Entra の画面に沿って示します。グループクレームは Token configuration で設定し、そのために groups スコープを追加しません。追加した場合は警告が出ます。Entra のトークンに検証済みメールやメールドメインの受け入れ規則に必要なクレームがなければ、その規則は通りません。

受け入れのモード

• あらかじめ紐付けたアカウントのみ：外部 ID を先に紐付けたアカウントだけがログインできます。
• ルールに従って自動で作る：ルールに合う人が最初のログインでアカウントを自動で作られます。

自動で作るルールは、テナントの識別子、組織のドメイン、メールのドメイン、メールが確認済みであることを組み合わせられます。 種類の違うルールどうしは「かつ」で、同じ種類の複数の値は「または」です。 共有の Issuer 上でメールのドメインだけを条件にするルールは拒否します。それでは組織を切り分けられないからです。 プロバイダーを複数組織の共有として強制的に扱うスイッチも別にあり、このスイッチは条件を厳しくする方向にしか働きません。

.env の OIDC_DEDICATED_ISSUERS で、どの Issuer が自組織の専用かを宣言します。

有効化と無効化

有効のスイッチはすぐに効きます。無効にするとき、画面が注意を出します。このプロバイダーで得た既存のセッションと接続はすぐに無効になります。 すでに ID の紐付けがあるプロバイダーは直接は消せません。無効化を使ってください。

監査で見えること

• ログインの成功は一件の記録になり、プロバイダーの識別子と名前、認証の方式、そしてログインがどの段階で止まったか （多要素認証の確認待ち、登録待ち、パスワード変更待ち、または正式なセッションの取得済み）が入ります。
• 自動で作られた最初のログインには、アカウント作成の記録が別に一件残ります。
• トークン交換の失敗は失敗として記録します。受け入れルールを満たさない場合は拒否として記録し、通らなかったルールを添えます。
• 送信元アドレスがアカウントの許可リストに入っていないログインは拒否として記録し、判定の根拠を含みます。
• 認証の方式とプロバイダーが一緒に付くので、シングルサインオンは既存の監査画面でもローカルログインと見分けられます。