Product-apim: 支持订阅者的基本身份验证

新发布的 APIM 3.0.0 确实支持 Basic Auth。 我们目前在我们的环境中使用它。

是的后端端点。 对于 Api，我找不到选项。

API 发布者 -> 运行时配置 -> 应用程序级安全

@Tomas-Mrazek 正确，现在我们也支持 API 客户端的基本身份验证。 您可以在应用程序级安全性下启用Basic选项，如上所示。 这将允许 API 使用者使用他们的用户名密码组合调用此 API。

好吧，看来我在看同一个地方。 刚刚测试了它，它的工作原理。

这带来了更多的问题。

订阅如何与基本身份验证一起使用？ 似乎任何用户都可以独立于订阅调用任何 Api？ 有没有办法将用户“分配”给特定的应用程序，以便他们只能调用订阅了应用程序的 API？

如果 Prod 和 Sandbox 共享同一个网关，那么在进行基本身份验证时如何确定调用哪一个？

如果我们在基本身份验证中使用应用程序密钥和应用程序机密而不是用户名和密码，那么这两个问题就不需要答案了。

也许我遗漏了一些东西，所以如果你能指出我的文档会很好。

订阅如何与基本身份验证一起使用？ 似乎任何用户都可以独立于订阅调用任何 Api？ 有没有办法将用户“分配”给特定的应用程序，以便他们只能调用订阅了应用程序的 API？

不，它应该与 oauth2 令牌的工作方式相同。 只有订阅用户才能调用 API，无论是通过令牌还是基本身份验证。

您不能将用户分配给应用程序，因为它以相反的方式工作 - 应用程序属于用户。 如果您想要更细粒度的控制，请在 /carbon 控制台中创建角色并将其分配给用户。 在 API 发布者中，转到 API 设置，将 devportal 的可见性更改为特定角色。 然后为每个资源创建具有特定角色的范围，将此范围分配给资源，启用安全性。 订阅的用户可以调用 API，但如果您不为用户分配角色，他们将无法调用任何受保护的资源。

如果 Prod 和 Sandbox 共享同一个网关，那么在进行基本身份验证时如何确定调用哪一个？

好问题。 我不知道答案。

顺便说一下，这不适用于消费者密钥和秘密。 端点是在 /token 生成 AFAIK 期间指定的。

嗨@Tomas-Mrazek 和@tmkasun ，这正是我现在基本身份验证的问题。 让我试着总结一下我对认证的看法：

OAuth2 - 我们为 App 订阅 Api。 基于密钥和秘密，我们知道应用程序和环境。 所以，为了让 App 使用 Api，我们需要做的就是订阅它。 然后，任何用户都可以调用该 Api，只要他知道密钥和秘密。

静态 Api 密钥- 在这里我们知道密钥，它提供了足够的信息来了解哪个应用程序正在调用 Api，以及它使用的环境。 App 订阅 Api 以使用它的概念仍然适用。 我们只需要为 App 订阅一个 Api。

现在的基本身份验证- 我将其称为“基于用户的基本身份验证”。 它完全摒弃了 App 和订阅的概念，需要使用不同的概念（基于用户的权限）和不同的工具，例如使用 Carbon admin 而不是 Publisher 或 Store/DevPortal。 当一个网关用于两者时，它无法区分生产环境和沙箱环境。 它还增加了设置和管理的复杂性。 现在只看订阅的应用程序列表是不够的，还必须去 carbon admin 查看用户和权限。 如果我想为一个 Api 限制一个特定的应用程序，或者有不同的订阅级别，我不能为用户这样做。

我认为支持基本身份验证的“正确”方式如下：

应用程序级基本身份验证- 我们从概念中删除用户（如使用静态密钥），而是使用应用程序身份验证。 应用程序仍然需要订阅 Api。 消费者密钥和消费者秘密用作基本身份验证凭据。 这样我们就保持了 App / Api 订阅的概念，可以继续使用与其他所有东西相同的工具（发布者 / devPortal，不需要 Carbon Admin），并且我们知道哪个 App 使用哪个 Api 以及基于密钥的环境。

