【问题标题】:classification of user population by access rights按访问权限对用户群体进行分类
【发布时间】:2018-01-10 04:13:08
【问题描述】:

我要做的是按员工的角色对他们进行分类 在一个组织中。这是通过获取所有权限来计算的,或者 访问列表,他们拥有目标企业软件。

可能有 10000 个用户和每个用户数十个权限。

编辑:当有大量用户时,绝大多数将具有有限的设置权限。例如,他们可能都只有Employee。更复杂的案例是高级用户,并且会更少。

另外,不要被我给出的权限名称所误导,例如 Acct1/Acct2,它们只是为了让您了解域。即使像您在许多 ORM 商店中看到的那样随机分配的主键整数,我正在寻找的解决方案在概念上也应该有效 - 权限之间存在 no 隐含关系。

import pprint
pp = pprint.PrettyPrinter(indent=4)

def classify(employees):
    """employees assigned the same set 
    of permissions are grouped together"""
    roles = dict()
    for user, permissions in employees.items():
        permissions = list(permissions)
        permissions.sort()
        key = tuple(permissions)
        members = roles.setdefault(key, set([]))
        members.add(user)
    return roles

everyone = {
    "Jim": set(["Employee","Acct1","Manager"]),
    "Marion": set(["Employee","Acct1","Acct2"]),
    "Omar": set(["Employee","Acct1"]),
    "Kim": set(["Employee","Acct1"]),
    "Tyler": set(["Employee","Acct1"]),
    "Susan": set(["Employee","Marketing","Manager"]),
}

result = classify(everyone)
print("pass1")
pp.pprint(result)

此时,分类系统返回如下:

{ ('Acct1', 'Acct2', 'Employee'): set(['Marion']), ('Acct1', 'Employee'): set(['Kim', 'Omar', 'Tyler']), ('Acct1', 'Employee', 'Manager'): set(['Jim']), ('Employee', 'Manager', 'Marketing'): set(['Susan'])}

由此,我们可以观察数据并手动为这些角色分配一些有意义的名称。

Senior Accountants - Marion
Accounting Managers - Jim
Accountants - Kim, Omar, Tyler
Marketing Manager - Susan

分配是手动的,但其目的是尽可能保持“粘性”,即使人们被雇用或离开以及权限发生变化。

让我们再做一遍。

有人决定将Acct2 重命名为SrAcct。人们被录用,Kim 离开。

这由以下员工权限表示:

everyone2 = { "Jim": set(["Employee","Acct1","Manager"]), "Marion": set(["Employee","Acct1","SrAcct"]), "Omar": set(["Employee","Acct1"]), "Tyler": set(["Employee","Acct1"]), "Milton": set(["Employee","JuniorAcct"]), "Susan": set(["Employee","Marketing","Manager"]), "Tim": set(["Employee","Marketing"]), }

这次的输出是:

{ ('Acct1', 'Employee'): set(['Omar', 'Tyler']), ('Acct1', 'Employee', 'Manager'): set(['Jim']), ('Acct1', 'Employee', 'SrAcct'): set(['Marion']), ('Employee', 'JuniorAcct'): set(['Milton']), ('Employee', 'Manager', 'Marketing'): set(['Susan']), ('Employee', 'Marketing'): set(['Tim'])}

理想情况下,我们会认识到这一点

Senior Accountants - Marion
Accounting Managers - Jim
Accountants - Omar, Tyler
Marketing Manager - Susan
new role - Tim
new role - Milton

Tim 的角色现在将命名为 Marketer,而 Milton 的角色将命名为 Junior Accountant

重要的是角色名称分配足够稳定,即使在人们被雇用和离开(最频繁)以及权限被添加或重命名(非常不频繁)时,也可以对员工群体进行推理。可以不时要求最终用户分配新的角色名称或在关系之间做出决定。但大多数时候,它应该运行顺利。它不应该猜错了什么,并错误地将一组用户标记为错误的角色名称。

我遇到的问题是它很容易引起注意,但是权限集和定义角色的用户集都可以更改。分类时间很重要,但是这种分类机制的价值会随着用户数量和权限的增加而增加。

