NGINXでの認可について考える

© Hitachi, Ltd. 2023. All rights reserved.
NGINXでの認可について考える
NGINXユーザーカンファレンス 2023 春
株式会社日立製作所 OSSソリューションセンタ
岡井倫人

1
自己紹介
• 認証認可のテクニカルサポートに従事
 NGINXをAPIゲートウェイやリバースプロキシとして使用する案件にも従事
• IAMのOSSであるKeycloakのコントリビュータ
 デバイスフロー[RFC 8626]をコミット
 ユースケースに応じたトークン周りの仕様改善
 性能向上
• Financial-grade API(FAPI)に精通
 FAPIに準拠したクライアントを開発・Certification取得
https://github.com/Hitachi/hitachi-fapi-java
 FAPIの記事を執筆
https://thinkit.co.jp/series/10313
岡井倫人
 ソフトウェアエンジニア
 日立製作所
 GitHub: @Michito-Okai

Contents
2
1. NGINXにおける認可とは
2. NGINXにおける認可の実現パターン
3. 認可をNGINXで実現する際のTips

Contents
3

4
そもそも認可とは
• しばしば認可は認証とセットで説明される。
• 認証: アクセスしてきたユーザ(クライアント)が誰(何)かを確認すること。
• 認可: アクセス先のリソースにアクセス可能かを確認すること。
※英語では、認証 = Authentication (authN)、認可 = Authorization (authZ)
認証・認可がOKだったら
リソースを返す。
アクセス
リソースサーバ
クライアント

5
本セッションでターゲットとする認可
• ここではNGINXをリソースサーバとして使用したときのAPI認可について考える。
• リソースサーバは、API提供機能に加えて、以下のような基本機能を備えることが一般的。
• OAuth 2.0に準拠したAPI認可
• XSSやSQLインジェクションなどのOWASP Top 101対策
• 流量制御
• API仕様の公開
APIコールの認証・認可がOK
だったらリソースを返す。
APIコール
リソースサーバ(NGINX)
クライアント
1 https://owasp.org/www-project-top-ten/

6
 NGINX App Protect
 豊富なモジュール群
 njs/Luaによるカスタマイズ
NGINXで実現するAPI認可
• リソースサーバをNGINXで構築するメリットは、以下の通り。
• 安定したパフォーマンス(low tail latency)
• NGINX App Protectの付加により、容易にWAF機能を導入可(OWASP Top 10対策)
※API仕様に従ったAPI固有のアクセス制御もできる
• 基本機能を実現するための豊富なモジュール群
• njs1やLua2でカスタマイズすることにより、案件個別機能にも柔軟に対応できる
APIコール
クライアント
1 NGINXの機能を拡張できるJavaScript言語のサブセット
2 スクリプト言語

Contents
7

8
API認可の流れ
• API認可では、クライアントは、OAuth 2.0の認可フレームワークを使用して発行したアクセストークンを
付与してAPIをコールする。
• リソースサーバは、アクセストークンを用いて、まずAPIコールを認証する。
• APIコールの認可には、アクセストークンに付随する情報(JWTのクレームなど)を用いるのが一般的。
4. APIコール w/ アクセストークン
2. エンドユーザの認証・同意取得
3. トークンの発行
認可サーバ
エンドユーザ
(サービス利用者)
使用
クライアント
1. エンドユーザの
認証・認可の委譲
アクセストークンを用いて、
APIコールの認証・認可を
行う。
APIを利用する
アプリケーション。
エンドユーザの
認証・認可を行う。

9
認可の実現パターン①: オールインワンパターン
• 一番シンプルな認可の実現パターン。
• NGINXでACL (Access Control List)のようなマッピング情報を持ち、そのマッピング情報を用いて
APIコールの全ての認可判断をNGINXが行う。
4. APIコール(GET /profile) w/ アクセストークン
認可サーバ
エンドユーザ
使用
クライアント
自身が保持するマッピング情報
をもとに、アクセストークンに
read_profileスコープがあるか
を確認する。
エンドユーザのプロフィール
を取得したい！
<<マッピング情報>>
• GET /profileには、
read_profileスコープ
が必要

10
認可の実現パターン①: オールインワンパターン
• このパターンの課題はスケーラビリティ(柔軟性)。
• リソースサーバ(API)が増えるごとに、管理対象のマッピング情報が増える。
• スコープやロール、属性といった認可判断のベースとなる情報が増えるたびに、各マッピング情報で
その情報を再定義する必要がある。
認可サーバ
エンドユーザ
使用
クライアント
リソースサーバA(NGINX)
リソースサーバB(NGINX)
新しいスコープやロールに対する
認可ロジックを個別に追加。
新しいスコープやロールに対する
認可ロジックを個別に追加。

