Open WebUIの認証・SSO・権限設計。Entra ID／Google／LDAPでログインさせ、部門ごとに見える文書を分ける

Q: Open WebUIをEntra ID（Microsoft 365）でログインさせるには何が必要ですか？

Entra IDでアプリを登録し、リダイレクトURIに https:// /oauth/microsoft/callback を設定します。Open WebUI側には MICROSOFT_CLIENT_ID、MICROSOFT_CLIENT_TENANT_ID、クライアントシークレットを設定し、ENABLE_OAUTH_SIGNUP を有効にして初回ログインでアカウントを作らせます。トークンの更新が必要なら OAUTH_SCOPES に offline_access を加えます。グループをEntra IDから同期する場合は ENABLE_OAUTH_GROUP_MANAGEMENT と OAUTH_GROUP_CLAIM を設定します。

Q: 閉域の構成でもSSOは使えますか？

IdPがクラウドなら、IdPへの経路だけを開ける必要があり、完全閉域ではなくなります。許可する宛先を限定して設計書に明記します。完全閉域で完結させたい場合は、社内のLDAPサーバーで認証する構成か、閉域内の認証プロキシと信頼ヘッダー認証を使う構成になります。LDAPの公式の例はOpenLDAPで、Active Directoryでの動作は検証して確かめてください。

社内にローカルLLMを置くとき、利用者が触るのは推論エンジンではなくUIです。Open WebUIはその代表で、ChatGPTに似た画面で社内モデルと社内文書（ナレッジ）を使えます。ところが導入直後の構成では、「誰でもアカウントを作れる」「取り込んだ文書が全員に見える」「推論APIに直接つながる」といった状態になりがちで、ファイルサーバーで守っていた部門ごとの閲覧権限が、AIに聞いた途端に崩れます。『ローカルLLMは本当に安全か』で「アクセス制御の欠如」として挙げた問題の、実装編が本記事です。

本記事では、2026年10月3日時点のOpen WebUI公式ドキュメント（open-webui/docs リポジトリ）で確認できる範囲に限って、認証方式の選び方、最初に決める設定、Entra ID／Google／汎用OIDCでのSSO、ロールとグループをIdP側で管理する方法、部門ごとに見える文書を分ける設定、権限の既定値、信頼ヘッダー認証の落とし穴、APIキー、閉域での注意点を、設定チェックリストまで含めて整理します。設定名と挙動はバージョンで変わるため、適用前に必ずお使いのバージョンのドキュメントで再確認してください。

この記事の要点

Open WebUIの認証は、ローカルのメール／パスワード、SSO/OIDC（Google・Microsoft・GitHub・汎用OIDC）、LDAP、プロキシの信頼ヘッダー、SCIM 2.0によるプロビジョニングから選べます。社内の認証基盤に合わせて1つを主にし、退職者のアカウントが自動で失効する経路を優先します

ロールは admin／user／pending の3つで、新規ユーザーの初期ロールは DEFAULT_USER_ROLE で決めます。社内公開でも pending にして管理者承認を挟むのが安全です

権限は加算型で、Deny がありません。複数グループに属する人は権限の和集合を持つため、「見せない」はグループに権限を付けないことでしか実現できません。この性質を前提にグループを設計します

ナレッジ・モデル・ツールは既定で非公開で、作成者がユーザーまたはグループに read／write を付与します。部門ごとに見える文書を分けるには、部門グループを作り、部門ナレッジにその部門だけ read を付け、全社公開は明示的な操作に限定します

信頼ヘッダー認証は「設定を誤ると任意のユーザーとして認証できてしまう」と公式に警告されています。リバースプロキシ以外からOpen WebUIに到達できない構成が条件です

「認証なし」で社内公開すると何が起きるか

Open WebUIを社内LANに公開するとき、最初の壁は「ログインの仕組みをどうするか」です。ここを後回しにして「とりあえず全員がアカウントを作れる状態」で始めると、次の3つが同時に起きます。

