【问题标题】:Handling user relationship with LDAP authentication [closed]使用 LDAP 身份验证处理用户关系 [关闭]
【发布时间】:2013-06-24 18:51:53
【问题描述】:

我正在设置一个带有 LDAP 身份验证的网络应用程序,但我不太清楚如何处理用户数据库关系(例如,由创建、分配给、批准者、成员)

到目前为止,我想出了以下选项:

  1. 当用户首次登录时,检查用户中是否存在记录 桌子。如果没有,请执行 ldap 查找以检索姓名和电子邮件,然后 创建用户记录。添加用户时会发生同样的事情 到列表或选定。 (可能存储上次 ldap 查找日期和 x 天后刷新登录详情)

  2. 仅使用 cn 创建用户记录,并即时查找姓名和电子邮件

  3. 只需存储 cn 而不是 fk,然后即时查找姓名和电子邮件。

我倾向于选择选项 1,因为它可以简化 ORM 并减少查找次数。另一方面,它似乎有点过度设计。

任何应避免上述选项的替代方案或理由,我们将不胜感激。

【问题讨论】:

  • 您应该将角色放入 LDAP,而不是单独的数据库。这就是 LDAP 的用途。
  • 这与角色无关..
  • 审批者和成员都是角色。
  • 如果团队由用户维护并且用户选择了批准者,则不会;)

标签: database orm ldap


【解决方案1】:

这可能取决于您的用例。

  • 您想了解所有用户(包括尚未登录的用户)吗?
  • 您需要为它们存储自定义属性吗?
  • 是否需要根据用户属性进行关系查询?

只是一些比较:

事实上,我见过的大多数应用程序都在使用修改后的选项 1。这是因为 LDAP 通常只是支持的 身份验证 选项之一,而且在许多情况下,您希望为每个用户并像与任何其他实体一样使用条目(谈到关系,成员资格,......)。与您的描述的重要区别是:

  • 每次用户登录时刷新用户条目。

请注意,还有第四种可能性——不要直接与 LDAP 集成,而是让IdM system 为您的应用程序提供用户。但是,这需要您的目标环境中存在有效的 IdM。

【讨论】:

  • 感谢您提供的信息,我想我会选择选项 1,在登录时刷新并为所有将使用此机制的系统使用共享用户数据库。没有存储自定义属性的计划,但对用户属性的查询很重要。在某些情况下,我需要尚未登录的用户的详细信息,但我可以轻松满足。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-08-05
  • 1970-01-01
  • 2012-10-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多