Questions tagged «authorization»

我试图了解访问控制（授权）时角色和权限之间的固有权衡。 让我们从一个给定的开始：在我们的系统中，“ 权限”将是一个细粒度的访问单位（“ 编辑资源X ”，“ 访问仪表板页面 ”，等等）。一个角色将是1 +权限的集合。一个用户可以具有1个以上的角色。所有这些关系（用户，角色，权限）都存储在数据库中，可以随时根据需要进行更改。 我的担忧： （1）检查用于访问控制的角色有何“坏处”？通过检查权限可获得什么好处？换句话说，以下这两个摘要有什么区别： if(SecurityUtils.hasRole(user)) { // Grant them access to a feature } // vs. if(SecurityUtils.hasPermission(user)) { // Grant them access to a feature } 和： （2）在这种情况下，角色甚至可以提供什么有用的价值？我们不能直接为用户分配1+权限吗？角色提供什么抽象的具体价值（有人可以提供具体示例）吗？

44 security  permissions  authorization  access-control  roles 

前景 我们正在从单一平台过渡到更加面向服务的体系结构。我们正在应用非常基本的DDD原则，并将我们的域划分为不同的有界上下文。每个域都是分布式的，并通过Web API（REST）公开服务。 由于我们的业务性质，我们提供诸如订舱，服务，客户，产品等服务。 我们还建立了一个Identity Server（基于Thinktecture Identity Server 3），其主要作用是： 集中身份验证（给定颁发令牌的凭据） 在令牌中添加声明，例如：客户范围（按照客户，我是指执行请求的应用程序），客户标识符（按照客户，我是指使用该应用程序的人） 我们还介绍了API网关的作用，它可以集中外部访问我们的服务。API网关提供的功能不需要深入了解内部域，例如： 反向代理：将传入请求路由到适当的内部服务 版本控制：API网关的一个版本映射到内部服务的不同版本 身份验证：客户端请求包括由Identity Server发行的令牌，API网关会验证令牌（确保用户说的是她的身份） 节流：每个客户端的请求数量限制 授权书 与授权有关，这不是在API网关中管理，而是在内部服务本身中进行管理。我们目前正在执行两种主要的授权类型： 基于客户范围的授权。示例：客户端（使用我们的API的外部应用程序）需要范围“ bookings”来访问Bookings服务API端点 基于客户的授权。示例：仅当客户（使用应用程序的自然人）是预订的参与者时，才能从预订服务访问端点GET / bookings 为了能够处理内部服务中的授权，API网关仅转发令牌（在将请求路由到内部服务时），该令牌既包含有关客户端（执行请求的应用程序）的信息，也包含有关客户的信息（作为声明）有人在客户端应用程序中登录的情况）。 问题描述 到目前为止，到目前为止还不错，直到我们引入了服务间通信（某些服务可以与其他服务进行通信以获得一些数据）。 题 在服务间通信中，我们应该如何处理授权？ 考虑的选项 为了讨论不同的选项，我将使用以下示例方案： 我们有一个名为ExternalApp的外部应用程序，该应用程序访问我们的API（可以将ExternalApp视为客户端），以建立预订流程 ExternalApp需要访问预订服务，因此我们授予ExternalApp范围“预订” 在内部（这对于ExternalApp来说是完全透明的），预订服务使服务服务获得预订的默认服务，例如航班，保险或租车 在内部讨论此问题时，会弹出几个选项，但我们不确定哪个选项最好： 当Bookings与Services通信时，它应该只转发他从API网关收到的原始令牌（表明客户端是ExternalApp）。 启示：我们可能需要将不应该被授予的范围授予ExternalApp。示例：ExternalApp可能需要同时具有“预订”和“服务”范围，而只有“预订”范围才足够 当Bookings与Services通信时，它转发一个令牌，指示该客户端现在已成为Bookings（而不是ExternalApp），并且添加了一个声明，表明Bookings模仿了原始客户端ExternalApp 通过还包括原始客户端是信息ExternalApp的服务业务也可以做逻辑如过滤取决于原调用一些服务（如用于内部应用程序，我们应该返回所有的战斗，外部应用程序只有一些） 服务不应相互通信（因此我们甚至不应面对这个问题） 预先感谢您的输入。

18 api  microservices  soa  authorization 

我在HTTP标头中使用JWT令牌来验证对资源服务器的请求。资源服务器和身份验证服务器是Azure上的两个单独的辅助角色。 我不能决定应该将请求存储在令牌中还是将请求附加到请求/响应中。Claims列表影响客户端UI元素的呈现以及对服务器上数据的访问。因此，在处理请求之前，我想确保服务器收到的声明是真实的并经过验证的。 声明示例包括：CanEditProductList，CanEditShopDescription，CanReadUserDetails。 我要为其使用JWT令牌的原因是： 更好地防止客户端对声明进行编辑（即入侵声明列表）。 无需在每个请求上查找索赔。 我不想使用JWT令牌的原因： 然后，身份验证服务器必须知道以应用程序为中心的声明列表。 令牌成为黑客入侵的单一点。 我读过几句话说，JWT令牌不用于应用程序级数据。 在我看来，两者都有缺点，但是我倾向于将这些声明包含在令牌中，并且只想由以前处理过此问题的人员来处理。 注意：我将对所有API请求使用HTTPS，因此在我看来，令牌将“足够”安全。我正在使用AngularJS，C＃，Web API 2和MVC5。

18 security  http  authentication  authorization 

我正在设计一个通过API密钥使用授权/身份验证的REST API。 我试图找出最合适的位置，然后发现许多人建议使用自定义HTTP标头ProjectName-Api-Key，例如： ProjectName-Api-Key: abcde 但在Authorization标头上使用自定义方案也是可能的，从思想上来说也是正确的，例如： Authorization: ApiKey abcde 另一方面，我发现一个考虑，自定义授权方案可能出乎意料，并且不受某些客户端支持，并且无论如何都会导致自定义代码，因此最好使用自定义标头，因为客户对此没有任何期望。 您希望以哪种方式发送API密钥？

17 rest  api  authentication  authorization  headers 

我正在研究一个小型应用程序，试图掌握域驱动设计的原理。如果成功，这可能是一个更大项目的试验。我正在尝试遵循《实现域驱动的设计》（由Vaughn Vernon撰写）一书，并试图实现一个类似的简单讨论论坛。我还在github上签出了IDDD示例。我在采用身份和案件访问权方面遇到一些困难。让我给出一些背景信息： 我（希望）理解了将用户和权限逻辑分开的原因：这是一个支持域，并且是一个不同的有界上下文。 在核心域中，没有用户，只有作者，主持人等。这些是通过使用服务延伸到“身份和访问”上下文，然后将接收到的User对象转换为and主持人而创建的。 以相关角色作为参数调用域操作：例如： ModeratePost( ..., moderator); 域对象的方法检查给定的主持人实例是否不为空（如果从“身份和访问”上下文中询问的用户不具有主持人角色，则主持人实例将为空）。 在一种情况下，它会在更改帖子之前进行另一项检查： if (forum.IsModeratedby(moderator)) 我的问题是： 在后一种情况下，安全性关注点是否不会再次混入核心域？以前，这些书指出“可以与谁一起发布主题，或者在允许的条件下发布。论坛只需要知道作者正在这样做”。 本书中基于角色的实现非常简单：当主持人是核心域时，它会尝试将当前的userId转换为主持人实例，或在需要时将其转换为作者。服务将以适当的实例进行响应；如果用户没有所需的角色，则该服务将为null。但是，我看不到如何适应更复杂的安全模型。我正在尝试的当前项目具有一个包含组，ACL等的相当复杂的模型。 即使规则不是很复杂，例如：“帖子只能由其所有者或编辑者编辑”，但这种方法似乎无法使用，或者至少我看不到实现该方法的正确方法。 通过向Identity and Access上下文询问OwnerOrEditor实例并不适合，我最终会在核心域中得到越来越多与安全性相关的类。另外，我不仅需要将userId传递给安全上下文，还需要将受保护资源的标识符（帖子，论坛等的ID）传递给安全性上下文，该上下文可能不关心这些事情（对吗？ ） 通过将权限拉到核心域并在域对象的方法或服务中检查它们，我将得出结论：将安全问题与域混合在一起。 我在某个地方读过（并且我倾向于同意），这些与权限相关的事物不应成为核心域的一部分，除非安全性和权限是核心域本身。像上面给出的那样简单的规则是否足以使安全性成为核心域的一部分？

16 domain-driven-design  authorization  permissions  implementations 

我们计划将公司系统重构为基于微服务的系统。该微服务将由我们自己的公司内部应用程序以及需要的第三方合作伙伴使用。一种用于预订，一种用于产品等。 我们不确定如何处理角色和范围。这个想法是创建3个基本用户角色，例如Admins，Agent和End-Users，并让消费者应用程序根据需要微调作用域。 管理员可以默认（针对其公司）创建，更新，读取和删除所有资源。 代理可以为其公司创建，更新和读取数据。 最终用户可以创建，更新，删除和读取数据，但不能访问与代理或管理员相同的端点。他们也将能够创建或修改数据，而不必与代理或管理员处于同一级别。例如，最终用户可以更新或阅读他们的帐户信息，就像代理可以为他们完成此操作一样，但他们看不到或更新管理员注释。 假设代理默认情况下可以为其公司创建，读取和更新每个资源，这是可以为其令牌/会话请求的最大范围，但是客户端（API使用者）应用程序的开发人员已决定他们的代理之一可以仅读取和创建某些资源。 更好的做法是在我们的内部安全性中处理此问题，然后让他们在数据库中写入该数据，还是让客户端通过请求范围较小的令牌在内部进行处理，并让他们编写哪个代理在数据库中具有哪个范围？这样，我们仅需跟踪令牌范围。 不利的一面是，我们的团队还需要在内部应用程序中创建经过微调的访问机制。 用这种思维方式，微服务及其授权系统不应受到客户需求的困扰，因为它们只是消费者，而不是系统的一部分（即使其中一些消费者是我们自己的内部应用程序）？ 这是一个好的方法吗？

15 security  authentication  microservices  authorization 

我试图遵循基于角色的访问控制模型来限制用户在系统中可以执行或不能执行的操作。 到目前为止，我具有以下实体： 用户 -将使用该系统的人员。这里有用户名和密码。 角色 -用户可以拥有的角色的集合。诸如经理，管理员等 资源之类的东西-用户可以操纵的东西。像合同，用户，合同草稿等 操作 -用户可以使用资源执行的操作。像创建，读取，更新或删除。 现在，我在图中有这样关系的地方对此表示怀疑： 操作（0 .. *）在 资源（0 .. *）上执行，该资源生成一个名为权限的表，该表将存储该操作和资源。 权限表如下所示（它的一行）： ID： 1，操作：创建，资源：合同。 这意味着许可，以创建一个合同。 我这样做是因为我觉得某些资源可能无法进行各种操作。例如，对于注册合同，用户可以上传文件，但是此操作不适用于注册提供商。 所以，现在当管理员将被赋予权限的角色，他不会有资源的清单，在系统中注册的每一个操作。 我认为每种资源都有自己的可以在他身上执行的操作的集合。 我可以澄清一下某些事情是无法理解的。 这是实施rbac的正确方法吗？ 编辑 我的意思是，通过拥有一个包含操作和资源的权限表，我有了两个额外的表，因为我想将资源与操作相关联。我本来也可以完成资源具有权限的权限，权限表将存储这些权限。 但是然后发生的是，当管理员分配资源时，某些权限甚至对于某些资源都不存在。 因此，我想从数据库设计的角度来了解具有一个列操作和另一个资源的表权限是否正确？如果这样下去我会遇到问题吗？

15 database-design  authorization  permissions  access-control  roles 

按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 6年前关闭。 我正在考虑限制选择不安全密码的用户的权限（密码的不安全性由长度，使用的字符类型（大/小写，数字，符号等）决定，是否可以使用）。 （位于彩虹表中）以限制帐户遭到破坏后所造成的损失。 我还没有这个想法的申请，但是说我正在写一个论坛之类的东西：使用1234作为密码的用户可能必须在发布前填写验证码，否则将受到诸如此类的严格反垃圾邮件措施的约束。作为超时或贝叶斯过滤器拒绝其内容。如果此论坛是非常分层的，允许“提升”主持人或通过某种方式进行的其他活动，这将阻止他们完全获得特权或告诉他们他们具有特权，但不允许他们在不进行任何更改的情况下行使其特权。密码。 当然，这不是唯一的安全措施，但是它可以很好地替代其他良好的安全做法。 你怎么看？这是否只是做的太过分，将注意力从更重要的安全实践上转移了下来，还是限制风险并鼓励用户使用更安全的密码的一种好方法（并希望说服您正在使用良好的安全实践的人们）？

13 security  passwords  authorization  risk  permissions 

我想实现一个更强大的身份验证服务，这jwt是我要做的事情的很大一部分，而且我了解如何编写代码，但是在理解保留iss与aud声明之间的区别时遇到了一些麻烦。我知道，一个定义了颁发令牌的服务器，而一个则引用了打算使用的应用程序。但是我的理解是，我的听众和发行人是同一件事，myserver.com就是发行令牌，以便以后的人们myserver.com可以得到授权和认证。我想我看不到两种说法之间的区别，尽管我知道有一种。 有一篇很好的文章写在msdn 关于所有保留的索赔，这是我最困惑的地方，因为他们的发行人和受众完全不同。

13 security  authentication  authorization  jwt 

微服务是否应该负责处理自己的授权，或者您认为最好有一个单独的授权服务，该服务在微服务的全部或子集（在同一业务域内）共享？ 对我而言，后者更有意义，因为它使更改，执行策略变得更加容易。它是DRY等。但是，通过各种将其规则转储到一个地方的服务，它也很容易失控，并且还担心网络开销。 有什么想法吗？

12 architecture  authorization  microservices 

我正在阅读Web应用程序中的身份验证/授权。有人可以确认/纠正我目前的知识吗？ Cookies：在其早期版本中，具有唯一客户端的文本文件会标识与该客户端有关的所有其他信息（例如角色） 会话：只有唯一的客户端ID在文件中发送（也称为Cookie），其他所有内容都存储在服务器上 JWT：所有内容都存储在令牌中（也可以存储在文本文件中，也称为Cookie） 感谢您的任何反馈！

12 authentication  authorization  session  cookies  jwt 

Exchange 2010中有一个代表团模型，其中一组的WinRM的cmdlet的essentally分为角色，并分配给用户的角色。 （图片来源） 考虑到我如何利用PowerShell的所有优势，同时使用正确的低级技术（WCF，SOAP等），并且在客户端不需要任何其他软件，这是一个很好且灵活的模型。 （图片来源） 问题 我是否可以在.NET应用程序中利用Exchange的委派模型？ 有没有人试图模仿这种模式？ 如果必须从头开始，我将如何模仿这种方法？

9 c#  security  wcf  authorization  iis7