誰が使っているか分からない。ローカル認証で各自が自由にアカウントを作ると、退職者や異動者のアカウントが残り、名簿と一致しなくなります
取り込んだ文書が全員に見える。ナレッジを公開設定で作ると、人事や経営の文書を含む索引が全社員の検索対象になります。ファイルサーバーの権限設計がAIの回答で迂回される形です
UIを経由しない利用が残る。推論エンジン（OllamaやvLLM）に社内から直接つなげる状態だと、UIでどれだけ権限を絞っても意味がありません

3つ目はUIの外の話で、推論サーバーの待ち受けを絞り、前段のリバースプロキシで認証を付ける対策を『ローカルLLMは本当に安全か』の「Ollamaを社内に置くときのセキュリティ設定チェック」にまとめています。本記事はUI層、つまりOpen WebUIの中での「誰が」「何を」の設計に絞ります。

なお、UI層にも脆弱性は公表されます。Open WebUIでは、アカウント乗っ取りからコード実行につながるCVE-2025-64496（バージョン0.6.35で修正）や、認証を回避して設定情報を読み出せるCVE-2025-63391が公表されています。認証と権限をどれだけ設計しても、更新を止めれば設計ごと迂回されます。更新の回し方は『閉域ローカルLLMの運用手順書』を参照してください。

認証方式の比較（ローカル・OIDC・LDAP・信頼ヘッダー・SCIM）

公式ドキュメントが挙げる認証方式を、社内導入の観点で並べます。選ぶ基準は「退職者のアカウントが自動で失効するか」と「既存の認証基盤に乗れるか」の2点です。

方式	向く規模・状況	必要なもの	注意点
ローカル認証（メール／パスワード）	数人の検証段階、認証基盤がない小規模組織	Open WebUIだけ	名簿との同期がない。退職者の失効は手作業。サインアップの扱いを必ず決める
SSO/OIDC（Google・Microsoft・GitHub・汎用OIDC）	Google WorkspaceやMicrosoft 365（Entra ID）、Okta、Keycloakを使っている組織	IdP側でのアプリ登録、クライアントID／シークレット、リダイレクトURI	汎用OIDCの `OPENID_PROVIDER_URL` で設定できるプロバイダは同時に1つ。IdPがクラウドなら閉域から経路が要る
LDAP	社内にLDAPサーバーがあり、閉域内で認証を完結させたい組織	LDAPサーバーへの到達、検索用アカウント（DNとパスワード）	公式の例はOpenLDAP。環境変数は初回起動時だけ読まれ、以降は管理画面で変更する
信頼ヘッダー認証	既に認証プロキシ（社内SSOのリバースプロキシ）を持つ組織	プロキシがメールアドレスをヘッダーで付与する構成	公式に「設定を誤ると任意のユーザーとして認証できてしまう」と警告。プロキシ以外から到達不可にする
SCIM 2.0	IdPからユーザーとグループを自動で作成・更新・無効化したい組織	SCIM対応のIdP	認証そのものではなくプロビジョニング。SSOと組み合わせる

実務では、SSO/OIDCかLDAPのどちらかを主にし、ローカル認証は「最初の管理者」と「緊急時の予備」に限定するのが安全です。SCIMはユーザーの増減が多い組織で、グループ所属の同期まで自動化したい場合に加えます。

初期設定で最初に決める3つのこと

認証方式の前に、どの方式でも共通して決めておく項目が3つあります。ここを飛ばすと、SSOを入れても穴が残ります。

1. 最初の管理者を誰にするか

新規インストールで最初に作ったアカウントが admin になります。この admin は権限チェックを通過する「スーパーユーザー」なので、個人の業務アカウントではなく、情シスが管理する専用アカウントにします。自動構築では WEBUI_ADMIN_EMAIL、WEBUI_ADMIN_PASSWORD、WEBUI_ADMIN_NAME を設定すると、初回起動時に admin を作成し、同時にサインアップを無効（ENABLE_SIGNUP=False）にします。「最初に誰かがアクセスした瞬間に管理者が決まる」状態を避けられるため、社内公開前の自動構築ではこの方法が向きます。

