问题标签 [authz]

介绍

我们的 apache2 设置使用 webdav 提供来自各种文件夹的文件，并使用 authz_dbd 与 mysql 数据库通信（这部分工作没有问题）。

总结：Apache2、mod_authz_dbd、mod_authn_dbd、mysql、启用webdav、多用户环境（物联网节点）。

但是......其中一些文件夹是用户特定的。

我们使用带有通配符的 dbd-groups，类似于：

并且通常都写在 vhosts 文件中

问题

这变得太大了，我们需要另一个修复。

我们不能将 .htaccess 文件与 dbd 组结合使用（.htacces 中不允许使用 dbd 组）。我们的 debian (jessy) 不允许其他 mysql apache2 mods。

.htaccess 文件与 dbd 的 mysql 授权的组合不起作用（.htaccess 中不允许 dbd 组）。我们的 debian 服务器不允许其他 mysql apache2 mods（如 mod_auth_mysql）。

如何将 mysql 授权与文件夹特定用户结合起来？

我有一个使用 KeyRock、PEP、PDP(AuthZForce) 的应用程序。

Keyrock 和 PEP 的安全级别 1（身份验证）正在工作，但是当我们尝试使用 AuthZForce 检查授权时，我收到错误消息：

我有我的用户和我按照 Fiware IdM 用户和程序员指南中的步骤创建的应用程序。

我还可以按照 AuthZForce - Installation and Administration Guide 中的说明创建域，但我不知道在创建域 ID 时如何将域 ID 与用户角色绑定。

那么，如何在特定域下插入用户/组织/应用程序，然后获得安全级别 2？

我的 config.js 文件：

我的 docker-compose.yml 文件是：

这个问题与AuthZForce Security Level 2: Basic Authorization error "AZF domain not created for application"相同，但我得到同样的错误，我的 keyrock 版本是 v5.4.0。

我正在尝试使用 KeyRock idm、Wilma PEP-Proxy 和 AuthZForce PDP over Docker 来保护 Orion Context Broker。目前，1 级安全性运行良好，我可以拒绝未登录用户的访问，但在尝试添加 2 级时，我在 Wilma 上收到此错误。

这是我在 Wilma 的 config.js 文件中的 azf 配置：

这就是我在 KeyRock 上设置访问控制配置的方式：

我已经在 Keyrock 上创建了自定义策略，但是 AuthZForce 日志没有显示来自 KeyRock 或 Wilma 的任何请求，因此没有在 PDP 上创建域。我检查了所有容器都可以看到并相互访问，并且所有端口都已启动。我可能缺少一些配置。

这些是我正在使用的版本：

这个问题与“未为应用程序创建 AZF 域”AuthZforce 相同，但即使使用所示的 AuthZForce GE 配置，我的问题仍然存在。

我在 AuthZForce PDP 的域中创建了此策略：

回应是：

所以我知道该政策是在 PDP 中定义的。

但是，当我对 PDP 域运行此请求时，不会评估该策略，只有默认的 allow-all：

回复：

为什么是这样？

我正在使用 Fiware 开发一个新应用程序，并且我有兴趣为此使用特定的 Fiware GE 添加一个安全层：

• IdM Keyrock
• 威尔玛 PEP 代理
• AuthZForce PDP

从本教程开始，我首先设置了我自己的这些组​​件的本地安装。几分钟后，我能够成功安装并运行所有三个组件。

然后我开始创建应用程序、角色、权限、为用户分配角色等等。事情是在玩了一段时间后 AuthZforce 组件崩溃了，我不得不重新启动它。之后，我注意到所有策略和域都从 AuthZForce 中删除。

我做了一些挖掘，发现所有的东西都保存在内存中供 AuthZForce 使用，也保存在 IdM 数据库中，所以如果你的 AuthZForce 崩溃，那么你会丢失所有的策略和应用程序域，除非你从 IdM 数据库中恢复它。

问题是当您重新启动 AuthZForce 时，存储在 IdM 数据库中的所有策略和应用程序不会自动与 AuthZForce 同步。要强制同步，您必须对应用程序进行一些更改，例如使用 IdM Web 界面更改应用程序描述。然后 IdM 重新创建应用程序域和所有应用程序策略。

有什么理由会这样吗？为什么同步没有自动完成？AuthZForce 本身能否负责策略的持久性？

我在 CentOS 7.4 上托管了 apache subversion 1.7.14，并且在获取基于路径的授权时遇到问题，这样一个特定分支的受限组可以从 apache Web 服务器导航到该分支。

示例结构是：

我有几组用户，例如：

