ユーザ認証とアクセス権の設定をサポートします。INTER-Mediator自身がデータベースを利用して、ユーザーやグループを管理する手法を「ビルトイン認証」、SAMLを利用する認証を「SAML認証」と呼びます。また、OAuth2（ただし、Googleのみ確認）にも対応しています。INTER-Mediator Ver.8では、パスワード記録時のハッシュを従来のSHA-1から、5000ストレッチしたSHA-256にアップデートしています。従来のSHA-1でのハッシュと相互運用もできます。LDAPについては、SAMLのIdp経由でSAMLベースで利用するようになりました。本ページは、INTER-Mediator Ver.14の状況で説明しています。

認証動作に必要なテーブル

チャレンジ等を記録するテーブル

ユーザ認証ではセキュリティを高めるために、サーバーからクライアントに「チャレンジ」を送り、その値を利用して認証情報を作ります。そのため、サーバー側にチャレンジを残しておく必要があり、テーブルの定義が必要です。そのテーブルは、IM_Entryの第3引数あるいはparams.phpで指定したユーザで読み書きの権限が必要です。チャレンジのテーブル名は、IM_Entryの第2引数で指定するか、あるいは既定値の名前（issuedhash）のテーブルを作成します。テーブルには以下のフィールドが必要です。

なお、このテーブルへの検索では、user_idとclienthostの2つのフィールドに対してAND演算での検索条件が与えられます。従って、高速化するためには、この2つのフィールドを合成したインデックスを作っておきます。

ユーザーのテーブル

認証のためのユーザは、データベース内にテーブルを作成する方法と、データベースエンジンが管理するユーザによる方法を利用できます。データベース内にテーブルを作る場合、そのテーブルは、IM_Entryの第3引数あるいはparams.phpで指定したユーザで少なくとも読み出しの権限が必要です。チャレンジのテーブル名は、IM_Entryの第2引数で指定するか、あるいは既定値の名前（authuser）のテーブルを作成します。テーブルには以下のフィールドが必要です。

ユーザの場合は、ユーザ名をキーフィールドに使えるとも考えられますが、大量のユーザになったときなどに処理速度を有利にするために、内部的にはidフィールドによる連番で与えた数値で処理をすることにします。なお、usernameを条件として検索をかけるので、高速化のためにはこのフィールドにインデックスを作成しておきます。パスワードはハッシュを保存しますが、ハッシュ値は、次の手順で計算をします。

1. パスワード（pw）と、4バイトのソルト（s）を用意します。
2. パスワードとソルトをつなげた文字列のSHA-256を5000回のストレッチで求めます（ sha256(pw+s, 5000) → H1）
3. H1の16進数表現した文字列と、ソルトを16進数表現した文字列をつなげます（hex(H1)+hex(s)→H2）
4. H2をフィールドに保存します。

コマンドで求める例としては、あまり効率良くはないですが、INTER-Mediatorのレポジトリにあるdist-docs/passwdgen.shスクリプトを利用できます。-uはユーザ名、-pはパスワード、-sはSQL文として出力するパラメータです。opensslのコマンドを内部で使っていますが、5000回のストレッチをコマンドから行う方法がわからず、シェルスクリプトで繰り返してopensslコマンドを動かしているため、ハッシュの計算に30秒から1分くらいかかると思われます。

% dist-docs/passwdgen.sh -u test -p TEST -s
INSERT authuser(username,initialpass,hashedpasswd) VALUES('test','TEST','5d4b09daced104e42bc5cfc1d4db6c677afd3ffeadc950a2873b009aeba39bab45654d4b');

なお、過去に開発したアプリケーションとの互換性を考慮して、SHA-1での利用も可能です。SHA-1ハッシュ値は、次の手順で計算をします。

1. パスワード（pw）と、4バイトのソルト（s）を用意します。
2. パスワードとソルトをつなげた文字列のSHA-1求めます（ sha1(pw+s) → H1）
3. H1の16進数表現した文字列と、ソルトを16進数表現した文字列をつなげます（hex(H1)+hex(s)→H2）
4. H2をフィールドに保存します。

SHA-256互換ハッシュという、SHA-1からパスワードを変更せずにハッシュそのものはSHA-256に移行できるモードも用意しています。設定を行えば、SHA-1での認証が成功した時に、データベースのhashedpasswdフィールドの内容をこの互換ハッシュで書き換えます。次回以降の認証は、互換ハッシュを使っての認証となるので、パスワードを変更せずにSHA-256を使ったハッシュでの運用に移行できます。互換ハッシュは次の手順で計算をします。

1. SHA-1で求めたHEX表現のハッシュをHとします。
2. Hのソルトを求めてsとします（salt(H) → s）
3. Hとsをつなげた文字列のSHA-256を5000回のストレッチで求めます（ sha256(H+s, 5000) → H1）
4. Hの16進数表現した文字列と、ソルトを16進数表現した文字列をつなげます。このH2がSHA-256互換ハッシュです（hex(H1)+hex(s)→H2）

グループを管理するテーブル

グループそのものを管理するテーブルと、ユーザーやグループの特定のグループへの所属を記録するテーブルの2つがあります。

アクセス権に関する設定の評価