2. 新規ユーザーの初期ロールを pending にする

新規ユーザーに付くロールは DEFAULT_USER_ROLE で決め、pending、user、admin から選びます。公式は公開インスタンスでは pending を推奨していますが、社内公開でも pending が安全です。pending のユーザーは承認されるまで何もできず、管理者が Admin Panel > Users で承認して user に上げます。SSOと組み合わせると「IdPでログインできた人」が自動で user になるわけではなく、承認の一手間が入るため、部門と役割を確認してからグループに入れる運用ができます。承認を自動化したい場合は、後述のロール連携でIdP側のクレームから user を付与します。

3. サインアップの扱いを決める

ローカル認証を残すなら、ENABLE_SIGNUP を無効にして、管理者がアカウントを作る運用にします。SSOを主にするなら、ENABLE_OAUTH_SIGNUP を有効にして初回のSSOログインでアカウントを作らせ、既存のローカルアカウントとメールアドレスで突き合わせるときは OAUTH_MERGE_ACCOUNTS_BY_EMAIL を使います。メールアドレスで自動的に結合する設定は便利ですが、IdP側でメールアドレスが変更できる環境では、別人のアカウントに結合される経路になりえます。IdPでメールの変更権限が利用者にない組織でだけ有効にしてください。

SSOの設定手順（Entra ID／Google／汎用OIDC）

SSOは「IdP側でアプリを登録する」「Open WebUI側に環境変数を入れる」「リダイレクトURIを一致させる」の3段で設定します。リダイレクトURIの形式は <open-webui>/oauth/{provider}/callback で、たとえばMicrosoftなら /oauth/microsoft/callback、Googleなら /oauth/google/callback、汎用OIDCなら /oauth/oidc/callback です。値はすべてプレースホルダで示します。

Entra ID（Microsoft 365）の場合

Entra IDでアプリを登録し、リダイレクトURIに https://<open-webui>/oauth/microsoft/callback を設定します
クライアントID、クライアントシークレット、テナントIDを控えます
Open WebUI側に MICROSOFT_CLIENT_ID、MICROSOFT_CLIENT_TENANT_ID、クライアントシークレットを設定し、ENABLE_OAUTH_SIGNUP を有効にします
トークンの更新が必要な場合は、OAUTH_SCOPES に offline_access を加えます（既定は openid email profile）

Google Workspaceの場合

Google Cloudでクライアントを作成し、リダイレクトURIに https://<open-webui>/oauth/google/callback を設定します
GOOGLE_CLIENT_ID とクライアントシークレットをOpen WebUI側に設定します
社外のGoogleアカウントでログインされないよう、許可するドメインをIdP側とOpen WebUI側の両方で絞ります

汎用OIDC（Okta・Keycloakなど）の場合

IdPでクライアントを作り、リダイレクトURIに https://<open-webui>/oauth/oidc/callback を設定します
OAUTH_CLIENT_ID、OAUTH_CLIENT_SECRET、OPENID_PROVIDER_URL（ディスカバリURL）、画面に表示する名前の OAUTH_PROVIDER_NAME を設定します
汎用OIDCは同時に1プロバイダだけです。複数のIdPを使う組織は、IdP側で連携させて1つに見せる構成にします

SSOを主にするなら、OAUTH_AUTO_REDIRECT でログイン画面を飛ばしてIdPへ直接遷移させ、ENABLE_LOGIN_FORM を false にしてローカルのログインフォームを隠します。ただし、IdPが止まったときに管理者がログインできる予備経路（ローカルの管理者アカウントと、フォームを一時的に戻す手順）を運用手順書に残しておきます。ENABLE_OAUTH 自体は既定で有効で、SSOを使わない構成ではこれを無効にします。

ロールとグループをIdP側で管理する

SSOでログインできるようにしただけでは、「誰が管理者か」「誰がどの部門グループか」はOpen WebUI側で手作業になります。これをIdPのクレームから自動で決める仕組みが、ロール連携とグループ連携です。