11
認可の実現パターン②: 認可判断を委譲するパターン
• オールインワンパターンの課題であったスケーラビリティを認可判断を委譲することで解決するパターン。
• ABACを用いて、認可判断委譲を行う。
クライアント
リソース
PEP
PDP
PIP
PAP
ポリシー
1. APIコール
2. 認可判断の委譲
3. ポリシーの評価
3’. 認可に必要な情報の取得
ポリシーの管理
4. リソースへアクセス
Policy Administration Point
ポリシーを管理する(UI)
Policy Information Point
認可判断に必要な情報を提供する
Policy Decision Point
ポリシーを評価し、認可の決定を下す
ABAC (属性ベースのアクセス制御)とは、一般的にポリシーを使って認可ロジックを定義する。
ABACには中央集権型と分散型の2つの実現パターンが存在する。
また、以下のような役割を持つコンポーネントが存在する。
Policy Enforcement Point
リソースへの接続を有効にしたり、監視したり、終了する

12
認可の実現パターン②-1: 認可判断を委譲する(中央集権型)パターン
• PDP(認可判断の役割)を他のサービスに委譲するパターン。
• リソースサーバは認可判断に使われる情報を意識することなく、PDPからの情報だけをもとに認可を
実行できる。
• Keycloakの認可サービスなど、PDP機能を提供する認可サーバを利用すると、認可用の情報を一元管理
できる。
認可サーバ(Keycloak)
エンドユーザ
使用
クライアント
PDP PIP PAP
PEP
PEP

13
主な特徴
 OAuth 2.0/OpenID Connect、SAMLやFAPI
に対応
 LDAPサーバやActive Directoryと連携可能
 GitHubなどのユーザアカウントを利用した
ソーシャルログインに対応
 PDPとして機能する認可サービスを提供
Keycloakとは
• Keycloakは、IAM (Identity and Access Management: IDアクセス管理)のOSS。
• OAuth 2.0の認可サーバの機能やシングルサインオンの機能を提供。
主要標準に準拠した認証・認可
Keycloak
LDAP
Active
Directory
RDB
OpenID Connect SAML
GitHub
Twitter Facebook
ID管理
ソーシャルログイン
(Identity Brokering)

14
認可の実現パターン②-1: 認可判断を委譲する(中央集権型)パターン
• このパターンの課題は可用性。
• 良くも悪くもPDPにアクセスが集中し、PDPがSPOFとなる。
• PDPへの通信遅延およびPDP自体の性能の影響を受けて、パフォーマンスが劣化する可能性もある。
エンドユーザ
使用
クライアント
PDP PIP PAP
PEP
PEP
負荷が集中！

15
認可の実現パターン②-2: 認可判断を委譲する(分散型)パターン
• PDPを各リソースサーバ(エッジ)に分散させるパターン。
• OPA (Open Policy Agent)など、PDP機能を提供するサービスをサイドカーとしてデプロイし、リソースサー
バは自身のサイドカーのPDPに認可判断を委譲する。
• 認可サーバがPIPとなるため、負荷の一点集中を避けることができる。
エンドユーザ
使用
クライアント
PIP
PEP
PEP
OPA
5. 認可判断の委譲 OPA
6. 認可に必要な
情報の取得
PDP
PDP

16
認可の実現パターン②-2: 認可判断を委譲する(分散型)パターン
• このパターンの課題はアーキテクチャの複雑性。
• サイドカーパターンの実装が必要になる。
• PDP専用のコンポーネントが増えた分、管理コストが増える。
• 可用性が向上した分、発生する障害によっては一貫性が損なわれる可能性がある。
エンドユーザ
使用
クライアント
PIP
PEP
PEP
OPA
5. 認可判断の委譲 OPA
6. 認可に必要な
情報の取得
PDP
PDP
障害によって取得情報に
差分が生じると認可判断の
一貫性が損なわれる。

17
NGINXにおける認可の実現パターンまとめ
• 3つの認可の実現パターンの特徴をまとめると以下の通り。
実現パターンスケーラビリ
ティ(柔軟性)
パフォーマンス可用性一貫性シンプルな
アーキテクチャ
適用ユースケース
オールインワ
ンパターン
×
個別に認可用の
情報を定義する
必要がある。
〇
認可処理はロー
カルで完結する。
〇
障害箇所以外の
の業務は継続可
能。
〇
認可用の情報は
ローカルに持つ
ため差分は生じ
ない。
〇
認可サーバとリ
ソースサーバの
みで実現可。
API数が少なく、認可ロ
ジックがシンプルな
ユースケース。
中央集権型パ
ターン
〇
PIPが一元管理
する。
×
PDPへの通信遅
延およびPDP自
体の性能の影響
を受ける。
×
PDPが止まると
すべてのリソー
スサーバが止ま
る。
〇
PDPが持つため
差分は生じない。
〇
認可サーバとリ
ソースサーバの
みで実現可。
スコープやロール、属
性といった複数の情報
を組み合わせた認可ロ
ジックが必要な、中規
模なユースケース。
分散型パター
ン
〇
PIPが一元管理
する。
〇
認可処理はロー
カル(サイドカー
含む)で完結する。
〇
障害箇所以外の
の業務は継続可
能。
×
各PDPが分散し
て持つため差分
が生じる恐れが
ある。
×
サイドカーパ
ターンの実装が
必要。
中央集権型だとPDPと
の通信遅延がパフォー
マンスのボトルネック
となるような大規模な
ユースケース。

