認可モジュール(権限管理)だけ追加したい〜認証情報を管理したくない〜

2026年01月14日 水曜日


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

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

「認可モジュール(権限管理)だけ追加したい〜認証情報を管理したくない〜」のイメージ

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

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

ここではnginxのBASIC認証に後から認可処理を追加したい方に、ngx_auth_modの新機能の用途を解説します。

サイトの認証処理として認証(誰かを確認する)のみしかしない場合、結果的に「全部許可」と「全部禁止」の二択になってしまいます。

認証のみのイメージ

もちろん、コンテンツ側(アプリ側)で認可処理(誰に許可するか)が行えれば、それほど問題にはなりません。ですが、静的コンテンツなどのようにコンテンツ側へ認可処理が無いこともあります。そのような場合、サイト側のBASIC認証で認可処理も行えると便利です。

認可分離のイメージ

新規の認証システムに入れ替えるのは影響が大きいので、できれば認可処理だけ追加したいところです。
そして、ngx_rewrite_and_authを使えば、以下の図のように既存の認証に認可処理(権限管理)を追加できます。

認可のモジュールを追加するイメージ

つまり、ngx_rewrite_and_authを間に差し込むことで、影響が少ない形で認可を後から追加できるようになります。


設定手順の概要

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

ngx_rewrite_and_authを利用して、権限管理するためにngx_header_path_authを追加で利用する設定例を、以下の順で説明します。

  1. 認証モジュールを準備する
  2. nginxでアカウント名での認証をテストする
  3. 認可モジュールとしてngx_header_path_authを準備する
  4. ngx_rewrite_and_authを設定する
  5. nginxで利用する

この後の説明では、以下の構成を想定して説明します。利用する環境に合わせて、適宜読み替えてください。

認証と認可のモジュールを組み合わせた構成図

0. 認証モジュールを準備する

構成図0

http://127.0.0.1:9200でアカウント用の認証モジュールがすでにある事を前提にしています。もし、認証モジュールがない場合は別途準備してください。
BASIC認証のサイトがあれば、隣のサイトへ認証を丸投げ〜認証を管理したくない〜の記事の方法で、認証モジュールとして流用も可能です。

1. アカウント名での認証をテストする

構成図1

