Policy Agentを組み込んだApacheをリバースプロキシにする

今日やること

今日はPolicy Agentを導入したWebサーバーをリバースプロキシにします。リバースプロキシの先には、また別のWebサーバーをセットアップします。

文字で書いてもわかりにくいので、簡単に図を書いてみます。

（かえってわかりにくい...？）
位置関係が分かってもらえればいいかなとおもいます。
ユーザーはOpenAMで認証後、Policy Agentが導入されたProxyにアクセスします。
Proxyは/org/パス以下にアクセスがあると、Originにリバースプロキシするという構成です。

この構成の嬉しいところとしては、以下のような点が挙げられます。

• OriginにPolicy Agentを導入しなくていい
  • 本当はOriginのWebサーバーに導入するものだけど、Originにそのような変更が加えられない場合などに有用です
• たくさんのアプリをリバースプロキシにぶら下げられる
  • リバースプロキシをガチガチに固めて、バックエンドのアプリのかわりにセキュリティの実装をしてあげられる
  • /org1にアクセスされるとOrigin 1、/org2にアクセスされるとOrigin 2...みたいな

準備

SSOのみモードをONに

今回は認可制御は不要なので、SSOのみモードをONにしときましょう。

12月3日の記事を参考に設定しましょう。

Originサーバーの準備

こちらはただのApacheサーバーです。本記事では以下のような構成です。

• OS
  • CentOS 6.8(Vagrant)
• Memory
  • 512MB
• FQDN
  • org.example.com

また、Apacheのコンテンツとして下記コンテンツを配置します。

$ tree /var/www/html/
/var/www/html/
├── img
│   └── openam-alone.jpg
└── index.html

直接、https://org.example.com/index.htmlにアクセスすると以下のような表示がされます。

リバースプロキシの設定

それではPolicy Agentを導入したWebサーバー（Apache）をリバースプロキシに仕立てましょう。ここからの作業は全てWebサーバー上（web.example.com）で行います。

事前にhostsを編集して、Originの名前解決ができるようにしておきましょう。
こんな感じです。

$ sudo diff /etc/hosts{,.org}
3,5d2
< 192.168.33.10 iam.example.com
< 192.168.33.20 web.example.com
< 192.168.33.30 org.example.com

ssl.confの設定

/etc/httpd/conf.d/ssl.confの設定を変更します。

$ sudo diff /etc/httpd/conf.d/ssl.conf{,.org}
222,224d221
< SSLProxyEngine on
< ProxyPass /org https://org.example.com
< ProxyPassReverse /org https://org.example.com

ProxyPassとProxyPassReverseはApacheのリバースプロキシ設定です。適当に言うと、/orgにアクセスされたらhttps://org.example.comにプロキシするっていう設定です \(´ー｀)ﾉ
設定の詳細な内容はApacheのサイトをご参照ください。

• ProxyPassディレクティブ
• ProxyPassReverseディレクティブ

SSLProxyEngineはHTTPSのサイト（今回はhttps://org.example.com）にリバースプロキシする際に必要な設定です。
設定の詳細な内容なApacheのサイトをご参照ください。

• SSLProxyEngine

設定が終わったら、Apacheを再起動します。

$ sudo service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]

確認

それでは、実際にプロキシを行うパス（https://web.example.com/org/）にアクセスしてみましょう。OpenAMのサインインはどのユーザーでも構いません。

先ほど、リバースプロキシを返さずに閲覧した時とは異なり、画像が閲覧できません。
理由はデベロッパーコンソールを見るとわかります。

問題の箇所はリクエストを送ったパスになります。リバースプロキシの設定は**/org以下のアクセスをhttps://org.example.comにプロキシするとなっているので、/img/openam-alone.jpgのリクエストはプロキシされずに404 Not Found**となってしまうのです。

これは、org.example.comが/img/openam-alone.jpgで画像を配信しようとしているために起こる事象であり、今回のような特定のパス以下を別のWebサーバーにプロキシするという構成をとったときに、よくある事象だそうです。

mod_substituteの設定

とはいえ、コンテンツがちゃんと見えないと困ります。そんな悩みを解決するmod_substituteというApacheのモジュールがあります。これを使って、プロキシ先から返却されるコンテンツの書き換えを行うことができます。

たとえば、今回ですとhttps://org.example.com/index.htmlから返却されるコンテンツは、

<img src="../img/openam-alone.jpg" width="384" height="256">

ですが、これを

<img src="/org/img/openam-alone.jpg" width="384" height="256">

という感じで、リバースプロキシ経由でもしっかり見れるように書き換えを行うことができます。

では、先ほどに引き続き、/etc/httpd/conf.d/ssl.confに設定を追加します。

$ sudo diff /etc/httpd/conf.d/ssl.conf{,.org}
222,226d221
< SSLProxyEngine on
< ProxyPass /org https://org.example.com
< ProxyPassReverse /org https://org.example.com
< AddOutputFilterByType SUBSTITUTE t text/html
< Substitute "s|(src=\")(.*)(/img)|$1/org$3|i"

AddOutputFilterByTypeは、Content-Typeがtext/htmlのコンテンツを書き換えるというルール（ルール名Substitute）の定義になります。
実際の書き換えルールはSubstituteからになります。正規表現で書き換えをすることができます。上記の例は、..を/orgに書き換えるという単純なものです。

設定が終わったら、Apacheを再起動します。

$ sudo service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]

今度こそ確認

気を取り直して、再度、プロキシ行うリソース（https://web.example.com/org/）にアクセスしてみましょう。

ばっちりですね。

〆

なんだか、OpenAMと銘打っておきながら、Apacheのリバースプロキシ設定の話になっちゃいましたね。ま、いっか(´◉◞౪◟◉)

まとめとしては、

• Policy Agent導入済みのApacheのmod_proxyを使ってリバースプロキシにできる
• コンテンツがちゃんと表示されないときはmod_substituteをつかって書き換え書き換え～↑↑↑
• 認証済みユーザーの情報もHTTP HEADERとかでOriginに渡せるので、認証の実装の代替にもなりそう

明日は何しようかな～。SAMLにしようかと思ったど、連携先のサービスを用意するのがめんどくさい大変なので、別のことするかも。

ばい！