連携	変数	動き
ロール連携	`ENABLE_OAUTH_ROLE_MANAGEMENT`、`OAUTH_ROLES_CLAIM`、`OAUTH_ALLOWED_ROLES`、`OAUTH_ADMIN_ROLES`	IdPのトークンに含まれるロールのクレームを読み、許可ロールに含まれる人を user、管理者ロールに含まれる人を admin にする
グループ連携	`ENABLE_OAUTH_GROUP_MANAGEMENT`、`OAUTH_GROUP_CLAIM`	KeycloakやAzure ADなどのグループをOpen WebUIのグループに同期する
グループの自動作成	`ENABLE_OAUTH_GROUP_CREATION`	IdP側にあってOpen WebUIに無いグループを自動で作り、所属をクレームに厳密に一致させる

設計で押さえる点は2つあります。

1つ目は、権限が加算型で Deny が無いことです。複数のグループに属する人は、すべてのグループの権限の和集合を持ちます。「営業部にはファイルアップロードを許可するが、営業部のうち契約社員には許可しない」という引き算はできません。この場合は「営業部（正社員）」「営業部（契約）」のようにグループを分け、権限を付けないグループを作ることで実現します。IdP側のグループ設計を、この加算型に合わせて見直すのが先です。

2つ目は、admin は権限チェックを通過することです。OAUTH_ADMIN_ROLES に対応づけるIdP側のロールは、情シスの運用担当だけに絞ります。部門長を admin にすると、部門長が全部門のナレッジを読める状態になります。部門の管理は admin ではなく、後述のナレッジへの write 権限で行います。

グループの自動作成を有効にすると、所属はIdPのクレームに「厳密に一致」します。Open WebUI側で手動で加えた所属は、次のログインで消えます。手動の例外運用を残したい場合は、自動作成を無効にして同期の対象を限定するか、例外用のグループをIdP側に作ります。

部門ごとに見える文書を分ける

ここが本記事の中心です。Open WebUIのナレッジ（RAGの文書集合）、モデル、ツール、プロンプト、チャンネルは、公式ドキュメントのとおり既定で非公開です。作成者がユーザーまたはグループに read か write を付与し、全体公開はワイルドカードの付与として保存されます。非公開でアクセスリストが空なら所有者だけが見られ、BYPASS_ADMIN_ACCESS_CONTROL が有効な場合は admin も見られます。

この仕組みを使って、ファイルサーバーの部門権限をAI側でも再現します。

手順	設定	目的
1. 部門グループを作る	営業、開発、管理のようにグループを作る。SSOなら `ENABLE_OAUTH_GROUP_MANAGEMENT` でIdPから同期する	「誰が」を確定する
2. ナレッジを部門ごとに分ける	部門の文書は部門ごとのナレッジに取り込む。全社共通の規程類だけ「全社ナレッジ」にする	索引の分割（『ローカルLLMは本当に安全か』のリスク④）
3. 部門ナレッジに部門グループへ read を付ける	営業ナレッジは営業グループだけ read。取り込みを担当する人には write	他部門から見えない状態を作る
4. 全社公開は明示的な操作に限る	全社ナレッジだけ公開（ワイルドカード付与）にする。部門ナレッジは公開しない	「うっかり公開」を防ぐ
5. グループへの共有可否を決める	各グループの「誰がこのグループへ共有できるか」を Anyone（既定）／Members／No one から選ぶ。権限付与だけに使うグループは No one	無関係な人が部門グループへ文書を共有するのを防ぐ
6. モデルとツールも同じ考え方で	部門専用のモデル（システムプロンプトを部門向けにしたもの）やツールも、部門グループに限定する	モデル経由でナレッジが見える経路を塞ぐ

注意が要るのは、ナレッジを紐づけたモデルです。部門ナレッジを参照するモデルを全社公開にすると、モデルを通じてナレッジの内容が回答に出ます。ナレッジとモデルの両方を同じグループに限定してください。