動作確認用に、nginxに以下のような既存の認証(http://127.0.0.1:9200)を使う設定をします。

...

location = /auth {
    auth_request off;
    proxy_intercept_errors off;
    proxy_cache off;

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

    ...

    internal;
}

location / {
    auth_request /auth;
    proxy_cache off;

    ...
}

...

アカウント名での認証が動作することを確認してください。この状態では、認証のみの動作で、認可による制限がありません。

2. 認可モジュールとしてngx_header_path_authを準備する

構成図2

お好きな認可モジュールを利用して良いのですが、ここでは、ngx_header_path_authでの設定例を紹介します。

ngx_header_path_authに、以下のような設定すると一階層目のパス単位で権限設定できるようになります。(例えば、/mgr//test/などで権限が設定できます。)

socket_type = "tcp"
socket_path = "127.0.0.1:9201"
cache_seconds = 15
neg_cache_seconds = 2
use_etag = true

path_header = "X-Authz-Path"
user_header = "X-Forwarded-User"

[authz]
user_map_config = "/etc/ngx_auth_mod/usermap_config.conf"
user_map = "/etc/ngx_auth_mod/usermap.conf"

path_pattern = "^/([^/]+)/"
nomatch_right = "*"
default_right = "@admin"

[authz.path_right]
"mgr" = "@mgr"
"grp-a" = "@grp-a"
"grp-b" = "@grp-b"

認可条件は、設定例の中の[authz]部分で設定されています。この[authz]部分だけ抜粋して説明します。(詳細はngx_header_path_authドキュメントを参照)

パラメータ名 用途
path_pattern user_headerで指定したヘッダー(X-Authz-Path)から一階層目のパスを取り出す正規表現
nomatch_right パスがpath_patternにマッチしなかった場合の権限(*は全ユーザに許可)
default_right パスがpath_patternにマッチした場合のデフォルト権限(adminグループへ許可)
[authz.path_right] path_patternでマッチしたパスへの個別の権限の設定

[authz.path_right]の内容は以下のようになっています。

一階層目のパス 権限の内容
/mgr/ mgrグループへ許可
/grp-a/ grp-aグループへ許可
/grp-b/ grp-bグループへ許可

2.1 user_mapパラメータ(認可グループの設定)

user_mapパラメータに指定したファイル(/etc/ngx_auth_mod/usermap.conf)へ、以下のように記述して各アカウントが所属するグループを定義します。

user1:grp-a mgr admin
user2:grp-a
user3:grp-a
user4:grp-b mgr
user5:grp-b

この例で、user1grp-amgradminの3グループに属しています。

2.2 user_map_configパラメータ(アカウント名とグループ名の書式)

user_map_configに指定したファイル(/etc/ngx_auth_mod/usermap_config.conf)へ以下のように記述し、アカウントとグループの書式を正規表現で指定します。

user_regex = '^[a-z_][0-9a-z_\-]{0,32}$'
group_regex = '^[a-z_][0-9a-z_\-]{0,32}$'

3. ngx_rewrite_and_authを設定する

構成図3

認可モジュールが設定できたら、認証モジュールと認可モジュールを組み合わせて呼び出すngx_rewrite_and_authを設定します。
以下が、そのngx_rewrite_and_authの設定例です。

socket_type = "tcp"
socket_path = "127.0.0.1:9300"
cache_seconds = 15
neg_cache_seconds = 2
use_etag = true
auth_realm = "Mix Authentication"

[[and]]
#username_re = '^(hoge|fuga)$' # 必要に応じて受け入れるアカウント名を制限
auth_url = "http://127.0.0.1:9200"
set_username = "$u" # $uには受け取ったアカウント名が設定される
set_password = "$p" # $pには受け取ったパスワードが設定される
timeout = 3000

[[and]]
#username_re = '^(hoge|fuga)$' # 必要に応じて受け入れるアカウント名を制限
auth_url = "http://127.0.0.1:9201"
set_username = "$u"
set_password = "" # 認可モジュールにはパスワードを渡さない
timeout = 3000

[and.set_header]
"X-Forwarded-User" = "$u"
"X-Authz-Path" = "$h{X-Authz-Path}"

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

パラメータ名 概要
socket_typesocket_path TCPソケットの127.0.0.1:9300で機能を提供
cache_seconds 認証成功時のキャッシュ期間(15秒)
neg_cache_seconds 認証失敗結果のキャッシュ期間(2秒)
use_etag ETagおよびIf-None-Matchヘッダーを使った検証を有効化(nginxがHTTPキャッシュの検証で利用)
auth_realm BASIC認証の認証領域名(“Mix Authentication”)
[[and]]username_re この例では未指定だが、受け入れるアカウント名を制限する時は設定する
[[and]]auth_url 認証モジュールおよび認可モジュールのURL
[[and]]set_username リクエストから受け取ったアカウント名($u)をそのまま渡す
[[and]]set_password 認可モジュールにはパスワードを渡さず、認証モジュールだけにリクエストから受け取ったパスワード($p)を渡す
[and.set_header] ngx_header_path_authにX-Forwarded-Userヘッダーでユーザー名を、X-Authz-Pathヘッダーでパス情報を渡す

[[and]]部分のパラメータは、組み合わせる認証モジュールの数だけ記述する必要があります。

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

4. nginxで利用する

構成図4

認証および認可のモジュールが起動したら、認証用モジュールのURL(proxy_pass)を変更し、認可モジュールが利用するヘッダー(X-Authz-Path)も追加します。

    ...

    location = /auth {
        auth_request off;
        proxy_intercept_errors off;
        proxy_cache off;

        proxy_pass http://127.0.0.1:9300; # 変更部分
        proxy_http_version 1.1;
        proxy_set_header X-Authz-Path $request_uri; # 追加部分
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";

        ...

        internal;
    }

    location / {
        auth_request /auth;
        proxy_cache off;

        ...
    }

    ...

nginxと認証および認可モジュールを再起動した後、認証処理と認可処理が正しく動作することを確認してください。


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

認可処理をカスタマイズして、より良い認証ライフを!

ヒラマツ

2026年01月14日 水曜日

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

Related
関連記事