OpenIG自習室(第4回:代理認証の動作)

takaです。

前回はOpenIGによる代理認証を行いました。

前回の設定では、config.json ファイルの中にユーザー名とパスワードを直接記述しています。
実際の運用環境においてそのような設定は行いません(行ってはいけない)ので、もう少し本番に近い形で設定を行ってみます。

が、その前に。
OpenIGが代理認証を行うとき、その裏側ではどのような処理が実施されているのでしょうか。
次のレベルに進む前に、今回は代理認証の裏側を見てみましょう。

検証作業は、以下の環境で実施しています。

OS :Ubuntu 12.04 LTS
CPU:Intel Celeron 2.20GHz
MEM:2GB

アプリケーションサーバ:target.example.com(192.168.0.10)
OpenIGサーバ             :gateway.example.com(192.168.0.20)


1. config.json ファイルの変更

まずは、config.json を変更します。
以下は簡易認証アプリ向けの設定ファイルです。WordPressを使っている場合でも、変更箇所は同じです。

{
    "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": "OutgoingChain",
                        }
                    ]
                }
            },
            {
                "name": "LoginChain",
                "type": "Chain",
                "config": {
                    "filters": ["LoginRequestFilter"],
                    "handler": "OutgoingChain"
                }
            },
            {
                "name": "LoginRequestFilter",
                "type": "StaticRequestFilter",
                "config": {
                    "method": "POST",
                    "uri": "http://192.168.0.10:80/sample/login.php",
                    "form": {
                        "userid": ["foo"],
                        "password": ["bar"],
                        "action": ["login"]
                    }
                }
            }, 
            {
                "name": "OutgoingChain",
                "type": "Chain",
                "config": {
                    "filters": ["CaptureFilter"],
                    "handler": "ClientHandler"
                }
            },
            {   
                "name": "CaptureFilter",
                "type": "CaptureFilter",
                "config": {
                    "captureEntity": true,
                    "file": "/tmp/gateway.log",
                }
            },
            {
                "name": "ClientHandler",
                "type": "ClientHandler",
                "config": {
                }
            }
        ]
    },
    "servletObject": "HandlerServlet",
}

変更箇所ですが、まずは22行目の handler が ClientHandler から OutgoingChain に変わっています。
32行目も同様に ClientHandler が OutgoingChain に変更されています。
そして LoginRequestFilter(35~47行)の下に OutgoingChain(48~55行)と CaptureFilter(56~63行)が追加されています。

設定ファイルの詳しい説明については、ForgeRock社によるWordPressを使ったチュートリアルや、OpenIGのReferenceを参照してください。
ここでは、簡単に動作を見てみます。

ブラウザからのリクエストは、最初に HandlerServlet が受け取り DispatchHandler に送られます。
DispatchHandler は、リクエストのURLに /sample/login.php が含まれていれば LoginChain に、そうでなければ OutgoingChain に処理を引き渡します。
LoginChain は LoginRequestFilter(代理認証)を実行し、OutgoingChain に処理を引き渡します。
OutgoingChaing は CaptureFilter を実行し、ClientHandler に処理を引き渡します。
CaptureFilter は、ブラウザとアプリケーションサーバとの通信内容をログ(ここでは /tmp/gateway.log)に記録します。
captureEntity というパラメータは、trueなら通信内容の全て(ヘッダー情報+HTML)を記録し、falseの場合ヘッダー情報のみを記録します。

この設定ファイルを使って、代理認証を行いましょう。
設定ファイルを変更した後は、OpenIGが稼働するWebアプリケーションコンテナを再起動します。

2. キャプチャーログを見る

ブラウザでターゲットアプリケーションを閲覧し、自動的にログインすることを確認します。
すると、アプリケーションサーバの /tmp に gateway.log というログファイルが生成されているはずです。
このファイルは、ブラウザとアプリケーションサーバとの通信内容をキャプチャーしたログです。
では、このログファイルの中身を見てみましょう。
REQUEST はブラウザからのリクエスト、RESPONSE はサーバからのレスポンスを示します。
なお、以下のログファイルは簡易認証アプリのものです。WordPressを使っている場合とは表示項目等が異なります。

--- REQUEST 1 --->