また、利用者が任意の文書を自分でナレッジに取り込める権限（Workspaceの Knowledge 権限）を部門ユーザーに与えると、機密文書が利用者の手で索引に入ります。取り込みは部門ごとの担当者（write 権限）に限定し、承認の運用を『社内生成AI利用規程のひな形2026』の規程に書きます。

文書のパース・埋め込み・検索の構成そのものは『社内文書RAGの作り方2026』で扱っています。本記事の権限設計は、その上に載せるものです。

権限の既定値の決め方

権限は Admin Panel > Users > Groups > Default Permissions で既定値を決め、グループごとに追加します。公式の分類は Workspace（Models・Knowledge・Prompts・Tools・Skills と各 import/export）、Sharing（共有・公開）、Chat（ファイルアップロード、Web添付、メッセージ編集、再生成、音声入出力、チャット共有・エクスポート）、Features（Web検索、画像生成、Code Interpreter、Memories、Automations、Calendar）、Settings の5つです。環境変数では USER_PERMISSIONS_ 接頭辞のもの（例: USER_PERMISSIONS_CHAT_FILE_UPLOAD）や、ENABLE_WEB_SEARCH、ENABLE_IMAGE_GENERATION で機能自体を制御できます。

社内導入での既定値の考え方を表にします。既定は「最小」にし、必要なグループに加算する方針です。

権限	部門ユーザー（既定）	取り込み担当（部門グループ）	管理部門（人事・経理）	管理者
チャットのファイルアップロード	許可（一時的な資料の添付用）	許可	許可	許可
Knowledge の作成・取り込み	不許可	許可（部門ナレッジのみ write）	許可（管理部門ナレッジのみ）	許可
共有・公開（Sharing）	不許可	部門グループ内のみ	不許可	許可
Web検索・Web添付	閉域では機能自体を無効	同左	同左	同左
画像生成	不許可（業務要件があるグループだけ）	不許可	不許可	許可
Code Interpreter	不許可（分析用途のグループだけ）	不許可	不許可	許可
チャットのエクスポート	不許可	不許可	不許可	許可

Web検索とWeb添付は、閉域構成ではそもそも外に出られないため、権限ではなく機能自体を無効にします（『生成AIをオフラインで使う2026』）。チャットのエクスポートは、会話履歴が端末に落ちる経路なので既定では閉じます。Code Interpreter は売上データの集計などで有用ですが、実行環境が社内に置かれているかを確認してから、必要なグループだけに開きます（『ローカルLLMでExcel・CSVを分析する2026』）。

加算型である以上、「既定で許可したものは、どのグループでも取り消せない」点に注意してください。既定値は迷ったら不許可にし、グループで足します。

信頼ヘッダー認証の落とし穴

既に社内SSOのリバースプロキシを持つ組織では、プロキシが認証を済ませ、メールアドレスをHTTPヘッダーに載せてOpen WebUIへ渡す「信頼ヘッダー認証」が選べます。WEBUI_AUTH_TRUSTED_EMAIL_HEADER にメールを含むヘッダー名を設定し、任意で WEBUI_AUTH_TRUSTED_NAME_HEADER（表示名）と WEBUI_AUTH_TRUSTED_GROUPS_HEADER（グループ）を使います。

公式ドキュメントはこの方式について、「設定を誤ると、任意のユーザーとして認証できてしまう」と警告しています。理由は単純で、Open WebUIはヘッダーの値をそのまま信じるため、プロキシを経由せずにOpen WebUIへ直接アクセスできる人は、好きなメールアドレスをヘッダーに書けば、その人としてログインできるからです。

使う場合の条件は次の3つで、1つでも欠ければローカル認証やOIDCのほうが安全です。

Open WebUIのポートには、リバースプロキシからしか到達できない（ファイアウォールとネットワーク設定で保証する）
プロキシは、クライアントから来た同名のヘッダーを必ず破棄してから、自分の認証結果で上書きする
プロキシの認証基盤が、退職者の失効を含めて社内の名簿と同期している

