61
第6章
認証
6.0 はじめに
NGINXはクライアントを認証できます。NGINXを使用したクライアントの認証は作
業を減らし、アプリケーションサーバーに認証されていない要求が到達するのを停止
する能力を提供します。NGINXオープンソースで 利 用 できるモ ジュール には 基 本 的な
認証と認証サブリクエストが含まれます。JSON Web Token（JWT）を 検 証 す る た め の
NGINX Plus専 用 モ ジ ュ ー ル に よ り 、認 証 標 準 の OpenID Connectを使 用するサード
パーティの認証プロバイダーとの統合が可能になります。
6.1 HTTP Basic認証
問題
HTTP Basic認証を介して、アプリケーションまたはコンテンツを保護する必要があり
ます。
解決法
次の形式でファイルを生成し、パスワードは、許可されている形式のいずれかで暗号
化 また は ハッシュするようにします：
# comment
name1:password1
name2:password2:comment
name3:password3
ユ ー ザ ー 名 は 最 初 の フ ィ ー ル ド 、パ ス ワ ー ド は 2番 目 の フ ィ ー ル ド 、区 切 り 文 字 は コ ロ ン
で す 。オ プ シ ョ ン の 3番目のフィールドがあり、ここは各ユーザーへのコメントとして使
用できます。NGINXは、複数の異なる形式のパスワードを理解できます。そのうちの1
つ は 、パ ス ワ ー ド が C言語の関数crypt()で 暗 号 化 さ れ て い る か ど う か で す 。こ の 関 数
62
は、openssl passwdコマンドによってコマンドラインに公開されます。代 わりにopenssl
を使 用すると、以下のコマンドで暗号化されたパスワード文字 列を作成できます：
$ openssl passwd MyPassword1234
出力は、NGINXがパスワードファイル内で使用できる文字列になります。
auth_basicおよびauth_basic_user_fileディレクティブ をNGINX 構 成 の 中 で 使 用して
Basic認 証を有 効 にします：
location / {
auth_basic "Private site";
auth_basic_user_file conf.d/passwd;
}
HTTP、サーバー、またはロケーションコンテキストでauth_basicディレクティブ を使
用することができます。auth_basicディレクティブは 文字 列 パラメータを取ります。こ
れは、認証されていないユーザーが到達したときにBasic認 証ポップ アップ ウィンドウ
に表 示されます。auth_basic_user_fileはユーザーファイルへのパスを指定します。
構 成をテストするた めに 、curlと-uまたは--userを 使 用して 要 求 に Authorizationヘッ
ダーを構 築します。
$ curl --user myuser:MyPassword1234 https://localhost
解説
ベーシック認証パスワードは、セキュリティのレベルを変更し、いくつかの方法と異な
る形 式で 生 成 できます。Apacheからのhtpasswdコマンドもパスワードを生成できま
す。opensslおよびhtpasswdコマンドのどちらもNGINXが理解できるapr1アルゴリズム
のパスワードを生成できます。パスワードはLightweight Directory Access Protocol (LDAP)
や Dovecotが使用するSalted SHA-1形 式も使 用 可 能です。NGINXは多数の 形式とハッ
シュアルゴリズムをサポートしています。しかし、ブルートフォース攻撃によって簡単に侵
害される可能性があるため、それらの多くは安全でないと見なされます。
Basic認 証を 使 用して、NGINXホスト全体、特定の仮想サーバー、または特定のロケー
ションブロックのコンテキストを保 護 できます。Basic認証は、Webアプリケーション
のユーザー認証に取って代わるものではありませんが、個人情報を安全に保つのに
役立ちます。あまり知られていませんが、ベーシック認証はサーバーが応答ヘッダー
WWW-Authenticateを含む401の認証資格不足のHTTPコードを返すことによって 行 わ
れ ま す 。こ の ヘ ッ ダ ー に は Basic realm="your string"の値があります。この応答によ
り、ブラウザはユーザー名とパスワードの入 力を求めます。ユーザー名とパスワード
は連結され、コロンで区切られ、base64でエンコードされてから、Authorizationとい
う名前の 要求ヘッダーで 送 信 されます。Authorization要求ヘッダーは 、Basicおよび
user:passwordでエンコードされた文字列を指定します。サーバーはヘッダーをデコー
ド し 、提 供 さ れ た auth_basic_user_fileに 対 して 照 合 し ま す。ユ ー ザ ー 名 と パ ス ワ ー ド
| 第6章：認 証
63
の文字列はbase64でエンコードされているだけなので、Basic認証ではHTTPSを使用
することをお 勧 めします。
6.2 認 証 サブリクエスト
問題
要求の認証を希望するサードパーティの認証システムがあります。
解決法
http_auth_request_moduleを使用して認証サービスに要求に応える前にIDを検証す
るよう要 求します。
location /private/ {
auth_request /auth;
auth_request_set $auth_status $upstream_status;
}
location = /auth {
internal;
proxy_pass http://auth-server;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
}
auth_requestディレクティブ は URIパラメータを取ります。このパラメータはローカル
の内部ロケーションでなければなりません。auth_request_setディレクティブ は 認 証
サブリクエストから変数を設定することを許可します。
解説
http_auth_request_moduleはNGINXサーバーが処理するすべての要求で認証を有効に
します。モジュールは サブリクエストを 使 用して、リクエストの 続 行 が 許可されているか
ど う か を 判 断 し ま す 。サ ブ リ ク エ ス ト と は 、 NGINXが要求を別の内部ロケーションに渡
し、要求を宛先にルーティングする前にその応答を観測する時です。authロケーション
は本文とヘッダーを含め元の要求を認証サーバーに渡します。サブリクエストのHTTP
ステータスコードは、アクセスが許可されるかどうかを決定するものです。サブリクエ
ストが HTTP200ステータスコードで返される場合、認証は成功し、要求は実行されま
す 。サ ブ リ ク エ ス ト が HTTP 401または403を返す時、同じものが元の要求に返されます。
認証サーバーが要求本文を求めない場合、例示のとおり、proxy_pass_request_body
ディレクティブで要求本文を削除できます。この行動により要求のサイズと時間が削
減されます。応答本文は破棄されるため、Content-Lengthヘッダーは空の文字列に設
定する必要があります。認証サービスが要求で指定しているURIを知る必要がある場
6.2 認 証 サブリクエ スト |
64
合は、認証サービスがチェックおよび検証するカスタムヘッダーにその値を記す必要
があります。応答ヘッダーやその他の情報など、サブリクエストから認証サービスまで
保持したいものがある場合は、auth_request_setデ ィレ ク テ ィ ブ を 使 用 して 、応 答
データから新しい変数を作成できます。
6.3 NGINX PlusでのJWTの照合
問題
要求がNGINX Plusに処理される前にJWTを照 合する必 要があります。
解決法
NGINX PlusのHTTP JWT 認 証モジュールを使 用して、トークンの署名を照合し、JWT
クレームとヘッダーをNGINX変 数として 埋 め 込 みます。
location /api/ {
auth_jwt "api";
auth_jwt_key_file conf/keys.json;
}
この構成はこのロケーションのJWTの照合を有効 にします。auth_jwt ディレ クティブ
には、認証レルムとして使用される文字列が渡されます。auth_jwtは、JWTを保持する
変 数のオプションのトークンパラメータを取ります。デフォルトでは 、Authenticationヘ
ッダーがJWTで 使 用されます。auth_jwtディレクティブ は 継 承された構 成 から 必 要な
JWT認証の効果を相殺するためにも使用されます。認証をoffに す る に は 、キ ー ワ ー ド
だけを auth_jwt ディレクティブに渡します。継承された認証要件を相殺するには、off
キーワードだけをauth_jwtディレクティブに 渡します。auth_jwt_key_fileは単一のパ
ラメータを取ります。このパラメータは 、標 準のJSON Web Key (JWK) 形 式 の キ ーファ
イル へのパスです
解説
NGINX Plusは 、ト ー ク ン 全 体 が 暗 号 化 さ れ る JSON Web暗 号 化タイプ ではなく、JSONWeb
署 名タイプのトークンを照合できます。NGINX Plusは、HS256、RS256、お よ び ES256ア
ルゴリズムで署名された署名を照合できます。NGINX Plusにトー クンを照 合させること
で、認証サービスへのサブリクエストを行うために必要な時間とリソースを節約できま
す。NGINX Plusは、JWTヘッダーとペイロードを解 読し 、標 準の ヘッダーとクレームを
埋め込み変数にキャプチャして使用できるようにします。auth_jwtディレクティブ は
http、server、location、limit_except コンテキストで 使 用できます。
| 第6章：認 証
65
関連項目
JSON Web署名のRFC標 準ドキュメンテーション
JSON WebアルゴリズムのRFC標準ドキュメンテーション
JSON WebトークンのRFC標準ドキュメンテーション
NGINX Plus JWT認証
詳細NGINX ブログ
6.4 JSON Web Keyの作成
問題
NGINX Plusが使用するJSON Web Key（JWK）が 必 要 で す 。
解決法
NGINX Plusは、RFC標準で指定されているJWK形式を利用します。この標準では、JWK
ファイル 内の キ ーオブジェクトの 配 列 が 許 可されています。
以下は、キーファイルがどういった見かけかを示す例です：
{"keys":
[
{
"kty":"oct",
"kid":"0001",
"k":"OctetSequenceKeyValue"
},
{
"kty":"EC",
"kid":"0002"
"crv":"P-256",
"x": "XCoordinateValue",
"y": "YCoordinateValue",
"d": "PrivateExponent",
"use": "sig"
},
{
"kty":"RSA",
"kid":"0003"
"n": "Modulus",
"e": "Exponent",
"d": "PrivateExponent"
}
]
}
6.4 JSON Web Keyの作成 |
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.