我的目标是将 svn-group2 明确限制在 /svn/repo/projA/branches/branch1 并且不能访问任何其他分支，例如：

但是，当导航到https://svn.example.com/repo/projA时，svn-group2 用户将收到一个禁止错误。只有当他们访问完整的 URL https://svn.example.com/repo/projA/branches/branch1时，他们才能获得访问权限。理想情况下，我希望 svn-group2 看到所有父级的叶子到根目录，以便他们“知道”他们可以从https://svn.example.com访问什么。

我可以通过明确排除每个兄弟叶子来获得正确的行为：

这甚至有利于用户甚至看不到来自https://svn.example.com/repo的 projB 和 projC 的链接。只会看到 projA，然后是分支，然后是 branch1。

但是，这并不能保证 svn-group2 只会看到 branch1。我想保证如果 svn-group1 创建了一些新的分支， svn-group2 默认不会看到这个。

我发现了一些带有通配符功能的 :glob: 规则的提示，但我无法让它工作。我可以想象像下面这样的事情，其中​​通配符不包括兄弟分支。

谢谢！

我们的系统正在从单体架构转变为微服务架构。微服务架构带来了我们需要解决的技术挑战，其中之一就是 AuthN/AuthZ。

我们的方法是使用身份验证服务来验证用户并生成访问/刷新令牌 (JWT)。然后访问令牌将通过微服务链在请求标头中传递，这样每个微服务只需验证令牌即可确定用户已成功通过身份验证。对于 AuthZ 部分，权限执行是在微服务本身中完成的。我的问题与 AuthZ 有关。

为了说明这个话题，让我们举一个具体的例子，一个接待员想要注册一个新成员到他的保真程序，例如从一个 Web 应用程序。为了支持这个用例，我们假设系统有 2 个微服务，ReceptionService 和 MemberService。ReceptionService 提供一个 REST API 来启动成员注册流程。它需要用户权限“注册”才能执行。MemberService 提供一个 REST API 来创建受 CRUD 权限保护的新成员资源。请求流将是：

1. 用户先前登录的 Web 应用程序向 ReceptionService API 发送成员注册请求，其中包括标头中的用户访问令牌。
2. ReceptionService 验证用户令牌，确保用户被授予“注册”权限，执行它需要执行的任何业务逻辑，最后向 MemberService API 发送一个成员创建请求，包括头部中的用户访问令牌。
3. MemberService 验证用户令牌，确保授予用户“member.create”权限，最后创建成员。

为了为这种情况设计解决方案，我的团队致力于以下假设/先决条件：

• 微服务必须始终强制执行权限（至少对于重要的 API 操作，例如创建成员）。因此，即使产品经理可能只需要顶级“注册”权限，上例中 MemberService 的 CRUD 权限也是如此。
• 因为具有“顶级”权限而能够启动用例的用户必须能够完成它。含义它不会因为他缺少来自底层服务调用链中某处的另一个权限而出错。
• 管理员用户不必了解执行用例所需的权限链。在我们的示例中，管理员应该只能向用户提供“注册”权限。

为了能够完成上述示例，需要为用户分配 2 个不同的权限，这打破了我们的一些假设/先决条件。为了克服这个问题，我的一位同事建议考虑在我们的 AuthN 系统中将微服务声明为身份/用户，以便为它们分配适当的权限。然后，最初提供的用户令牌将被调用链中的参与服务令牌替换。回到这个例子，新的请求流程是：

1. 用户先前登录的 Web 应用程序向 ReceptionService API 发送成员注册请求，其中包括标头中的用户访问令牌。

2. ReceptionService 验证用户令牌，确保授予用户“注册”权限，执行它需要执行的任何业务逻辑，最后向 MemberService API 发送一个成员创建请求，在标头中包含它自己的服务令牌（因此替换原始用户令牌）。

3. MemberService 验证服务令牌，确保服务被授予“member.create”权限，最后创建成员。

使用此解决方案，AuthN 系统中的服务身份将被标记为从管理权限分配的管理员用户中过滤出来。服务身份的权限分配将是预先定义的，用户无法对其进行配置。虽然它满足了我们的假设/先决条件，但我对这种方法几乎没有担忧：

• 在处理“谁做了什么”（审计）时，令牌中提供的用户身份和服务身份将被冷淡列出。在我们的示例中，RegistrationService 将审核发起操作的实际用户，但 MemberService 将审核该操作是由“RegistrationService”执行的。在报告场景中，这意味着我需要协调来自两个系统的审计，以确定“谁实际创建了成员”，以某种方式使用关联 ID。
• 虽然我了解在不涉及实际用户的情况下需要为系统组件创建身份（自动批处理/第三方访问..），但在以下情况下我不习惯用服务令牌替换用户令牌用户实际启动了用例。这是标准的设计模式吗？

