授权系统设计问题

Question

我正在尝试想出一种进行身份验证和授权的好方法。这是我所拥有的。欢迎评论，也是我所希望的。

我在mac服务器上安装了php。我有用于用户帐户的Microsoft AD。

当用户登录到Intranet时，我正在使用LDAP查询AD。

我的设计问题涉及如何处理这些广告信息。一位同事建议在AD中使用命名约定，以避免中间数据库。例如，我有一个网页，personnel_payroll.php。我获得了url，并使用该URL和AD用户在AD上查询组personnel_payroll。如果登录的用户在该组中，则他们有权查看该页面。我将必须有一个组为每个页面或至少用户域用户的一般身份验证。

在页面上使用控件会变得更加棘手。例如，假设页面或网格上有一个按钮，只有管理员才能看到。我需要在我的广告中将personnel_payroll_myButton作为一个组。如果用户在该组中，他们将获得按钮。如果一个页面有几个不同级别的授权，我可以有很多组。

是的，我的AD会很大，但如果我不这么做，其他东西也会这么做，不管是MySQL (或其他数据库)、文本文件、httpd.conf等等。

我会有一个通用的功能IsAuthorized的各种项目，传递的网址或控制名称和认证的用户。

使用这样的安全命名约定并使用AD作为存储库，是否存在固有的错误？我得把它放在某个地方。为什么不是AD呢？

感谢您的评论。

编辑:您认为这种方案会因为LDAP调用而导致超慢的页面吗？

编辑:我不是第一个想到这一点的人。任何关于这方面的想法都是值得感谢的。

编辑:感谢大家。很抱歉，我不能给你们更多的分数来回答。我不得不选一个。

Answer 1

我想知道是否有一种不同的方式来表达和存储权限，这样可以更干净、更有效地工作。

大多数应用程序被划分为功能区域或角色，并根据这些大的区域分配权限，而不是按页分配权限。因此，例如，您可能具有如下权限：

• UseApplication
• CreateUser
• ResetOtherUserPassword
• ViewPayrollData
• ModifyPayrollData

或者使用角色，您可以拥有：

• ApplicationUser
• ApplicationAdmin
• PayrollAdmin

角色(可能还有每个功能的权限)可能已经映射到Active Directory中存储的数据，例如现有的AD组/角色。如果不是这样，它仍然比每页权限更容易维护。权限可以作为用户组维护(用户可以在组中，因此具有权限，也可以不在组中)，也可以作为自定义属性进行维护：

dn: cn=John Doe,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: webAppUser
cn: John Doe
givenName: John
...
myApplicationPermission: UseApplication
myApplicationPermission: ViewPayrollData

这样做的优点是，模式更改最少。如果您使用组，AD (和地球上的所有其他LDAP服务器)已经具有该功能，并且如果您使用这样的自定义属性，则只需要添加单个属性(以及上面示例中的objectClass、webAppUser )。

接下来，您需要决定如何使用数据。一种可能是在用户登录时检查用户的权限(找出他们所在的组，或者他们被授予了什么权限)，并将其存储在会话中的when服务器端。这有一个问题，即权限更改仅在用户登录时生效，而不是立即生效。如果您不希望权限经常更改(或者当用户同时使用系统时)，这可能是一种合理的方法。这有一些变体，比如在经过一段时间后重新加载用户的权限。

另一种可能性是根据需要检查权限，但具有更严重的(负面)性能影响。在这种情况下，您最终会更频繁地访问AD服务器，导致( web服务器和AD服务器上的)负载增加，网络流量增加，延迟/请求时间更长。但您可以确保权限始终是最新的。

如果您仍然认为将单独的页面和按钮名称作为权限检查的一部分会很有用，那么您可以有一个页面/按钮=>权限的全局“映射”，并通过它执行所有的权限查找。一些东西(完全未经测试，主要是伪代码)：

$permMap = array(
    "personnel_payroll" => "ViewPayroll",
    "personnel_payroll_myButton" => "EditPayroll",
    ...
);

function check_permission($elementName) {
    $permissionName = $permMap[$elementName];
    return isUserInLdapGroup($user,$permissionName);
}

Answer 2

使用AD获取权限的想法是没有缺陷的，除非你的AD不能扩展。如果使用本地数据库会更快/更可靠/更灵活，那么就使用它。

然而，使用命名约定来查找正确的安全角色是非常脆弱的。您将不可避免地遇到自然映射与真实映射不对应的情况。一些愚蠢的事情，比如你希望URL是"finbiz"，但它在AD中已经是"business-finance“--你是复制组并保持它们的同步，还是在你的应用程序中进行重新映射...？有时它就像"finbiz“和"FinBiz”一样简单。

在国际海事组织，最好从一开始就避免这种问题，例如，使用组"185“而不是"finbiz”或"business-finance"，或者其他一些您可以更好控制的键。

不管您是如何获得权限的，如果最终不得不缓存它，您将不得不处理过时的缓存数据。

如果您必须使用ldap，那么创建一个权限ou (或任何AD中"schema“的等价物)会更有意义，这样您就可以将任意实体映射到这些权限。缓存这些数据，你应该没问题。

编辑：

问题的一部分似乎是为了避免中间数据库-为什么不让中间数据库成为主要数据库？定期将本地权限数据库同步到AD (通过挂钩或轮询)，您可以避免两个重要问题: 1)脆弱的命名约定；2)外部数据源关闭。

Answer 3

除非你实现了某种类型的缓存，否则你的页面会非常慢(在我看来，每次用户导航以确定他能做什么时，你都会重新查询AD LDAP )，但随后你可能会遇到不稳定的权限问题(在你不知道的情况下，撤销/添加了AD上的权限)。

我会保持权限等分离，而不是使用AD作为存储库来管理您的应用程序特定授权。取而代之的是使用单独的存储提供程序，它将更容易维护和根据需要进行扩展。