GET http://192.168.0.10:80/sample/admin.php HTTP/1.1
connection: keep-alive
accept-language: ja,en-us;q=0.7,en;q=0.3
host: target.example.com
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
user-agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0
accept-encoding: gzip, deflate

<--- RESPONSE 1 ---

HTTP/1.1 302 Found
Date: Wed, 31 Jul 2013 06:10:42 GMT
Content-Length: 0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Location: login.php
Set-Cookie: PHPSESSID=xxxx55tk5c8av9aln8tetsxxxx; path=/
Content-Type: text/html
X-Powered-By: PHP/5.5.0
Server: Apache/2.4.4 (Unix) PHP/5.5.0
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0


REQUEST 1 で admin.php をリクエストすると、ログインしていないので login.php にリダイレクトされます。

--- REQUEST 2 --->

POST http://192.168.0.10:80/sample/login.php HTTP/1.1
Content-Length: 36
Content-Type: application/x-www-form-urlencoded

action=login&userid=foo&password=bar

<--- RESPONSE 2 ---

HTTP/1.1 302 Found
Date: Wed, 31 Jul 2013 06:10:42 GMT
Content-Length: 211
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Location: admin.php
Set-Cookie: PHPSESSID=xxxxl9s9qmfd6dhnvtqml6xxxx; path=/
Content-Type: text/html
X-Powered-By: PHP/5.5.0
Server: Apache/2.4.4 (Unix) PHP/5.5.0
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

<form action="" method="post">
USER: <input name="userid" type="text" value="foo" /><br/>
PASS: <input name="password" type="text" value="bar" /><br/>
<input name="action" type="submit" value="login" />
</form>

REQUEST 2 は login.php に対して action=login&userid=foo&password=bar をPOSTしています。
この REQUEST 2 はブラウザからのリクエストでなく、OpenIGが /sample/login.php というURLを認識して代理認証を行っています。
設定ファイルでいうと、DispatchHandler から LoginChain に処理が引き渡され LoginRequestFilter が実行されたところです。
RESPONSE 2 では、ログインに成功したので admin.php へリダイレクトをかけています。

--- REQUEST 3 --->

GET http://192.168.0.10:80/sample/admin.php HTTP/1.1
cookie: PHPSESSID=xxxxl9s9qmfd6dhnvtqml6xxxx
connection: keep-alive
accept-language: ja,en-us;q=0.7,en;q=0.3
host: target.example.com
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
user-agent: Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0
accept-encoding: gzip, deflate

<--- RESPONSE 3 ---

HTTP/1.1 200 OK
Date: Wed, 31 Jul 2013 06:10:42 GMT
Content-Length: 13
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Content-Type: text/html
X-Powered-By: PHP/5.5.0
Server: Apache/2.4.4 (Unix) PHP/5.5.0
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Login success

REQUEST 3 はリダイレクト先のadmin.phpをリクエストしており、RESPONSE 3 でadmin.phpページが表示されています。

このキャプチャーログを見ると、OpenIGの動作がよくわかります。
代理認証がうまくいかなかったり、何かエラーが表示されたときなど、アプリケーションサーバのエラーログだけでなくキャプチャーログも参考になると思います。

ただし、本番運用でキャプチャーログを取得する設定だとログのデータ量が膨大になってしまうので、キャプチャーは試験運用時のみ用いるのが望ましい、とForgeRock社のドキュメントには記載されています。

さて、ざっとですが代理認証の裏側をみてみました。
OpenIGの動作について、少し理解が深まったのではないでしょうか。

次回は、より本番に近い形での代理認証を行ってみます。


(参考サイト)

ForgeRock社のドキュメントを参考にさせていただきました。

OpenIG自習室(第3回:代理認証 Lv.1)

takaです。

前回はOpenIGのインストールと動作テストを行いました。
今回は、OpenIGのメイン機能とも言える代理認証機能を実現してみます。
まずはレベル1ということで、簡単な設定を使ってやってみましょう。

検証作業は、前回同様以下の環境で実施しています。
OS :Ubuntu 12.04 LTS
CPU:Intel Celeron 2.20GHz
MEM:2GB

アプリケーションサーバ:target.example.com(192.168.0.10)
OpenIGサーバ             :gateway.example.com(192.168.0.20)


1. ターゲットアプリケーションの準備

