認証処理を集中管理する〜シングルサインオン(SSO)はしたくない〜

2026年01月14日 水曜日


【この記事を書いた人】
ヒラマツ

セキュリティ本部 セキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい!」とフラグを...。

「認証処理を集中管理する〜シングルサインオン(SSO)はしたくない〜」のイメージ

認証をnginx用にちょっと弄れる機能〜認証だってrewriteしたい〜の続き記事です。

ngx_auth_mod開発者のヒラマツです。

ここではBASIC認証のまま認証処理を集中管理したい方に、ngx_auth_modの新機能の用途を解説します。

セキュリティ事故を防ぐためには、重要情報を共有するサイトに認証システムを導入しないわけには行きません。ですが、やみくもに認証システムをどんどん増やしてしまうと、管理の負荷もどんどん増えて大変なことになります。

認証サイトが増えるイメージ

管理の手間を考えると、認証システムが増えすぎないように集約したいと考えるのも自然な話です。
でも、シングルサインオン(SSO)などの複雑な認証システムを使うのは、別の部分の手間が増えて、本末転倒感があります。
管理の手間だけ考えるなら、単純なBASIC認証のままに認証システムを集約したいところです。

そんな状況向けに、BASIC認証のまま、サイト毎のカスタマイズも許しつつも、肝心の認証処理は管理サーバで集中管理する方法を紹介します。

認証管理が楽になるイメージ

利用サイトは認証処理を管理サイトへ委譲し、認証判断は管理サイトがすべて行う仕組みです。
この仕組みには、以下のようなメリットがあります。

  • 認証処理が管理サイト側で行われるので、利用サイト側のリスクが軽減できる。
  • nginxのキャッシュで、認証サイトの認証DBや認証モジュールの負荷を軽減できる。
  • 負荷が増えても、HTTPSベースなので一般的な方法で管理サイトを増強して、負荷分散できる。
  • プロトコル的にはBASIC認証なので、通信上の問題が起きても一般的なHTTPの知識で調査できる。
  • アクセス制御にnginxの仕組みが流用できる。
  • (ngx_rewrite_authなどを使うことで)利用サイト側でも認証のカスタマイズができる。

サイト毎にカスタマイズする場合、具体的には以下のような構成になります。

管理サーバで認証処理を集中管理する構成

さらに、以下の図のように管理サーバをゲートウェイにすることで、認証DBのネットワーク分離にも使えます。

管理サーバで認証をゲートウェイするイメージ


設定手順の概略

以後はnginxでの具体的な設定を説明します。実際に使用する際に活用してください。

このBASIC認証のまま集中管理する方法を、以下の順で説明します。

  1. 管理サイトの認証モジュールを用意
  2. 管理サイトのアクセス制御をするnginxを用意
  3. 利用サイト向けに認証内容をカスタマイズ
  4. 利用サイトから管理サイトの認証を利用

この後の説明では、以下のような構成を想定して説明します。

管理サーバで集中管理する構成図

利用する環境に合わせて、適宜読み替えてください。

1. 管理サイトの認証モジュールを用意

構成図1

ngx_http_auth_request_module用のアカウント名で認証するモジュールを、http://127.0.0.1:9200で動かします。
ngx_auth_modについては、ngx_auth_modの「はじめに」に基本的な設定方法を書いているので、参考にしてください。

2. 管理サイトのアクセス制御をするnginxを用意

構成図2

nginxに以下のような設定をします。

  • HTTPSでnginxが動作するようにする。
  • 利用サイトからアクセスできるように設定する。
  • 負荷を軽減するために、認証結果キャッシュの設定をする。

以下は、利用サイトから共有するhttps://ngxauth.example.com/authの認証機能を提供する設定の例です。

proxy_cache_path /var/cache/nginx/auth levels=2 keys_zone=zone_auth:1m max_size=1g inactive=1m;
proxy_temp_path  /var/cache/nginx_tmp;

...

