これは良い記事ですが、ldap への接続とバインディング (どのページ) をどこに配置すればよいかわかりません。認証がサブページ、または将来作成される他のページにも適用されるようにするにはどうすればよいですか?
これで、アプリに状態が追加されます。最初は、認証 (authn) と認可 (authz) をアプリではなく tomcat に実装することを考えるかもしれません。
tomcat で実装せず、perl で実装することを選択した場合は、アプリケーションに状態を追加することを決定したことになります。つまり、何らかのセッション処理を追加する必要があります。CGI::Session を見てください。CPAN には他にも多くのセッション処理モジュールがあります。Apache::Session を避けます。トランザクションが長時間実行される場合、そのロック処理は多くの苦痛を引き起こす可能性があります。Cookie でセッション キーを使用します。SSL経由ですべてを送信します。SSL を使用しない場合、クラッカーはセッション キーを傍受し、セッションを乗っ取ることができます。
セッション インフラストラクチャをセットアップしたら、ログイン メカニズム (通常はユーザー名とパスワードを含むフォーム) を作成する必要があります。そのフォームが送信されると、その背後にある CGI がパスワードに対して魔法の暗号を実行し、次に LDAP ダンスを実行します。
- ディレクトリ サーバーに接続しますが、接続はまだ存在しません。
2a. 匿名で、またはアプリケーション ユーザーとしてサーバーにバインドする、CN でユーザーを検索する、DN とパスワードを使用してユーザーとしてバインドする
また
2b. ユーザー名から DN を計算し、DN と暗号のパスワードをバインドします。
多くの場合、ステップ 3 は、ユーザーのレコードをチェックして何らかの認証インジケーターを確認することです。これは、はい/いいえのアクセス インジケーターである場合もあれば、役割または特権のリストである場合もあります。
ユーザーが正常に認証され、承認された場合は、承認情報をユーザーのセッションに書き込みます。
アプリの後続の各ページは、ユーザーがログインしているかどうか、および/またはそのページを使用するための適切な認証を持っているかどうかを確認します。承認されていない場合は、ログイン後のランディング ページに送り返すか、ログインしていない場合はログイン ページに送り返すことができます。
基本的には、通常の「データベースのユーザー テーブルをクエリする」を、ディレクトリ サーバーへの LDAP へのクエリに置き換えるだけです。