代理認証というくらいですから、認証を行うアプリケーションが必要です。
ForgeRock社のドキュメントでは、WordPress を使っています。
すでにWordPressを使っている方、WordPressの導入が容易な方はWordPressを使っていただければ結構です。
導入にはハードルが高い、面倒、訳あって使えない、などであれば簡単な認証アプリケーションを用意しましょう。
PHPを使える環境があれば、以下のスクリプトをサーバにアップして準備完了です。

■login.php

<?php
header('Content-Language: ja');
header('Content-Type: text/html; charset=UTF-8');

define("USERID", "foo");
define("PASSWORD", "bar");

session_start();

if(isset($_POST["action"]) && $_POST["action"]==="login"){
    if(USERID === $_POST["userid"] && PASSWORD === $_POST["password"]){
        $_SESSION["TEST"] = array("USERID"=>$_POST["userid"],"PASSWORD"=>md5(PASSWORD));
        header("Location:admin.php");
    }else{
        session_destroy();
        message();
    }
}

function message(){
    print "ユーザー名またはパスワードが違います";
}
?>
<form method="post">
USER: <input name="userid" type="text" value="<?php echo USERID; ?>" />
PASS: <input name="password" type="text" value="<?php echo PASSWORD; ?>" />
<input name="action" type="submit" value="login" />
</form>

■admin.php

<?php
header('Content-Language: ja');
header('Content-Type: text/html; charset=UTF-8');

define("USERID", "foo");
define("PASSWORD", "bar");

session_start();

if(isset($_SESSION["TEST"]) && $_SESSION["TEST"] != null && USERID === $_SESSION["TEST"]["USERID"] && md5(PASSWORD) === $_SESSION["TEST"]["PASSWORD"]){
    print "Login success";
}else{
    session_destroy();
    header("Location:login.php");
}
?>

WebTecNote さんのスクリプトを参考にさせていただきました。ありがとうございます!

http://target.example.com/sample/ というURLに設置するという前提で説明します。
http://target.example.com/sample/login.php を開くと、ログインフォームが表示されます。
テキストフォームにはデフォルトで値が入力済みとなっていますので、そのまま送信してみましょう。
ログイン成功のメッセージが表示されるはずです。
念のため、フォームの文字を変更するとログイン失敗と表示されます。

■ログインフォーム

簡易認証アプリケーション - ログイン

■ログイン成功

■ログイン失敗

これで、ターゲットアプリケーションの準備は完了しました。

2. OpenIG設定ファイルの変更

【WordPress】
WordPressを使う方は、ForgeRock社が提供しているサンプルのコンフィグファイルに含まれる WordPressLogin.json を使います。
なお、コンフィグファイルは config.json にリネーム(またはシンボリックリンクを張る)して、Tomcat実行ユーザーのホームディレクトリ($HOMEとします)以下にある {$HOME}/.ForgeRock/OpenIG/ に設置してください。

以下の箇所を実際の環境に合わせて修正してください。

9行 :baseURI のURL
40行:uri のURL
42行:log のユーザー名
43行:pwd のパスワード
45行:redirect_to のURL

【簡易認証アプリ】
簡易認証アプリケーションを使う方は、WordPressLogin.json を以下のようにカスタマイズします。
カスタマイズしたコンフィグファイルは config.json にリネーム(またはシンボリックリンクを張る)して、Tomcat実行ユーザーのホームディレクトリ($HOMEとします)以下にある {$HOME}/.ForgeRock/OpenIG/ に設置してください。

{
    "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": "LoginChain",
                "type": "Chain",
                "config": {
                    "filters": ["LoginRequestFilter"],
                    "handler": "ClientHandler"
                }
            },
            {
                "name": "LoginRequestFilter",
                "type": "StaticRequestFilter",
                "config": {
                    "method": "POST",
                    "uri": "http://192.168.0.10:80/sample/login.php",
                    "form": {
                        "userid": ["foo"],
                        "password": ["bar"],
                        "action": ["login"]
                    }
                }
            }, 
            {
                "name": "ClientHandler",
                "type": "ClientHandler",
                "config": {
                }
            }
        ]
    },
    "servletObject": "HandlerServlet",
}

以下の箇所は実際の環境に合わせて修正してください。

9行 :baseURI のURL
18行:condition のURL(ログインページのURLを記載)
40行:uri のURL(同上)

設定ファイルを変更した場合は、OpenIGが稼働するWebアプリケーションコンテナを再起動します。