18
アドバンストな認可の実現パターンの紹介
• サービス利用者(リソースオーナ)ではない第三者がクライアントを利用するユースケースの実現は、
CIBA (OIDC Client-Initiated Backchannel Authentication Flow) で実現可能！
• さらに、 UMA 2.0 (User-Managed Access 2.0 Grant)によって、
リソースオーナが事前に条件を設定し、認可を管理できる。
CIBA UMA 2.0
認証デバイス経由
でサービス利用者
の認可を取得する。
2. サービス利用者の認証・同意取得
3. トークンの
発行
認可サーバ
(Keycloak)
サービス利用者
(リソースオーナ)
使用
クライアントリソースサーバ
(NGINX)
1.サービス利用者の
コールセンタ
の担当者
電話
認証デバイス
サービス利用者のリソース
にアクセスする。
1. APIコール
認可を与える条件を事前に設定
5. トークンの
発行
認可サーバ
(Keycloak)
リソースへのアクセスを
許可するユーザ
(リソースオーナ)
使用
クライアントリソースサーバ
(NGINX)
4. トークン要求 w/
パーミッションチケット
6. APIコール w/ RPT
3. パーミッションチケット
2. パーミッション
チケットの
要求と発行
事前に設定され
た条件に従って
認可判断する。
クライアント
使用者
リソースオーナのリソース
にアクセスする。

Contents
19

20
NGINXでの認可の実現方法
load_module modules/ngx_http_js_module.so;
http {
js_import oidc from conf.d/openid_connect.js;
location /api/ {
auth_request /auth;
…
}
location = /auth {
internal;
js_content oidc.accessControl;
}
}
• 一般的に、ngx_http_auth_request_module を使う。
• 以下のように設定することで、njsで実装した認可ロジックの結果に応じたアクセス制御を実現できる。
• njsから2xxレスポンスを返す → /api/へのアクセスを許可
• njsから401や403のレスポンスを返す → /api/へのアクセスを拒否

21
auth_requestを使う際の注意事項
• ハマりポイント: POSTリクエストのときに失敗(タイムアウト)することがある。
• 原因: auth_requestの中で、リクエストボディをプロキシしていた。
• 対策: 以下のように、リクエストボディをプロキシしない設定を入れましょう！
http {
location /api/ {
auth_request /auth;
…
}
location = /auth {
proxy_pass …
proxy_pass_request_body off;
proxy_set_header Content-Length “”;
}
}
特に、proxy_passで認可判断
を外部に委譲しているときは注意
が必要。

22
njsを使う際の注意事項
• ハマりポイント: コード実行時にエラーが発生する。
• 原因: 意図しない型変換が行われていた。
• 対策: 型定義チェックを有効化しましょう！
• 使用する型定義ファイル
• TypeScript definitions for njs
https://github.com/nginx/njs/tree/master/ts
• 使用方法
1. njs-typesをインストール
2. jsファイルの先頭に参照パスを追加
3. 関数定義にJSDocを追加
// @ts-check
/// <reference path="./node_modules/njs-types/ngx_http_js_module.d.ts" />
npm install --save-dev njs-types

23
型定義チェックの有効化
• ハマりポイント: コード実行時にエラーが発生する。
• 原因: 意図しない型変換が行われていた。
• 対策: 型定義チェックを有効化しましょう！ → コード実装時にエラーを抽出できる！
returnNumber関数の
引数の型チェック。
returnNumber関数の
返り値の型チェック。
実装時にエラーを抽出！

24
まとめ
 NGINXにおける認可の実現パターンを紹介しました。
 オールインワンパターン → シンプルなユースケースに適用。
 中央集権型パターン → 中規模なユースケースに適用。
 分散型パターン → 大規模なユースケースに適用。
 NGINXとKeycloakを統合して実現するアドバンストな認可を紹介しました。
 CIBA、UMA 2.0
 認可をNGINXで実現する際のTipsを紹介しました。
 auth_requestを使う際の注意事項
 型定義チェックの有効化

25
Trademarks
• OpenID is a trademark or registered trademark of OpenID Foundation in the United States and other
countries.
• GitHub is a trademark or registered trademark of GitHub, Inc. in the United States and other
countries.
• Red Hat is a registered trademark of Red Hat, Inc. in the United States and other countries.
• NGINX and NGINX Plus are registered trademarks of F5, inc. in the United States and other
countries.
• Other brand names and product names used in this material are trademarks, registered trademarks,
or trade names of their respective holders.

NGINXでの認可について考える

NGINXでの認可について考える

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to NGINXでの認可について考える

Similar to NGINXでの認可について考える (20)

More from Hitachi, Ltd. OSS Solution Center.

More from Hitachi, Ltd. OSS Solution Center. (20)

NGINXでの認可について考える