この認証方法は、しばしば特に大きな組織で シングルサインオン (SSO) に使われます。
この認証は別のシステムで完了するので、Kanboardはパスワードを知らず、あなたも既に認証されていると思うでしょう。
同じサーバー上のApache Auth か、 十分な設定がされたリバースプロキシ。
- リバースプロキシ認証のユーザーは、ユーザー名をHTTPヘッダを通して送ります。
- Kanboard はユーザー名をリクエストから取得します。
- 必要に応じ、自動的にユーザーが作成されます。
- 有効なプロンプトが無いと想定して、新しいKanboardセッションが開かれます。
この件はこの文書のスコープ外です。リバースプロキシによるユーザーログインが送信するHTTPヘッダを確認すべきで、そこから何かを見つけられるでしょう。
カスタム config.php
ファイルを作成するか、 config.default.php
ファイルをコピーします:
<?php
// リバースプロキシ認証を有効/無効にする
define('REVERSE_PROXY_AUTH', true); // この値をtrueにしてください。
// HTTP ヘッダーを取得します。指定されない場合、 REMOTE_USERがデフォルトとなります。
define('REVERSE_PROXY_USER_HEADER', 'REMOTE_USER');
// 組織で既定のKanboardの管理者を指定します。
// リバースプロキシによって全てフィルタリングされるべきなので、
// ブートストラップの管理ユーザーを持つべきです。
define('REVERSE_PROXY_DEFAULT_ADMIN', 'myadmin');
// Emailアドレスはデフォルトのドメインであると仮定します。
// ユーザー名がEmailアドレスで無い場合、自動的に USER@mydomain.comに更新されるでしょう。
define('REVERSE_PROXY_DEFAULT_DOMAIN', 'mydomain.com');
- プロキシがKanboardを実行しているwebサーバーと同じであるならば、 CGI protocol によると、ヘッダーでの名前は
REMOTE_USER
になるでしょう。例えば、デフォルトでRequire valid-user
をセットするようになっていた場合、REMOTE_USER
をApacheが追加するでしょう。
- -
REVERSE_PROXY_USER_HEADER
とは違うヘッダーを使用している場合、値の接頭辞はHTTP_
であるべきで、 それは
$_SERVER
配列から取得されるからです。
- Kanboardを動かしているApacheとは別のApacheをリバースプロキシとしている場合、
REMOTE_USER
ヘッダーはセットされません (IISとかNginxと同じ動作) - 本物のリバースプロキシを持っている場合、HTTP ICAP draft が提案するヘッダーは
X-Authenticated-User
です。これは数多くあるデファクトスタンダードとして採用されたツールです。