3. 動作テスト

【WordPress】
OpenIGの設定ファイルで指定したユーザーアカウントを、WordPressで事前に作成します。
接続元のクライアントより、Webブラウザでターゲットアプリケーションを閲覧します。
デフォルトであれば画面の右下に「ログイン」リンクがあります。
「ログイン」リンクをクリックすると、自動的に設定済みユーザーでログインできることを確認します。

【簡易認証アプリ】
接続元のクライアントより、Webブラウザでターゲットアプリケーションを閲覧します。
http://target.example.com:8080/sample/admin.php(URLは実際の環境に合わせてください)
自動的にログイン成功画面が表示されることを確認します。

※WordPress、簡易認証アプリ共に、ポート番号は8080を指定してください(Tomcat使用の場合)。
あくまでもブラウザで閲覧する先は、OpenIGサーバです。

さて、うまくいきましたでしょうか?
簡単な設定で代理認証を実現できることがお分かりになったかと思います。

次回は、代理認証がどのように行われているか、その仕組みを見てみます。


(参考サイト)

ForgeRock社のドキュメント、および以下のサイトを参考にさせていただきました。

パスワード認証ログインシステムのサンプル
http://tenderfeel.xsrv.jp/php/628/
初心者向けPHP5でつくるログイン機能のサンプルアプリケーション
http://d.hatena.ne.jp/replication/20100828/1282994791

sendMailの件名で文字化け

PHPで日本語のメール送信を実行する場合「mb_send_mail」関数が利用される。
しかし、この関数は不具合があり「mail」関数を好むプログラマも多い。
今回は、その「mail」関数の備忘録。

通常、日本語の件名で「mail」関数より送信しようとすると文字化ける。
そのため、JISに変換して送信すると、文字化けが解消される。
しかし、「【XXX】サンプル日本語件名」と件名に「すみつき括弧」があると、
文字化けが発生する。
この解消は下記の箇所に半角スペースを入れるとなぜか解消されるのだ。

「【XXX】_サンプル日本語件名」 ※ 分かり易いように「_」で半角スペースとしてます

OpenIG自習室(第2回:インストール)

takaです。

今回はOpenIGをインストールして、簡単な動作確認を行います。
なお、検証作業は以下の環境で実施しています。

OS :Ubuntu 12.04 LTS
CPU:Intel Celeron 2.20GHz
MEM:2GB

アプリケーションサーバ:target.example.com(192.168.0.10)
OpenIGサーバ             :gateway.example.com(192.168.0.20)


OpenIGはwarファイルです。従いまして、

1.warファイルと設定ファイルをダウンロード
2.warファイルを、Webアプリケーションコンテナの公開領域に設置(必要ならば展開)
3.OpenIG設定ファイルを、コンテナ起動ユーザーのホームディレクトリ以下に設置
4.Webアプリケーションコンテナを起動

これでインストールは完了します。簡単ですね。
といっても、OpenIGを動かすためには以下の環境が必要です。

A. Java SDK
ForgeRock社のドキュメントでは、Java SE JDK 6 Update 21以降が必要と書かれています。
なお、現時点(2013年7月)の最新バージョンは、

Java SE JDK 7 Update 25
Java SE JDK 6 Update 45

となっています。
どちらのバージョンでも、OpenIGの動作は確認できました。

B. Webアプリケーションコンテナ
OpenIGをサポートしているコンテナはこちらです。

・Tomcat 6.x、7.x
・Jetty 6.x、7.x
・Glassfish 2.x、3.x
・JBoss 5.x
・Weblogic 10.x

各コンテナのインストールや設定は、割愛します。
以下の例ではTomcat6を使用しますが、他のコンテナがインストール済みの場合はそちらを使っても良いでしょう。
ちなみに、ForgeRock社のドキュメントでは Jetty を使っています。

では、ForgeRock社のドキュメントを参考に、一番簡単なインストールと動作確認を行ってみます。
なお、以下の操作はOpenIGをインストールするサーバ上で行うことを想定しています。

1. OpenIGの .war をダウンロード
ここからダウンロードします。
http://download.forgerock.org/downloads/openig/2.1.0/gateway-2.1.0.war
ForgeRock Community -> OpenIG Project -> Archives に最新の安定版があります。
現時点(2013年7月)の安定バージョンは、2.1.0 です。

