takaです。
前回はOpenIGとOpenAMを連携させるためのエージェントアプリケーションをインストールしました。
今回はいよいよ、OpenIGとOpenAMの連携動作を確認します。
検証作業は、以下の環境で実施しています。
（同一ハードウェア上で複数サーバを起動しています）
OS ：Ubuntu 12.04 LTS
CPU：Intel Celeron 2.20GHz
MEM：2GB
検証サーバ： www.example.com (192.168.0.10)
アプリケーションサーバ（Apache2＋PHP：ポート80）
OpenIGサーバ（Tomcat6：ポート8080）
OpenAMサーバ（Tomcat6：ポート18080）
1. OpenIGのconfig.jsonを編集
OpenIGの設定を変更して、OpenAMから送信されたログイン情報を代理認証に使うようにします。
第6回で使った config.json を元に内容を変更します。
変更のポイントは、CryptoHeaderFilterを使ってOpenAMから送信されたログインパスワードを復号化する箇所です。
keyの値には、第9回の 2-6 で取得した復号化キーをセットします。
{
"name": "CryptoHeaderFilter",
"type": "CryptoHeaderFilter",
"config": {
"messageType":"REQUEST",
"operation":"DECRYPT",
"algorithm":"DES/ECB/NoPadding",
"key":"xxxxxxxxxxxx",
"keyType":"DES",
"charSet":"utf-8",
"headers": ["password"],
}
},
また、LoginRequestFilterのクレデンシャル（ログイン情報）はヘッダーから取得するようになっています。
参考までに、OpenAM連携用のconfig.jsonを全文掲載しておきます。
{
"heap": {
"objects": [
{
"name": "HandlerServlet",
"type": "HandlerServlet",
"config": {
"handler": "DispatchHandler",
"baseURI": "http://192.168.0.10:80"
}
},
{
"name": "DispatchHandler",
"type": "DispatchHandler",
"config": {
"bindings": [
{
"condition": "${exchange.request.uri.path == '/sample/login.php'}",
"handler": "LoginChain",
},
{
"handler": "ClientHandler",
}
]
}
},
{
"name": "CryptoHeaderFilter",
"type": "CryptoHeaderFilter",
"config": {
"messageType":"REQUEST",
"operation":"DECRYPT",
"algorithm":"DES/ECB/NoPadding",
"key":"xxxxxxxxxxxx",
"keyType":"DES",
"charSet":"utf-8",
"headers": ["password"],
}
},
{
"name": "LoginChain",
"type": "Chain",
"config": {
"filters": ["CryptoHeaderFilter","LoginRequestFilter"],
"handler": "ClientHandler"
}
},
{
"name": "LoginRequestFilter",
"type": "StaticRequestFilter",
"config": {
"method": "POST",
"uri": "http://192.168.0.10:80/sample/login.php",
"form": {
"userid": ["${exchange.request.headers['username'][0]}"],
"password": ["${exchange.request.headers['password'][0]}"],
"action": ["login"]
}
}
},
{
"name": "ClientHandler",
"type": "ClientHandler",
"config": {
}
}
]
},
"servletObject": "HandlerServlet",
}
2. 連携動作の検証
連携動作を確認する前に、OpenIGが稼働するWebアプリケーションコンテナを再起動します。
再起動後、Webブラウザでターゲットアプリケーションを閲覧します。
※簡易認証アプリの場合、http://www.example.com:8080/sample/admin.php を開きます。
正常であれば、ターゲットアプリケーションからOpenAMのログイン画面にリダイレクトされます。
OpenAMのログイン画面で、登録済みのアカウントを使ってログインすると、ターゲットアプリケーションにログイン済みの状態でリダイレクトされます。
もしも正常に動作しない場合、いくつかの切り分けポイントがあります。
ターゲットアプリケーションからOpenAMにリダイレクトされない場合、エージェントをインストールする際の設定に誤りがあるかもしれません。
エージェントをインストールしたディレクトリ（Agent_000というディレクトリが生成されます）にログが出力されますので、参考になるかと思います。
エージェントのログにエラーがなければ、OpenAM側のエージェント設定が原因かもしれません。
OpenAMからターゲットアプリケーションにリダイレクトされない場合、OpenAM側かOpenIG側かの切り分けが必要です。
OpenAMが稼働するWebアプリケーションコンテナのログファイルを確認します。
また、OpenAM管理画面でのエージェント設定内容を再度見直してみましょう。
OpenAM側で問題がなさそうな場合、OpenIGのキャプチャーログ（第4回を参照）を取得して、アカウント情報が正常にPOSTされているかを確認します。
これでOpenIGとOpenAMの連携が確認できました。
実際の運用では複数アプリケーションに対して連携することで、シングルサインオン（SSO）が実現できます。
また、簡易認証アプリでは実装していませんが、ログアウト機能によってシングルサインアウトも可能となります。
複数のアプリケーションを使って、シングルサインオン、シングルサインアウトのテストもできると思います。
（ひとまず）終わりに
11回にわたってOpenIGの勉強をしてきましたが、いかがだったでしょうか。
少しでも、皆様の参考となっていれば幸いです。
ForgeRock社のドキュメントでは、どちらかというとエージェントの利用が推奨されているように書かれています。
エージェントはOpenAMで集中管理できますし、ターゲットアプリケーションと同一サーバ上で稼働することができます。
OpenIGは、ターゲットアプリケーションと（原則的には）別サーバですし、設定はローカル管理なので煩雑になるというデメリットがあります。
リバースプロキシですから、ボトルネックとなるリスクも伴います。
とはいえ、SAMLなどフェデレーション機能を持たない「レガシー」なアプリケーションがまだまだ存在する中で、OpenIGを導入するメリットはあると考えております。
代理認証はエージェントだけで実装することができませんので、OpenIG＋エージェントの組み合わせをうまく活用して既存の「レガシー」アプリも含めた、シングルサインオン環境の構築にチャレンジしてみてはいかがでしょうか。
ForgeRock社のコミュニティでは非常に活発なやりとりが行われていますので、わからないことがあれば積極的に活用してみてください。
（参考サイト）
ForgeRock社のOpenIGドキュメントを参考にさせていただきました。