会不会是我们的一些假设/先决条件错了？

• 例如，某些微服务即使仅
  在安全环境中由其他受控微服务访问，也不会强制执行权限，这真的是一个安全漏洞吗？假设
  后者的答案是“不，这不会是一个安全漏洞”，那么如果明天，我需要让 MemberService API 也可以
  在安全环境之外访问（例如，因为我将它
  提供给第三方派对）。我很可能需要对其添加
  权限，这会破坏我的注册流程。
• 说我们确实希望管理员用户知道
  用例需要哪组权限并且我们应该
  构建系统以便它优雅地处理由于调用链中缺少一个权限而导致的失败是错误的（可能使用 Sagas 和补偿
  程序）？

任何评论或资源链接将不胜感激。谢谢！

我正在开发 Go 中的授权插件，但我坚持使用它。当我向 localhost 上的 Docker 引擎发送命令时，我得到了 RequestURI 和 RequestBody，但没有得到发送请求的用户。这是一个空字符串。

使用上面的代码，我希望日志中出现“已授权”文本，但我看到“未授权”并且用户名为空。

有人能帮我吗？

我正在尝试使用 Keycloak AuthzClient 在资源服务器中注册资源和相​​关权限。

我有一个启用了 authz 服务的资源服务器“resourceserver”。

使用 AuthzClient，使用包含资源服务器的客户端 ID 和机密的 json 文件进行初始化，我可以获得一个 pat。

执行此代码后，我可以在 keycloak 管理 UI 中看到已创建资源和范围，但似乎没有显示策略/权限。

我相信这可能是有意的，因为这个 keycloak 管理 UI 只显示类型为客户端、角色、js 等的策略，而不是 UmaPermissionRepresentation 创建的“uma”。

authz/protection/uma-policy但是，通过使用我的 pat查询，我可以看到 Keycloak 中存在该策略。

所以那里有东西。现在测试它。我创建了一个普通用户并为其分配了领域角色somerole。使用这个用户和一些任意的公共客户端，我可以获得一个 RPT。

首先使用密码授权获取访问令牌：

grant_type=password&username=joe&password=password&client_id=somepublicclient

然后将其交换为 RPT：

grant_type=urn:ietf:params:oauth:grant-type:uma-ticket&audience=resourceserver

RPT 回来了，如果我查看它的内容，我可以看到授权块让我可以访问 myresource 资源。

somerole但是，当我尝试使用服务帐户（我也授予角色）使用客户端凭据流来获取初始访问令牌的类似流程时：

grant_type=client_credentials&client_id=serviceaccount1&client_secret=77c1ffa8-0ea8-420c-ad45-e1a69a03838d

我能够获得一个 RPT，但该 RPT 在授权/权限块中不包含 myresource，只有默认资源。

我一直试图理解为什么会这样。我也尝试过在 UmaPermissionRepresentation 中使用.addClient("serviceaccount1") or .addUser("service-account-serviceaccount1")，但是，该策略似乎没有生效，我的服务帐户无权访问该资源。

这是使用 Keycloak 4.8.0.Final。

注意：使用 keycloak 管理客户端，我可以创建实际执行此操作的策略/权限；但在我的环境中，这会导致其他问题，因为我需要分配给管理客户端的角色（例如查看所有客户端以检索 id 等）

背景

多年来，我一直在我的 Windows 内部网上运行svnserve版本 1.8.17 配置管理软件，现在有 10 台 PC。PC 使用 TortoiseSVN 作为客户端。现在我需要添加另一个只能访问子文件夹的用户。这意味着更改authz文件。

问题

当我添加authz文件的路径时，我收到错误Invalid authz configuration。这是我经过清理的authz文件：

以下是我清理过的路径：

以下文本取自Subversion 文档页面 xxii，说明我的路径语法是正确的：

为保持一致性，本书中的示例假定读者使用的是类 Unix 操作系统，并且对 Unix 和命令行界面比较熟悉。也就是说，svn 程序也可以在 Microsoft Windows 等非 Unix 平台上运行。除了一些小例外，例如使用反斜杠 () 而不是正斜杠 (/) 作为路径分隔符，此工具在 Windows 上运行时的输入和输出与 Unix 对应的相同。

我无法找出那些“小例外”是什么。

问题

还有另一种有效的语法吗？还是这些年来这真的是一个错误？