主页 / computer / 问题 / 1628619
Accepted
realtebo
Asked: 2021-02-25 00:33:03 +0800 CST

LDAP：如何为 webapp 访问组织树？

  • 772

我有创建一个不那么小的 web 应用程序的要求，我们只有 3 个配置文件

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

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

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

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

  • 管理员、r/w 和 r/o

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

webapp 部分完全是另一个问题，我不是在问客户端部分。

我问你如何将其他一些人组织成这样的组

  • 非网络应用
    • 非webappuser1
    • 非webappuser2
  • 网络应用
    • webappadmins
      • webappadmin1
      • webappadmin2
    • webapprw
      • webapprw1
      • webapprv2
    • 网络应用程序
      • webappro1
      • webappro2

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

但是“角色”组，比如 webappadmins、webapprw 和 webappro 呢？

这是主要问题

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

linux authentication

1 个回答

  1. Best Answer

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

    全新的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 表。

    • 1

相关问题