この方式は「プロキシの設計に全責任を寄せる」構成です。プロキシの運用手順書に、ヘッダーの上書きと到達制限の確認項目を入れてください。

APIキーの扱い

スクリプトや他システムからOpen WebUIを呼ぶときはAPIキーを使います。公式ドキュメントのとおり、APIキーはそのユーザーのロールとグループ権限を継承し、権限は作成時に固定されず毎リクエストで再チェックされます。1アカウントにつき1キーで、新しいキーを作ると前のキーは即座に無効になります。全体の有効・無効は ENABLE_API_KEYS で切り替え、リバースプロキシが Authorization ヘッダーを消費する環境では CUSTOM_API_KEY_HEADER（既定 x-api-key）で別のヘッダー名にできます。

社内での運用ルールは次のとおりです。

統合ごとに専用のアカウント（サービスアカウント）を作り、そのアカウントの権限を最小にする。管理者のキーを共有しない
キーには自動失効がないため、ローテーションの周期を決め、『閉域ローカルLLMの運用手順書』の定期作業に入れる
キーはシークレット管理の仕組みに保存し、設定ファイルやリポジトリに書かない
エンドポイント制限の機能で、統合が使う経路だけに絞る

APIキーの権限が「そのユーザーの権限と同じ」である以上、サービスアカウントを部門グループに入れると、その統合は部門ナレッジを読めます。統合に必要なナレッジだけを read 付与した専用グループを作るのが安全です。

閉域での注意（IdPがクラウドにある場合）

閉域やネットワーク分離の構成でSSOを使うと、一つ矛盾が生じます。Entra IDやGoogle WorkspaceはクラウドのIdPなので、ログインのためにOpen WebUI（正確には利用者のブラウザとOpen WebUIのサーバー）がIdPへ到達する必要があります。

構成	仕組み	向く組織	注意点
IdPへの経路だけ開ける	推論・ナレッジは閉域に置き、IdPのエンドポイントへの通信だけプロキシ経由で許可する	Microsoft 365やGoogle Workspaceを既に使い、閉域の対象が「業務データ」である組織	「完全閉域」ではなくなる。許可する宛先を限定し、稟議と設計書に明記する
LDAPで閉域内に閉じる	社内のLDAPサーバーで認証し、外部への経路を持たない	エアギャップに近い構成、LGWANなど閉域網内で完結させたい組織	公式の例はOpenLDAP。Active Directoryでの動作は公式ページに記載がなく、検証して確かめる。環境変数は初回起動時だけ読まれる
信頼ヘッダー＋社内プロキシ	閉域内の認証プロキシが認証し、ヘッダーで渡す	既に閉域内に認証プロキシがある組織	前述の落とし穴がそのまま当てはまる

どの構成にするかは、『生成AIをオフラインで使う2026』で整理した「閉域の3段階」のどれを選んだかで決まります。完全閉域ならLDAPか社内プロキシ、ネットワーク分離ならIdPへの経路を開ける構成が現実的です。「SSOのために穴を開けた」事実は、閉域を前提にした稟議の条件と矛盾しうるので、設計書に宛先と理由を残してください。

設定チェックリスト

稼働前に、次の項目を確認します。設定名は確認日時点の公式ドキュメントに基づくもので、バージョンで変わることがあります。

まとめ

Open WebUIの認証はSSO/OIDCかLDAPを主にし、ローカル認証は最初の管理者と予備に限定します。退職者が自動で失効する経路を優先します
最初に決めるのは、管理者を情シス専用にすること、DEFAULT_USER_ROLE を pending にすること、サインアップの扱いの3つです
権限は加算型で Deny がありません。「見せない」はグループに権限を付けないことでしか実現できないため、IdP側のグループ設計を加算型に合わせます
ナレッジ・モデル・ツールは既定で非公開です。部門グループにだけ read を付与し、ナレッジを参照するモデルも同じグループに限定し、全社公開は明示的な操作に限ります
信頼ヘッダー認証はプロキシ以外から到達できない構成が条件で、閉域でクラウドIdPを使う場合は許可する宛先を設計書に残します

