ChatGPT解决这个技术问题 Extra ChatGPT

主题,用户和委托人之间的含义和区别是什么?

在安全框架的上下文中,通常会出现一些术语,即主体、用户和主体,我一直无法找到明确的定义和它们之间的区别。

那么,这些术语究竟是什么意思,为什么需要区分主体和主体?


T
T.Rob

它们是等级的,就像属、种和个体的等级一样。

主体 - 在安全上下文中,主体是请求访问对象的任何实体。这些是用于表示请求访问的事物和发出请求的事物的通用术语。当您登录应用程序时,您是主体,应用程序是客体。当有人敲门时,访客是请求访问的主体,而您的家是请求访问的对象。

主体 - 由帐户、角色或其他唯一标识符表示的主题子集。当我们达到实现细节的水平时,主体是我们在访问控制列表中使用的唯一键。它们可能代表人类用户、自动化、应用程序、连接等。

用户 - 通常指人工操作员的主体子集。随着时间的推移,这种区别变得越来越模糊,因为“用户”或“用户 ID”这两个词通常与“帐户”互换。但是,当您需要区分作为主体的广泛事物类别和以非确定性方式驱动事务的交互式操作符的子集时,“用户”是正确的词。

主题/对象继承自语法中使用的相同术语。在一个句子中,主语是演员,客体是被作用的事物。从这个意义上说,这种用途早在计算机发明之前就已经存在。在安全上下文中,主题是可以发出请求的任何东西。如上所述,这不必局限于 IT 安全,因此是一个非常广泛的分类。有趣的是,主体意味着客体。没有客体,就没有主体。

主体是主体解决的问题。当您出示信用卡时,您是主体,帐号是委托人。在其他情况下,您的用户 ID 或国家颁发的身份证明是您的委托人。但是主体可以与非人的许多类型的主体相关联。当应用程序请求系统级功能时,主体可能是已签名可执行代码模块的签名者,但即使在这种情况下,驱动请求的用户仍然是主体。

用户比主题或主体更具体,因为它通常指的是交互式操作员。这就是为什么我们有一个图形用户界面而不是一个图形主体界面。用户是解析为主体的主体实例。单个用户可以解析为任意数量的主体,但任何主体都应解析为单个用户(假设人们遵守不共享 ID 的要求)。在上面的例子中,一个可执行代码模块的签名者肯定不是用户,而是一个有效的委托人。试图加载模块的交互式操作员是用户。

正如评论中所指出的,即使是权威人士也不同意这些条款。在准备此回复时,我搜索了 NIST、SANS、IEEE、MITRE 和几个“准权威”资源,例如安全考试指南。我发现没有一个至少是准权威的单一来源涵盖所有三个术语,并且它们的用法都存在显着差异。这是我对如何使用这些术语的看法,但从实际的角度来看,当您在半夜仔细阅读手册时,定义往往是供应商或作者所说的任何内容。希望这里的回复能够提供足够的洞察力来导航水域并使用这些术语解析任何安全文档。


将事情分解为主题、主体、用户有什么好处,它的额外复杂性我们从这种额外的复杂性中得到什么好处?
选择正确的特异性水平的能力。这与我们从能够区分目的地与队列或主题中获得的好处相同。在分类学中不同级别的特异性之间进行选择的能力允许精确的表达,从而更好地将作者的意图传达给读者。在编程时,我们有一种奢侈/诅咒,CPU 只会以一种方式解释我们的指令,我们被迫使用它的精度级别。但在人类语言中,我们需要细微差别和精确度才能有效地传达意义。
T.Rob,太棒了,但你能澄清一下“用户 - 主体的子集”吗?如果 John 是主题,“account #123”是他的委托人,那么用户是谁?有两个约翰的吗?由于 Genus > Species > Individual 越来越具体,John(用户)应该比 John(主题)更具体。还是我错过了什么?
考虑两个主体,其中#123 是 John,#124 指的是服务帐户。我们可能希望在密码策略、登录功能等方面处理这些不同。“用户”类型的主体受密码复杂性和到期策略的影响,而“服务帐户”类型的主体甚至可能没有密码。当我们开始对主体类型进行分类时,我们会创建子集。这有帮助吗?还是我只是搅动了更多的泥浆?
是的,这有帮助。那么,具体来说,对以下内容有何更正?您可能希望将其复制并粘贴到 Notepad++ 之类的编辑器中,并在每个 John 之前放置一个 linebreak(因此不允许在评论中使用换行符):John (human) SUBJECT > username_1 PRINCIPAL > password_1 USER John (human) SUBJECT > username_1 PRINCIPAL > password_2 USER {3 } John (human) SUBJECT > username_1 PRINCIPAL > cellphone_1 USER
b
bluish

看看我的 Authentication concept map

https://i.stack.imgur.com/5bT0L.jpg


很酷的图表。但我既没有看到主题,也没有看到主体,也没有看到用户。这意味着,至少需要对图表进行一些评论。
对于那些寻找 Subject、Principal 和 User 节点的人来说,它们都在图表的底部附近。
C
Community

我认为该术语取自JAAS

当应用程序使用 JAAS 身份验证来验证用户(或其他实体,如服务)时,会创建一个 Subject 作为结果。 Subject 的目的是代表经过身份验证的用户。一个 Subject 由一组 Principal 组成,其中每个 Principal 代表该用户的一个身份。例如,一个 Subject 可以有一个名字 Principal(“Susan Smith”)和一个社会安全号码 Principal(“987-65-4321”),从而将该 Subject 与其他 Subject 区分开来。