2. サンプル設定ファイルをダウンロード
ここからダウンロードして展開します。
http://openig.forgerock.org/forgerock-sample-configs.zip

# unzip forgerock-sample-configs.zip

4つのJSONファイルが含まれていますが、今回は一番単純な WordPressProxyOnly.json を使います。

3. Tomcat6 をダウンロード
ここからダウンロードしました。
現時点(2013年7月)の最新バージョンは、6.0.37 です。
http://ftp.riken.jp/net/apache/tomcat/tomcat-6/v6.0.37/bin/apache-tomcat-6.0.37.tar.gz
展開や設定は割愛します。

4. OpenIGの配備
Tomcatのルートコンテキストにある ROOT ディレクトリは、事前に移動、リネーム、削除などしておきます。

# cp /usr/local/src/gateway-2.1.0.war $CATALINA_HOME/webapps/ROOT.war

5. OpenIG設定ファイルの設置
手順2で展開した WordPressProxyOnly.json を、Tomcat起動ユーザーのルートディレクトリ直下に設置します。
今回は全てrootで作業しているので、/root配下となります。

# cd /root
# mkdir .ForgeRock .ForgeRock/OpenIG
# mv /usr/local/src/WordPressProxyOnly.json /root/.ForgeRock/OpenIG/config.json

6. OpenIG設定ファイルの編集
ForgeRock社のドキュメントには、WordPressLogin.json を使ってWordPressのデモサイトに接続する手順が記載されています。
ところが、2013年の6月頃からデモサイトにアクセスできなくなりました。
今回は、リバースプロキシの動作だけを確認するため WordPressProxyOnly.json を編集して使います。
手順5でリネームした config.json をエディタで開きます。

# vi config.json
{
    "heap": {
        "objects": [
            {
                "name": "HandlerServlet",
                "type": "HandlerServlet",
                "config": {
                    "handler": "ClientHandler",
                    "baseURI":"http://109.73.67.52:8080"
                }
            },
            {
                "name": "ClientHandler",
                "type": "ClientHandler",
                "config": {
                }
            }
        ]
    },
    "servletObject": "HandlerServlet",
}

baseURI のURLを、任意のアドレスに変更します。
baseURI の値は、どこのサイトでも構いません。
GoogleやYahooなどのIPを調べて記述しても結構ですが、ポート番号が一致しないと正しく表示されないことがあります。

{
    "heap": {
        "objects": [
            {
                "name": "HandlerServlet",
                "type": "HandlerServlet",
                "config": {
                    "handler": "ClientHandler",
                    "baseURI":"http://192.168.0.10:8080"
                }
            },
            {
                "name": "ClientHandler",
                "type": "ClientHandler",
                "config": {
                }
            }
        ]
    },
    "servletObject": "HandlerServlet",
}

(ポイント)OpenIGのポート番号と、ターゲットアプリケーションのポート番号は合わせておきます。

7. 名前解決設定の変更
OpenIGにアクセスする接続元のクライアントで、hostsファイルの記述を変更します。
ターゲットアプリケーションのドメインに対して、OpenIGサーバのIPアドレスを紐づけます。
これによって、ターゲットアプリケーションに直接アクセスするのではなく、必ずOpenIGを経由してアクセスするようになります。

例)
アプリケーションサーバ     :target.example.com(192.168.0.10)
OpenIGサーバ                  :gateway.example.com(192.168.0.20)

このような環境の場合、hostsファイルの記述は以下のように行います。

192.168.0.20	target.example.com

8. 動作テスト
TomcatなどのWebアプリケーションコンテナを起動します。
接続元のクライアントより、Webブラウザでアプリケーションサーバ(target.example.com)を閲覧します。
ターゲットアプリケーションが表示されるはずです。
また、gateway.example.com にアクセスしても target.example.com が表示されます。

次に、Tomcatを停止します。
再びターゲットアプリケーションを閲覧してみましょう。
対象ページが開かなければ、OpenIGは正しく設定されています。
もしもページが開く場合は、ターゲットアプリケーションを直接見に行っていることになるので設定を見直してください。


さて、うまくいきましたでしょうか?
今回の内容だと、わざわざ遠回りをしてターゲットアプリケーションを表示しているだけです。
ですが、リバースプロキシの動作についてはお分かりになったと思います。
次回は、OpenIGの売りである代理認証機能を検証します。