よくある質問

Q. Open WebUIをEntra ID（Microsoft 365）でログインさせるには何が必要ですか？

Entra IDでアプリを登録し、リダイレクトURIに https://<open-webui>/oauth/microsoft/callback を設定します。Open WebUI側には MICROSOFT_CLIENT_ID、MICROSOFT_CLIENT_TENANT_ID、クライアントシークレットを設定し、ENABLE_OAUTH_SIGNUP を有効にして初回ログインでアカウントを作らせます。トークンの更新が必要なら OAUTH_SCOPES に offline_access を加えます。グループをEntra IDから同期する場合は ENABLE_OAUTH_GROUP_MANAGEMENT と OAUTH_GROUP_CLAIM を設定します。

Q. 認証なしでOpen WebUIを社内に公開しても、LAN内なら安全ではないですか？

安全ではありません。誰が使ったかが分からず、取り込んだ文書が全員に見え、退職者のアカウントも残ります。LAN内であっても DEFAULT_USER_ROLE を pending にして承認を挟み、SSOかLDAPで社内の名簿と同期させてください。また、UIの外で推論エンジンに直接つなげる状態も塞ぐ必要があります。

Q. 部門ごとに見える文書を分けるには、どう設定しますか？

部門グループを作り、部門の文書を部門ごとのナレッジに取り込み、そのナレッジに部門グループだけ read を付与します。ナレッジは既定で非公開なので、公開（ワイルドカード）にしなければ他部門からは見えません。ナレッジを参照するモデルも同じグループに限定し、各グループの共有可否を決めます。利用者が自分で文書を取り込める権限は与えず、取り込みは部門の担当者に限定します。

Q. 「この部門には許可するが、一部の人には許可しない」という設定はできますか？

引き算の形ではできません。Open WebUIの権限は加算型で、複数グループに属する人は権限の和集合を持ち、Deny がありません。許可しない人を別のグループに分け、そのグループには権限を付けないことで実現します。IdPのグループ設計をこの前提に合わせてください。

Q. 信頼ヘッダー認証はどんな場合に使えますか？

既に社内SSOのリバースプロキシがあり、Open WebUIのポートにプロキシ以外から到達できないことを保証できる場合だけです。公式ドキュメントは「設定を誤ると任意のユーザーとして認証できてしまう」と警告しています。プロキシがクライアント由来の同名ヘッダーを破棄して上書きすること、到達制限、プロキシの認証基盤が名簿と同期していることの3条件が揃わなければ、OIDCかLDAPを選んでください。

Q. 閉域の構成でもSSOは使えますか？

IdPがクラウド（Entra IDやGoogle Workspace）なら、IdPへの経路だけを開ける必要があり、完全閉域ではなくなります。許可する宛先を限定して設計書に明記します。完全閉域で完結させたい場合は、社内のLDAPサーバーで認証する構成か、閉域内の認証プロキシと信頼ヘッダー認証を使う構成になります。LDAPの公式の例はOpenLDAPで、Active Directoryでの動作は検証して確かめてください。

主な参考資料: Open WebUI Docs: Authentication & Access、SSO / OIDC、Roles、Groups、Permissions、LDAP、API Keys（いずれも2026年10月3日確認）、Open WebUIの脆弱性CVE-2025-64496（Cato Networks）

TodoONadaでは、ローカルLLMの導入支援の中で、Open WebUIの認証・権限設計を社内の認証基盤（Entra ID、Google Workspace、LDAP）と接続する形で行っています。機材を買う前に、DGX SparkやMacを貴社オフィスに設置して2週間で「置けるか」を判定する社内設置の実現性検証（30万円〜・税別・機材貸出料込み）では、情報システム部門との調整に使う構成図と接続範囲の説明資料も作成します。「部門ごとに見える文書を分けたい」「既存のSSOにつなぎたい」といった設計段階のご相談も歓迎します。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。