如何通过 API 从 SAML 支持的 IBM App ID 获取令牌？答案

【问题标题】：How to get token via API from IBM App ID backed by SAML?如何通过 API 从 SAML 支持的 IBM App ID 获取令牌？
【发布时间】：2019-06-04 19:23:43
【问题描述】：

我正在尝试使用 App ID 通过 CLI 工具对 Kubernetes 中运行的服务进行用户身份验证/授权。

我已经配置了 App ID 并配置了 SAML 身份提供者。我添加了一个应用程序并获得了租户 ID、客户端 ID 和客户端密码。我还在 Kubernetes 入口定义中添加了 appid-auth 注释。

根据此处https://cloud.ibm.com/docs/services/appid?topic=appid-obtain-tokens 的文档，通过curl 应该非常困难，但我得到Error - cloud directory is OFF。

这是一个带有 X 的凭据示例。

$ curl -iX POST \
> https://us-south.appid.cloud.ibm.com/oauth/v4/XXXX/token \
> -H 'Authorization: Basic XXXXXXXXX' \
> -H 'Content-Type: application/json' \
> -H 'Accept: application/json' \
> -d '{"grant_type":"password","username":"testuser@ibm.com","password":"testuser"}'
HTTP/2 403
date: Tue, 04 Jun 2019 17:20:54 GMT
content-type: text/html; charset=utf-8
set-cookie: __cfduid=d8fb55f6b30555b81f64b3c3e40bbf8f71559668853; expires=Wed, 03-Jun-20 17:20:53 GMT; path=/; domain=.us-south.appid.cloud.ibm.com; HttpOnly
x-dns-prefetch-control: off
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=15552000; includeSubDomains
x-download-options: noopen
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
surrogate-control: no-store
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate
pragma: no-cache
expires: 0
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 4e1b948028aec1cf-IAD

Error - cloud directory is OFF

如果我使用"grant_type":"client_credentials"，它会返回获取访问令牌，但我需要一个身份令牌，以便应用程序可以根据用户进行授权。

我尝试在入口定义中使用“网络”版本，并且网络重定向工作正常。所以我知道 SAML 配置正确。

【问题讨论】：

标签： ibm-cloud ibm-appid

【解决方案1】：

您在这里混合了几个不同的概念。

SAML 身份验证通过向用户显示登录 UI 来工作。用户需要填写电子邮件/密码（或任何凭据），然后返回应用程序。这里的底线是 SAML 身份验证工作流程意味着可以与浏览器交互以输入凭据的人类用户。为了通过 OpenID Connect（App ID 所基于的协议）实现 SAML 联合，使用了一个名为 authorization_code 的grant_type。此工作流程还意味着向用户呈现登录 UI。由于在不向用户提供 UI 的情况下无法使用 SAML 身份验证，因此您不能仅使用 API 方法来对用户进行身份验证。使用 SAML，您必须使用 grant_type=authorization_code，它只能在浏览器中正常工作（除非您执行 html 抓取，不建议这样做）。

“grant_type=client_credentials”的工作方式不同。它专为非用户交互场景而设计，在这些场景中您不涉及人类用户。 SAML 用于验证用户，client_credentials 用于验证应用程序/服务。

在 youtube 上查看 App ID 教程中的幕后技术视频，它解释了各种工作流程之间的差异 - https://www.youtube.com/playlist?list=PLbAYXkuqwrX2WLQqR0LUtjT77d4hisvfK

【讨论】：

感谢您的 youtube 参考。这对理解工作流程非常有帮助。在您提到的视频中，在“授权代码”OAuth2 工作流程中，用户代理不必是浏览器。您是否有关于如何实现由 SAML 或任何其他身份提供者支持的用户代理的参考或示例。基本上，我不明白我会调用什么 AppID 端点。或者这仅适用于网络浏览器？
在阅读了更多内容之后，我想我明白了如何做到这一点。用户代理必须直接与 SAML 提供者通信并获得授权，然后将授权提交给 AppID 以获取令牌。对吗？
为了使用 SAML 工作流程，您必须 (1) 支持 http 重定向，(2) 显示（或以其他方式解析）html 登录表单，(3) 使用凭据填充上述登录表单并将其提交给服务器。浏览器可以做到所有这些，因此应该使用浏览器进行 SAML 身份验证。从技术上讲 - 您可以编写一些代码来在无浏览器场景中实现上述登录，但这需要手动 html 解析等。我不建议这样做。你能详细描述一下你想要达到的目标吗？