(参考サイト)

ForgeRock社のドキュメント、および、以下のサイトを参考にさせていただきました。

OpenAMによるシングルサインオン(2)リバースプロキシー編
http://tech-sketch.jp/2013/06/openam-1.html
Diary >> 2012.12.04 OpenIG
http://spiral.world.coocan.jp/diary/?cat=68

OpenIG自習室(第1回)

takaです。

OpenIGというソフトウェアについて、数回にわたって検証したいと思います。

OpenIG – ForgeRock
http://openig.forgerock.org/

OpenIGとは何者か?

OpenIGは、Open Identity Gateway の略で、そのまんま「アイデンティティのゲートウェイ」です。
何のために使うのかというと、その目的はWebアプリケーションへのシングルサインオンを実現することです。
シングルサインオンが分からない方はこのブログに興味がないと思いますが、参考までにこちらがわかりやすいと思います。

基礎から学ぶ!シングルサインオン/キーマンズネット
http://www.keyman.or.jp/at/sec/pki/30001292/

ディレクトリ統合(1):なぜ「シングル・サインオン」が必要なのか? – @IT
http://www.atmarkit.co.jp/ait/articles/0212/19/news001.html

既存のWebアプリケーション(以下、ForgeRock社の言葉を借りて、レガシーアプリ)には、独自の認証機構が組み込まれています。
シングルサインオンを実現しようとすると、通常はレガシーアプリ側への改修が必要となります。
ところが、このOpenIGを使うことによって、レガシーアプリに手を加えることなく、シングルサインオン環境を構築することができます。

OpenIGのコアとなる機能は、リバースプロキシです。
Webアプリケーションの前面に配備され、アプリケーションへのリクエスト/アプリケーションからのレスポンスをインターセプトします。

OpenIGは、リクエストやレスポンスの内容に応じて、動作を切り替えることができます。
例えば、ユーザーからレガシーアプリのログイン画面がリクエストされた場合、レガシーアプリからのレスポンス(ログイン画面のHTML)をインターセプトします。
インターセプトしたログイン画面に、本来ならユーザーが入力するはずのログイン情報(ID、パスワード等)をセットし、ユーザーに代わってレガシーアプリにPOSTしてログインを行います。
これが、アイデンティティのゲートウェイ、たる所以です。

最近のWebアプリケーションには、シングルサインオンのためのインターフェースが予め用意されていることが多いです。
Google Appssalesforce.com を始めとするSaaSアプリケーションは、SAMLという認証情報を交換するプロトコルを装備しています。
ちなみに、OpenIGにはSAMLプロトコルをサポートする機能もあり、レガシーアプリをSAML対応にすることも可能です。
また、OpenIDOAuthといったキーワードを目にする機会も多いと思います。
これらも、シングルサインオンを実現するための認証手段です。

レガシーアプリには、そのような気の利いた機能など(おそらく)ありません。
かといって、レガシーアプリのカスタマイズをする予算やリソースを確保することは困難だったりします。
そうなると、レガシー(遺産)という言葉通り、シングルサインオンから取り残されてしまうことになります。
レガシーアプリだけは今まで通り別にログインすればいいじゃないか!という意見もあるでしょう。
もちろん、それでも良いですが、ユーザー側の手間が増える以上の弊害があります。

シングルサインオンが可能ならば、アカウント情報は集中管理できますが、取り残されたアプリケーションが存在することによって、アプリケーション毎の管理が必要となります。
(現在はそういう状況が多いと思います)
社員の増減によるアカウントの追加や削除、異動による更新などの際に手続きが漏れてしまい、ログインできなかったり、いつまでもアカウントが使えてしまう可能性が出てきます。
場合によっては、致命的なセキュリティホールにもなり兼ねません。
組織変更や部署の統廃合の場合にも、レガシーアプリは別途マスタ情報を書き換えるなどの対応が必要となります。
そういうわけで、レガシーアプリをシングルサインオン環境に統合していくためには、OpenIGのようなゲートウェイソフトウェアの導入が求められています。
(エージェントという選択肢もありますが、これは追ってご説明します)

ということで、非常に簡単ですがOpenIGの紹介でした。
次回は、さっそくOpenIGをインストールして動かしてみます。