我尝试提取“定义角色的权限子集”。例如,Employee 分配给每个人,因此可以忽略。而(Manager, Acct1)(Manager, Marketing) 唯一属于 Jim 和 Susan。麻烦的是,一旦您轻松解决了 20-30% 的案例并且它永远不会完成,就会出现组合爆炸。

我现在的想法是回溯并计算每一代的新员工权限角色分类,然后回溯以获得与上一代相比的模糊匹配“最佳匹配”。选择那些相当明确的并要求用户决定关系并根据需要分配新的角色名称。

例如,权限的完全匹配和员工的合理匹配意味着 'Omar', 'Tyler' 在第 2 次传递时仍然是 Accountants。另一方面,如果 Marion 离开而我拥有 "Jane": set(["Employee","Acct1","SrAcct"]),我会必须要求最终用户进行仲裁并将她识别为Senior Accountant

我过去曾与 Jaccard Similarity (https://en.wikipedia.org/wiki/Jaccard_index) 合作过,但我不确定它如何适用于双方都可以改变的情况 (Acct2 => SrAcct as以及员工变动)。

我很确定以前需要这种逻辑,所以我希望对算法和策略提出建议。

哦,我正在寻找可以在更大的 Python 应用程序的上下文中实现和推理的合理独立的方法。不适用于 机器学习 关于如何配置 TensorFlow 之类的工具来为我执行此操作的建议。不过,如果迫在眉睫,我可以调用一个批处理来进行匹配。

【问题讨论】:

    标签: python algorithm classification


    【解决方案1】:

    这就是我最终做的:

    1. 在计算新用户/访问权限集的分类之前,保存旧用户/访问权限及其分配的名称。

    2. 计算出新的分类后,找到新旧最接近的匹配,如果置信度足够高,则转移名称。

      • 完整的用户匹配?那么这是一场比赛。我将用户集转换为用户的排序元组以通过字典进行匹配。

      • 完全权限匹配?再次,这是一场比赛。再次,通过集合到排序的元组转换查找字典进行检查。

      • 对于每个未匹配的当前,我分别根据其用户和权限计算每个未匹配的先前的 Jaccard 相似度。因此,在不匹配的数量上可能会变成 O(N2)。将每个匹配项附加到该分类的列表中。按照得分的顺序对列表进行排序(来自下面的calc 函数),最后一步,只有在与下一个最接近的匹配有足够大的差异时才会自动选择一个。

    `

        class Match(object):
    
            #these are weighing coefficients - I consider roles/permissions more important because of the expected user churn.
            con_roles = .7
            con_users = .3
            con_other = .07
    
            threshold = .7
    
            def calc(self):
                #could have anything you want here, really.
                self.similarity = self.con_roles * self.simroles + self.con_users * self.simusers
    

    好的,我遗漏了很多内容,但基本上,您可以将一个简单的 Jaccard 相似性算法应用于用户和角色方面,并将这些数字放入一个合适的等式中,看看什么是最接近的匹配。如果不满意,作为最后的手段,要求用户再次分配名称。

    希望如果他们最终寻找类似的东西,这会有所帮助。

    【讨论】:

      【解决方案2】:

      您在这里真正创建的是一个单一的组织层次结构树。您的分组算法已经能够做到这一点。您不会在单个层次结构中显示它们,但它们可以很容易地以这种方式显示。

      您组织的“主观”部分决定何时将分支机构合并为一个组织角色是合适的,并决定在创建分支机构时按何种顺序对权限进行排序(即您是否希望拥有一个经理分支机构,下面有部门,或者你想要部门分支,每个分支都包含一个经理分支)。

      不幸的是,机器无法知道这些偏好。您将不得不做出所有这些决定,尤其是如果您需要 0% 的误报率。

      我能想到的向算法提供此偏好信息的最简单方法是为其提供一个有序的权限“权重”列表,它将在构建层次结构时使用。对于第一次通过,您可以按以下顺序对它们进行排序有多少人拥有该权限。您可能需要比一组有序权限更复杂的“权重”。对于更复杂的权重,您需要指定更复杂的“规则”来检查成员身份(或非成员身份) 在多个权限集中。

      第二位信息可能会以交互方式提供。给定整个组织结构图的显示,您可以选择应将哪些权限集组合成一个组织集。您还可以在此处为每个权限集组分配角色的显示名称。

      就能够响应雇佣/解雇而言,只要权限相同,这应该不是问题。至于添加和删除用户的权限,您必须存储以前的权限和分组,并将它们与每个用户的当前权限相匹配,以提示某人同意对角色权限集的更改,或者使用新权限。

      【讨论】:

      • 有趣。但请注意,每个员工只绑定一个role这里AccountantSenior Accountant 之间没有关系,因为它们没有相同的访问权限。所以他们处于不同的角色/桶中。我可以在角色之间进行基于 Jaccard 的匹配以实现相似性。或者直接比较它们。这已经完成并且有效。这里的重点只是在组织发生变化时保持那些用户分配的存储桶/角色名称稳定。这只是一个命名问题,而不是分层问题。
      • 是的,用户只能属于 1 个角色组。我认为考虑角色稳定性的一个好方法是决定忽略哪些差异。这是将组织视为层次结构的地方很有用,因为它允许您设置有关何时折叠和合并分支的规则。例如,您可以创建一个规则,其中任何会在下面创建分支超集 ([Acct1, Employee]) 的更改都会自动折叠到该角色中。
      • 看,我试图绕过规则的概念,只匹配用户角色分组数学上。在拥有 500 名员工的公司中,管理员将查看拥有 380 名用户的角色,并说“是的,这是我们的正式员工”角色。他们会看着吉姆说“他是一名会计经理”。经营良好的公司已经这样做了:会计部门的新经理?克隆参考现有会计经理的用户配置文件。如果我可以可靠地重新匹配角色名称,则无需了解“PYRARG”与“PYRBRZ”之类的权限的来龙去脉(客户通常会重命名)。
      【解决方案3】:

      这将是一个马马虎虎的答案,所以很抱歉,但你的问题非常广泛,需要一些逻辑而不是一些特定的代码。

      也许这个问题会更好地解决为“标签”?我的意思是,一个人可以同时是员工、营销人员和经理(我认为将拥有所有这三者的权限)。

      所以我建议一种不同的方法——而不是按照各自的权限对帐户进行分组,然后手动命名它们,首先对权限进行分类和命名(至少是其中更流行和稳定的),然后将每个员工分配给通过为每个员工提供封装多个权限的标签来正确(或多个)类别。

      然后,您将拥有很多未分类的用户或权限,但希望您可以要求用户为您进行一些分类(例如,描述他们的职位/权限)并在更小的范围内使用您的方法问题集。

      这样您就可以确保当新员工进入时,通过查看他的权限并决定他适合的位置,他会获得适当的标签。当员工离开时,这没有任何区别,因为他没有单独影响权限和标签。

      【讨论】:

      • 标签意味着可以将多个标签应用于一个对象。从某种意义上说,这些就是权限。这是任意的,不能真正“预先分类”。但是,当您将所有权限授予特定用户时,这会给他们一个独特的配置文件,您可以将他们作为一个组进行推理。例如,您可能只有具有Employee, Manager 权限的人。在这种情况下,您会根据Managers 而不是Managers AccountingManager Marketing 进行推理,因为它们会look the same 进入系统。
      • 重点是简化对庞大员工人数的推理。任何需要在个人员工层面进行手动准备和推理的系统都是不可行的。
      • 我不认为“标签”和权限是平等的,“经理”标签可以应用于一组 3 个单独的权限,所有这些权限都必须放在一起才能应用标签
      • 如果这对您的用例来说还不够,我很抱歉,我会删除我的答案吗?
      • 不,一点也不。这是一个相当广泛的问题的合理答案。如果你删除它,其他人也会有同样的想法。
      猜你喜欢
      • 1970-01-01
      • 2018-05-23
      • 2011-08-07
      • 2021-06-14
      • 2017-11-12
      • 2018-11-10
      • 1970-01-01
      • 2021-12-02
      相关资源
      最近更新 更多