認証の設定は基本的にコンテキストに行いますが、IM_Entryの2番目の引数にも行えます。記述可能な内容については、『定義ファイルでの記述方法a>』を参照してください。つまり、2カ所の設定があるので、以下のように、コンテキストに設定する方を「コンテキストの認証設定」、2つ目の引数に設定するのを「オプションの認証設定」とします。また、いずれも、アクセス権の設定も行いますが、「認証とアクセス権」を合わせてここでは「認証」というネーミングをします。

IM_Entry(
    array(
        array(
            "name"=>"context",
            "authentication"=>array(
                /* コンテキストの認証設定 */
            ),
        ),
    ),
    array(
        "authentication"=>array(
            /* オプションの認証設定 */
        ),
...);

オプションの認証設定やparams.phpファイルに設定可能な情報

オプション配列に関して（未定義）とあるものは、オプションで指定ができないものを意味します。つまり、この設定は、params.phpファイルでの変数での設定のみです。一方、params.phpでの変数名が（未定義）のものは、オプション設定のみで利用できるものです。既定値が「なし」とは、設定しない場合はその機能が利用できないことを意味します。

認証設定の動作に関する設定

認証動作に関する設定

OAuth2認証に関する設定

SAML認証についての設定

ログインパネルのカスタマイズに関する設定

コンテキストの認証設定に設定可能な情報

コンテキストの認証設定なし、オプションの認証設定あり

タイトル用な条件だと、コンテキストの認証設定のuserとgroupがアクセス権の設定に関係します。もし、userもgroupも設定されていない場合は、認証が通ったユーザは何でもできると考えてください。

userあるいはgroupが設定されている場合、認証が通ると同時に、そのユーザあるいはそのユーザを含むグループが、userあるいはgroupの設定に含まれている必要があります。

コンテキストの認証設定あり、オプションの認証設定なし

オプションの設定のうちuserとgroupの設定がないということです。この場合、特定のコンテキストのデータベース処理に対して、コンテキストの認証設定が適用されます。

コンテキストの認証設定あり、オプションの認証設定あり

両方の認証設定があれば、先にオプションの認証設定が評価されて、その後にコンテキストの認証設定が評価されます。

コンテキストの認証設定の適用対象

適用対象として、4つのデータベース処理、read/create/update/deleteに対する処理と、それらすべてに対してまとめて設定を行うallがあります。

コンテキストの認証設定のtableとfleld

"table"キーに対する値がfield-userあるいはfield-groupの場合は、そのテーブルにあるfieldに指定したフィールドに、ログインが成功したユーザあるいはそのユーザが含むグループの名前が設定されちているレコードだけに絞り込まれます。検索条件にANDでユーザないしはグループの値をfieldに指定したフィールドに対する条件を付け加えます。したがって、fieldで指定したフィールドのうち、空欄ものは認証すればいっさいアクセスできないということになります。

"table"キーに対する値がfield-useやfield-groupではない場合、アクセス権はすべてのテーブルに渡って適用されます。レコードごとのアクセス権を記録するフィールドは不要です。このとき、userあるいはgroup属性に含まれていないユーザで認証した場合、いっさいのアクセスはできないようになっています。オプションの認証設定と異なる動作ですので、注意してください。

read/update/deleteに関しては、アクセス権は「検索条件」として集約されます。一方、createの操作に対しては、アクセス権がある場合だけ、レコードの作成が可能です。レコードの作成により、fieldで指定したフィールドに、ユーザないしはグループが設定されます。ユーザの場合は1つに決まりますが、グループの場合は、グループ名を並べ替えたときのいちばん先頭のグループ名を記録するようにします。

ログインパネルのカスタマイズ

ログインパネルのカスタマイズについて、マイナーなものであれば、CSSの設定で行けると思います。ブラウザのデバッガで見ていただければ、ログインパネルの各要素はそれぞれclass属性が割り当てられているので、たとえば、ページのヘッダや独立したファイルでCSSを適用します。これらは、原則としてINTER-Mediatorのテーマ設定よりも優先度は高くなるので、上書きや変更は可能です。なお、ログインパネルのスタイル情報はテーマに含まれているので、テーマを作り直すという方法もあります。

ログインパネルを完全にカスタマイズしたいとう場合は、例えば、以下のようなプログラムを、INTERMediatorOnPage.doBeforeConstructに代入する関数の中などで実行します。最初の3行はプロパティ名から動作は明白と思われますが、ポイントは、ページに上乗せするログインパネル部分を、HTMLの文字列として、loginPanelHTMLプロパティに書き込みます。

INTERMediatorOnPage.isShowChangePassword = false;
INTERMediatorOnPage.defaultBackgroundImage = null;
INTERMediatorOnPage.defaultBackgroundColor = "white";
INTERMediatorOnPage.loginPanelHTML = '<div>....';

このloginPanelHTMLに書き込むHTMLはボディの一部となるような書き方をします。原則自由に記述できますが、この中にユーザー名を入れるテキストフィールドや、認証ボタンなどを配置する必要があります。それらは、決められたid属性を持つ必要があります。INTER-Mediatorが認識するid属性は、_im_password、_im_username、_im_authbutton、_im_changebutton、_im_oauthbuttonです。最初の2つがテキストフィールド、残りがボタンを想定しています。このid属性値を設定しておけば、例えば、認証ボタンとしての機能はINTER-Mediatorが自動的に組み込みます。