这个定义我以前看过,太密集了,能不能详细说明一下,特别是用户和委托人有什么不同,为什么使用主题这个词而不仅仅是用户。如果这些术语具有超越 JAAS 的含义,我非常想熟悉该含义,如果这些术语是 JAAS 的发明,那么我猜创建它的 Sun 工程师为这些概念的含义选择了糟糕的名称。我问过不少程序员这个问题,都没有得到明确的答案,似乎每个人对这些术语的理解都不一样。
似乎校长只是识别主题的一种方法。换句话说,理论上任何 Principal 都可以作为用户数据库的主键。
该词典远远早于 JAAS。 JAAS 只是重用了其中的一部分,而且有时以非标准方式重用。引发这个问题的部分问题是,这些概念是从使用术语的上下文中学习的,然后以稍微不同的方式重用。当权威来源难以找到或被忽略时,含义会随着时间的推移而漂移。当涉及到精度是绝对要求的安全性时,这种模糊性会降低我们构建和实施安全设计的能力。
@T.Rob 你有什么论文题目,或者你可以分享的权威参考资料吗?
不幸的是,即使是权威人士也不同意。 SANS 根本没有定义主体或主体bit.ly/hl4rUP,而 NIST bit.ly/fE7NJs 将主体专门定义为一个人。其他“权威”来源同样含糊不清,考虑到该领域的明确性的重要性,这相当令人失望。 IEE 有一个词汇表,但您只能通过会员资格或订阅才能阅读它,因此它在与广大受众的讨论中使用有限。我的回答部分基于 Shon Harris 的 CISSP 考试指南。
r
rahulmohan

主题是请求服务的实体。它可以是用户或进程。可能这就是为什么选择名称主题而不是用户的原因。

当主体尝试访问服务时,必须首先对主体进行身份验证。成功的身份验证以加载该主题的安全主体结束。例如,在基于角色的访问控制系统中,经过身份验证(登录)的用户通常有两个主体 - userId 和 roleId。在这样的系统中,特权(即谁可以访问什么)是为角色和用户指定的。在授权期间(即检查是否应允许请求的服务),安全系统将检查两个主体的可访问性。

因此,从授权的角度来看,主体是允许或不允许访问的实际实体。主题只是一个拥有一些主体的用户/线程/进程。


每个主题有多个原则有什么好处?
我可以想到两个好处:(1)考虑用户 Alice 的主体 UserId("Alice")、Role("Manager")、Department("Sales") 访问服务(对象)。然后可以将服务访问控制指定为“允许角色(经理)”或“禁止部门(销售)”等,而不是指定 Alice 是否可以访问它。这种访问控制系统更易于管理,因为安全管理员不需要为所有用户指定所有服务的访问权限。
(2)在企业系统中,用户通常需要经过多个系统的认证才能执行某些复合服务。可能会发生这些系统中的每一个都有自己的访问控制机制,需要不同的详细信息——一个系统使用 SSN,而另一个系统使用 userId。因此,同一个主体应该拥有两个主体才能访问两者
我觉得 99% 的与这个术语的混淆可以用一句话来解决,“校长基本上是一个群体”。
?! ...为什么你说校长是一个组?
R
Rafael

正如 T.Rob 所解释的,Subject 是任何请求访问对象的实体。从那时起,我发现了一条关于 javax.security.auth.Subject 代码的评论,我发现它非常有用且易于理解:

“主体可能有多个身份。每个身份都表示为主体中的一个主体。主体只是将名称绑定到主体。例如,碰巧是人的主体,爱丽丝,可能有两个主体:一个绑定“ Alice Bar”,她的驾驶执照上的名字,与主题,另一个绑定,“999-99-9999”,她的学生证上的号码,与主题。两个校长都指的是同一个主题,即使每个校长有不同的名字。”

希望能帮助到你。


f
fgul

这是来自 Oracle JAVA SE 文档的以下解释的 link

主题、主体、身份验证和凭据 要授权对资源的访问,应用程序首先需要对请求的来源进行身份验证。 JAAS 框架定义术语主题来表示请求的来源。主体可以是任何实体,例如人或服务。主题由 javax.security.auth.Subject 类表示。身份验证表示验证主体身份的过程,并且必须以安全的方式执行;否则,犯罪者可能会冒充他人来访问系统。身份验证通常涉及主体展示某种形式的证据来证明其身份。此类证据可能是只有主体可能知道或拥有的信息(例如密码或指纹),也可能是只有主体可以产生的信息(例如使用私钥签名的数据)。一旦通过身份验证,Subject 就会填充相关的身份或主体(类型为 java.security.Principal)。一个 Subject 可能有许多 Principal。例如,一个人可能有一个名字 Principal(“John Doe”)和一个 SSN Principal(“123-45-6789”),这将其与其他 Subject 区分开来。除了关联的 Principal 之外,Subject 还可能拥有与安全相关的属性,这些属性称为凭证。凭证可能包含用于对新服务的主体进行身份验证的信息。此类凭据包括密码、Kerberos 票证和公钥证书。凭证还可能包含使主体能够执行某些活动的数据。例如,加密密钥表示使主体能够签署或加密数据的凭据。公共和私有凭证类不是核心 J2SE API 的一部分。因此,任何类都可以代表一个凭证。


尽管我同意 T.Rob 的回答,但来自 Aram 的这个回答——它说“一个主题可能是任何实体”——暗示了 ERM:支持大多数数据库的实体关系模型。在该模型中,“实体”对应于安全上下文中的“主体”,但根据您所建模的内容,它可能是主体(银行账户、SSN #)或用户(John Smith),正如 Marinus 中所建议的那样' 回答。维基百科:en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
C
ChinaJavaDeveloper

根据 rahulmohan 的说法,我认为,在 Authentication 是 subjet 之前,在 Authentication 是 pricipal 之后,在不同的意义上,一个 subjet 可能有很多 pricipal