server {
    # HTTPSの設定
    listen 443 default ssl;
    server_name ngxauth.example.com;

    ... # 証明書などの一般的なnginxの設定

    location = /auth {
        auth_request off;
        proxy_intercept_errors off;

        # キャッシュ領域の指定
        proxy_cache zone_auth;
        proxy_cache_key $remote_user;

        # キャッシュアクセスを排他制御
        proxy_cache_lock on;

        # キャッシュ検証を有効化
        proxy_http_version 1.1;
        proxy_cache_revalidate on;

        # ヘッダーなどの認証モジュール固有な設定を追加
        # ex.) proxy_set_header X-Forwarded-User $remote_user;

        proxy_set_header Content-Length "";
        proxy_pass_request_body off;
        proxy_pass http://127.0.0.1:9200;

        # 利用サイトからアクセス制御
        allow 192.0.2.5;
        deny all;
    }

    location / {
        # (認証無しで見れる)利用案内などの認証サイトのドキュメント設定
        auth_request off;
        index index.html;

        allow 192.0.2.0/24;
        deny all;
    }

    ...
}

設定後、ブラウザでhttps://ngxauth.example.com/authへアクセスして、BASIC認証が正しく動作したら、管理サイト側の設定は完了です。

3. 利用サイト向けに認証内容をカスタマイズ

構成図3

以下の設定例のように、利用サイトの都合に合わせてキャッシュ期間などの設定をします。

socket_type = "tcp"
socket_path = "127.0.0.1:9200"
cache_seconds = 15
neg_cache_seconds = 2
use_etag = true
auth_realm = "XXX Authentication"

username_re = '.'
auth_url = "https://ngxauth.example.com/auth"
#root_ca_files = [
#        "/var/cats/etc/ca-certs/My-Network-CA.cer",
#]

set_username = "$u" # $uには受け取ったアカウント名が設定される
set_password = "$p" # $pには受け取ったパスワードが設定される

この設定例で利用しているパラメータごとに、設定内容の概要を説明しておきます。パラメータ自体の詳細については、ngx_rewrite_authドキュメントを参照してください。

パラメータ名 概要
socket_typesocket_path TCPソケットの127.0.0.1:9200で機能を提供
cache_seconds 認証成功時のキャッシュ期間(15秒)
neg_cache_seconds 認証失敗結果のキャッシュ期間(2秒)
use_etag ETagおよびIf-None-Matchヘッダーを使った検証を有効化(nginxがHTTPキャッシュの検証で利用)
auth_realm BASIC認証の認証領域名(“XXX Authentication”)
username_re ユーザ名が空でなければ認証先を呼び出す指定
auth_url 認証を委譲するサイトのURL(https://ngxauth.example.com/auth)
root_ca_files 追加のCA証明書を指定(プライベートCAの証明書で利用)
set_username リクエストから受け取ったアカウント名($u)をそのまま渡す
set_password リクエストから受け取ったパスワードをそのまま渡す

ngx_rewrite_authの起動は、ngx_auth_modの他のモジュールと同様でsystemdなどで行います。
具体的な起動方法についてはngx_auth_modの「はじめに」で紹介していますので、そちらを参照してください。

サイト側で認可処理を追加する方法は、認可モジュール(権限管理)だけ追加したい〜認証情報を管理したくない〜で説明しているので、そちらを参照してください。

4. 利用サイトから管理サイトの認証を利用

構成図4

3.で設定したngx_rewrite_authをnginxから利用する設定をします。以下は、利用サイトでも認証結果をキャッシュする設定例です。

proxy_cache_path /var/cache/nginx/auth levels=2 keys_zone=zone_auth:1m max_size=1g inactive=1m;
proxy_temp_path  /var/cache/nginx_tmp;

...

server {
    ...

    location = /auth {
        auth_request off;
        proxy_intercept_errors off;

        proxy_cache zone_auth;
        proxy_cache_key $remote_user;
        proxy_cache_lock on;
        proxy_http_version 1.1;
        proxy_cache_revalidate on;

        proxy_pass http://127.0.0.1:9200;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";

        ...

        internal;
    }

    location / {
        auth_request /auth;
        proxy_cache off;

        ...
    }

    ...
}

...

設定手順の説明は以上です。

認証管理を集約して、少しでも楽な認証管理ライフを!

ヒラマツ

2026年01月14日 水曜日

セキュリティ本部 セキュリティ情報統括室に所属 システム開発者。2000年問題で「2038年問題は定年で対応しなくていい!」とフラグを...。

Related
関連記事