4

LDAP 認証を使用して Web アプリをセットアップしていますが、ユーザー データベースの関係 (作成者、割り当て先、承認者、メンバーなど) を処理する方法がよくわかりません。

これまでのところ、次のオプションを考え出しました。

  1. ユーザーが最初にログインしたときに、users テーブルにレコードが存在するかどうかを確認します。そうでない場合は、ldap ルックアップを実行して名前と電子メールを取得し、ユーザー レコードを作成します。ユーザーがリストに追加されるか選択されると、同じことが起こります。(おそらく、最後の LDAP ルックアップ日付を保存し、x 日後にログイン時に詳細を更新します)

  2. cn だけでユーザー レコードを作成し、名前と電子メールのオンザフライ検索を実行します。

  3. fk の代わりに cn を保存し、名前と電子メールのオンザフライ検索を実行します。

私はオプション 1 を選択する傾向があります。これは、ORM をシンプルに保ち、ルックアップの数を減らすためです。一方で、少し過剰に設計されているようです。

上記のオプションを避けるべき代替案や理由を教えてください。

4

1 に答える 1

1

これはおそらくユースケースに依存します。

  • すべてのユーザー (まだログインしていないユーザーも含む) について知りたいですか?
  • それらのカスタム属性を保存する必要がありますか?
  • ユーザー属性に基づいてリレーショナル クエリを作成する必要がありますか?

ほんの少しの比較：

  • Linux PAMはオプション 3 (NSS) を使用します。
  • LiferayまたはRedmineは両方とも、変更されたオプション 1 を使用します。

実際、私が見たアプリケーションの大半は、変更されたオプション 1 を使用しています。これは、通常、LDAP はサポートされている認証オプションの 1 つにすぎず、多くの場合、すべてのユーザーの追加データを保存し、他のユーザーと同じようにエントリを操作する必要があるためです。他のエンティティ（関係、メンバーシップについて言えば...）。あなたの説明との重要な違いは次のとおりです。

  • ユーザーがログインするたびにユーザー エントリを更新します。

4 番目の可能性があることに注意してください。LDAP と直接統合せず、IdM システムがユーザーをアプリケーションにプロビジョニングできるようにします。ただし、これには動作中の IdM がターゲット環境に存在する必要があります。

于 2013-06-25T06:52:25.710 に答える