☰

LDAP：如何组织用于 Web 应用程序访问的树？

tag-icon • tag-icon linux authentication
LDAP：如何组织用于 Web 应用程序访问的树？

我需要创建一个不太小的 Web 应用程序，其中只有 3 个配置文件

  • 行政
  • 读/写用户
  • r/o 用户

我们需要使用 LDAP 树登录用户。这是我第一次在 Debian 上创建 OpenLDAP 服务器，所以我对树的组织方式感到很困惑

我知道 LDAP 有一个管理员用户，即 LDAP 本身的系统管理员。

我需要在这 3 个“组”中添加一些用户

  • admin、r/w 和 r/o

而且我需要创建一个无法访问应用程序但作为 ldap 用户有效的用户，因为组织很大，只有其中一些可以访问 ldap。所以我需要测试当非 webapp 用户尝试登录时会发生什么。

Webapp 部分是完全不同的问题，我并不是在问客户端部分。

我问你如何将其他人组织成这样的群体

  • 非 Web 应用程序
    • nonwebappuser1
    • nonwebappuser2
  • 网络应用
    • 网络应用管理员
      • webappadmin1
      • webappadmin2
    • 网页应用
      • webapprw1
      • webapprv2
    • 网页应用
      • webappro1
      • webappro2

我知道这一点，nonwebapp并且webapp可以成为组织单位。

但是对于“角色”组，如 webappadmins、webapprw 和 webappro 来说又如何呢？

这是主要问题

我应该如何组织 LDAP 树以仅允许一部分用户访问 Web 应用程序并赋予他们角色？

答案1

我知道 LDAP 有一个管理员用户，即 LDAP 本身的系统管理员。

A新鲜的OpenLDAP 安装将有一个“root”帐户，但您可以随后通过olcAccess（参见“man slapd.access”）定义访问控制列表。

例如，您可以授予特定 groupOfNames 的成员修改访问权限，使您的 web 应用程序能够仅更新“成员”属性，等等。

事实上你很可能需要定义一些基本的 ACL，以防止非管理员用户看到每个人的“userPassword”属性。（并创建服务帐户以避免将 rootDN 放在所有应用程序中！）

我知道 nonwebapp 和 webapp 可以是组织单位。

一旦实施了角色，区分“webapp”和“nonwebapp”就纯粹是出于组织考虑，不再适用于授权。由于无论如何都要检查角色，因此只需拒绝不属于任何角色的用户访问即可。

换句话说，目录树不是授权机制。

但是对于“角色”组，如 webappadmins、webapprw 和 webappro 来说又如何呢？

有多种方式来实现角色：

  • 专用的“组”条目，其中列出了属于该角色的每个用户的 DN。有两个常用对象类（均在 core.schema 中预定义）可在此处使用：

    • groupOfNames是通常用于访问控制的属性。它不允许成员列表为空（即“member”属性是必需的）。

      dn: cn=Read-only users,ou=Webapp roles,o=Widgets Ltd
objectClass: groupOfNames
member: uid=webappro1,ou=Webapp users,o=Widgets Ltd
member: uid=webappro2,ou=Webapp users,o=Widgets Ltd

    • organizationalRole更适合用于“信息”目录条目（如电话簿），但您也可以使用它进行访问控制。它允许空成员列表（roleOccupant 是可选的）。

      dn: cn=Read/write users,ou=Webapp roles,o=Widgets Ltd
objectClass: organizationalRole
roleOccupant: uid=webapprw1,ou=Webapp users,o=Widgets Ltd
roleOccupant: uid=webapprw2,ou=Webapp users,o=Widgets Ltd

    注意：最好不要直接检查组成员列表，而使用 LDAP“比较”操作，因为它会识别您正在处理“DN”类型的属性，并会为您处理 DN 规范化。

    （在处理对 LDAP 数据库的直接访问时，OpenLDAP ACL 系统可以支持这两种格式。by group=主题规范默认将期望 groupOfNames，但by group/organizationalRole/roleOccupant=也可以这样说。）

  • 帐户条目本身的属性。您可以定义自定义属性并将其添加到 OpenLDAP 架构中，或重新利用现有属性，例如authorizedService。（此特定属性最初用于操作系统级授权，但它不会限制您在其中输入的服务名称。）

    dn: uid=webapprw1,ou=Webapp users,o=Widgets Ltd
objectClass: person
objectClass: authorizedServiceObject
authorizedService: webapp/read-only

    （请注意，OpenLDAP 的 ACL 不支持检查主题的属性；在这种情况下您仍然需要使用组。）

  • 如果每个用户都恰好一角色，您实际上可以像在图表中一样使用嵌套 OU。但是检查或更改某人所在的 OU 需要的代码比通过属性执行相同操作要多一些，所以我不会使用这种方法。

  • 首先不要通过 LDAP 做出这些决定。应用程序实际上通常会认证用户针对 LDAP（并从那里检索信息），但是授权将它们与某个非 LDAP 数据库（完全在应用程序本身内部）进行比较。例如，您可以只拥有一个名为“role_assignments”的 SQL 表。

相关内容