如何到达那里？

有两种选择。 要么将当前的 Basic 实现更改为上述建议的实现，要么实现一个名为“App Basic 身份验证”的新实现。
还有第三个选项，在现有的基本身份验证中同时支持用户/密码和密钥/秘密，但这是最脏的一个。

基本的身份验证实现是不够的。 例如，您可以基于角色限制开发门户上的 API 可见性 -> 需要通过 Carbon 控制台创建并与用户关联。

嗨@Tomas-Mrazek 和@markokocic
感谢您的建议，请在线查找我的答案。

订阅如何与基本身份验证一起使用？ 似乎任何用户都可以独立于订阅调用任何 Api？ 有没有办法将用户“分配”给特定的应用程序，以便他们只能调用订阅了应用程序的 API？

对客户端请求的基本身份验证支持不需要存在订阅。 如果 API 创建者为特定 API 启用了基本身份验证支持，则无需订阅该 API（按应用程序）即可调用该 API。
和@markokocic是的，订阅是如何工作的， An Application subscribed to an API 。

此外，使用 Baisc 身份验证：
你仍然得到：

• 资源级别或 API 级别限制
• 资源范围验证

你不会得到：

• 订阅级别限制
• 生产环境和沙盒环境差异化

如果 Prod 和 Sandbox 共享同一个网关，那么在进行基本身份验证时如何确定调用哪一个？

是的，我们无法通过用户名和密码区分环境，因此在使用基本身份验证时，您将无法选择环境，将使用生产端点。

@托马斯-姆拉泽克

端点是在 /token 生成 AFAIK 期间指定的。

不，端点（Prod 和 Sandbox）由 API 创建者在创建 API 时定义，API 使用者如果想使用基于重定向的授权类型（即隐式），可以为应用程序提供回调 URL

@markokocic关于

应用级基本认证

这对于当前的实现也是可能的。 您可以使用客户端凭据授予类型代表应用程序所有者获取令牌对。

应用级基本认证

这对于当前的实现也是可能的。 您可以使用客户端凭据授予类型代表应用程序所有者获取令牌对。

@tmkasun
是的，可以使用基本身份验证通过客户端凭据生成令牌。 你使用这样的东西：

curl -k -X POST https://localhost:8243/token -d "grant_type=client_credentials" -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

但是，要使用 API，您的使用者仍然需要能够：

• 使用上述方法生成令牌
• 将其设置为带有 Bearer 和 Token 的 http“Authorization”标头，用于实际 API 请求
• 最终处理令牌过期和刷新

如果程序员为您的消费者编程，或者您有可以做到这一点的供应商，那也没关系。 如上所述，问题在于许多不可定制的传统企业客户端。 例如在 SAP 中，如果您想使用外部服务，您唯一可以设置的是 URL，以及可选的用户名和密码以进行基本身份验证。 在那里您无法获取令牌或设置自定义标头。

上面我说的App级Basic Authentication其实就是可以跳过token生成这一步，直接使用基于客户端凭据的Basic Authentication来调用API。

类似的东西：

curl -k -X POST https://localhost:8243/my/nice/Api/doSomething -H "Authorization: Basic Base64(consumer-key:consumer-secret)"

这将允许我仍然以统一的方式使用相同的应用程序到 API 订阅模型，而无需创建、设置和管理用户。

另一个好处是，由于基本身份验证标准提供了将授权标头作为 URL 的一部分包含在内的能力，我们甚至可以通过以下方式支持旧版消费者：

curl -k -X POST https://consumer-key:consumer-secret<strong i="25">@localhost</strong>:8243/my/nice/Api/doSomething

编辑：现在我考虑了一下，也许更清晰的名称是基于客户端凭据的 API 基本身份验证。