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

.envのPUBLIC_BASE_URL。コールバックアドレスはこの値から組み立てます。この値が無いプロバイダーは設定が未完了と示され、ログイン画面にも出ません。- ID プロバイダー側でのアプリ登録と、そこで得る Issuer、Client ID、Client Secret。
- ローカルパスワードでログインできる管理者アカウントを最低ひとつ残すこと。マスター鍵の封印解除はローカル管理者の資格情報だけを受け付けます。
設定のしかた
Section titled “設定のしかた”ディレクトリとシングルサインオンは外部グループのマッピングにまとめてあります。グループ claim はソースの詳細で設定し、ロールとユーザーグループのルールは外部グループのマッピングページで管理します。古い「OIDC プロバイダー」のアドレスでもまだ開けます。「アイデンティティソース」で「プロバイダーを追加」を押します。
追加と編集のページでは、まずプロバイダーを Microsoft Entra ID、Google、その他の OIDC から選びます。ページは選んだプロバイダー側で各項目をどこから取得するかを示し、詳しい手順は下に折りたたんであります。新しいソースで Google を選ぶと issuer https://accounts.google.com が入り、既存のソースでは issuer から自動で判別します。この選択は案内とフォームのプロバイダー固有の部分を切り替えるだけで、選択そのものは保存しません。続けて次を入力します。
- 表示名:ログイン画面のボタンに出る名前です。たとえば Azure AD です。
- Issuer:https である必要があります。作成後は変えられません。
- Client ID:作成後は変えられません。同じ Issuer と Client ID の組み合わせは一件だけです。
- Client Secret:エンベロープ暗号化して保存します。更新のときに空欄にすると既存の値を引き継ぎます。
- 追加の scope:
openidは常に付きます。ほかにprofileとemailを足せます。
Microsoft Entra ID
Section titled “Microsoft Entra ID”Issuer が login.microsoftonline.com のとき、設定画面はテナント、クライアント情報、グループクレーム名と値の取得場所を Entra の画面に沿って示します。グループクレームは Token configuration で設定し、そのために groups スコープを追加しません。追加した場合は警告が出ます。Entra のトークンに検証済みメールやメールドメインの受け入れ規則に必要なクレームがなければ、その規則は通りません。
受け入れのモード
Section titled “受け入れのモード”- あらかじめ紐付けたアカウントのみ:外部 ID を先に紐付けたアカウントだけがログインできます。
- ルールに従って自動で作る:ルールに合う人が最初のログインでアカウントを自動で作られます。
自動で作るルールは、テナントの識別子、組織のドメイン、メールのドメイン、メールが確認済みであることを組み合わせられます。 種類の違うルールどうしは「かつ」で、同じ種類の複数の値は「または」です。 共有の Issuer 上でメールのドメインだけを条件にするルールは拒否します。それでは組織を切り分けられないからです。 編集ページには、このプロバイダーに対するシステム判定(複数組織共用か自組織専用か)とその理由が出ます。 「常に複数組織共用として扱う」スイッチは、導入側が専用と宣言したソースと、すでにこのスイッチが有効なソースに表示されます。 有効にすると複数組織共用向けの厳しいルールが常に適用され、無効にするとシステム本来の判定に戻ります。
.env の OIDC_DEDICATED_ISSUERS で、どの Issuer が自組織の専用かを宣言します。
接続前の確認
Section titled “接続前の確認”アイデンティティソースのページの「接続前の確認」パネルは、ソースが正しく設定されているかを項目ごとに示します。
- 「再探索」はディスカバリーのランプを結果と時刻で更新し、プロバイダーが宣言する issuer が入力値と一致すること、ディスカバリー文書が宣言する署名アルゴリズムにこのシステムが受け付けるものが含まれることを確かめます。通らなかったときは考えられる原因を並べます。
- ログインテストは公開 URL から組み立てたリンクで、コピーしてプライベートウィンドウや別のブラウザーで開きます。ログイン画面はリンクが指すログインの選択肢を示します。
- 直近 30 日にこのソースを通った最後のログインの試みについて、結果、時刻、ユーザー名、平易な言葉の理由、次にすることを示します。プロバイダーが返したエラーはプロバイダーの文面のまま表示します。
- 「クライアントシークレット」のランプはログイン後にプロバイダーとのトークン交換が成功したかを示し、「グループ情報」のランプはグループを観測した時刻を示し、「マッピング規則」のランプは規則がない、またはすべて無効のときに合格と表示しません。
- パネルには「再読み込み」ボタンがあり、ウィンドウがフォーカスを取り戻したときにも読み込み直します。
有効化と無効化
Section titled “有効化と無効化”有効のスイッチはすぐに効きます。無効にするとき、画面が注意を出します。このプロバイダーで得た既存のセッションと接続はすぐに無効になります。 すでに ID の紐付けがあるプロバイダーは直接は消せません。無効化を使ってください。
ある人の OIDC でのログインを止めるには、そのアカウントを無効にします。無効のアカウントで OIDC ログインすると、アカウントが無効であることがログイン画面に示されます。 アカウントを削除した場合、プロバイダーが自動作成のモードなら、その人の次のログインで同じユーザー名のアカウントが作り直され、ロールはグループのマッピングから付きます。 プロバイダーがあらかじめ紐付けたアカウントだけを受け入れる場合は、アカウントが削除されたことと管理者への連絡を求める案内がログイン画面に出ます。管理者はアカウントを作り直して外部 ID を紐付け直せます。
監査で見えること
Section titled “監査で見えること”- ログインの成功は一件の記録になり、プロバイダーの識別子と名前、認証の方式、そしてログインがどの段階で止まったか (多要素認証の確認待ち、登録待ち、パスワード変更待ち、または正式なセッションの取得済み)が入ります。
- 自動で作られた最初のログインには、アカウント作成の記録が別に一件残ります。
- トークン交換の失敗は失敗として記録します。受け入れルールを満たさない場合は拒否として記録し、通らなかったルールを添えます。
- 無効のアカウントによる OIDC ログインは拒否として記録します。
- 送信元アドレスがアカウントの許可リストに入っていないログインは拒否として記録し、判定の根拠を含みます。
- 認証の方式とプロバイダーが一緒に付くので、シングルサインオンは既存の監査画面でもローカルログインと見分けられます。