0

此观察与 CAS 5.3.9 和https://apereo.github.io/cas/5.3.x/installation/OAuth-OpenId-Authentication.html下的文档有关

没有提到 /callbackAuthorize 端点，但我在授权代码流的实现中看到了这一点。以下是请求序列（我们假设用户已经通过 CAS 身份验证）：

请求：GET https://localhost:8145/api/profile（我的应用程序的受保护端点）

RESP：302，位置：https://cas-server:8443/cas/oauth2.0/authorize?response_type=code&client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf

请求：GET（上面的 URL）

RESP：302，位置：https://cas-server:8443/cas/login?service=https%3A%2F%2F172.16.238.10%3A8443%2Fooscas%2Foauth2.0%2FcallbackAuthorize%3Fclient_id%3Dclient1%26redirect_uri% 3Dhttps%253A%252F%252Flocalhost%253A8145%252Fcallback%253Fstate%253Dcsrf%26response_type%3Dcode%26client_name%3DCasOAuthClient

请求：GET（上面的 URL）

RESP：302，位置：https://cas-server:8443/cas/oauth2.0/callbackAuthorize?client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf&response_type=code&client_name=CasOAuthClient&ticket=eyJhbGciOiJIUzUxMiJ9。 ZXlKNmFYQWlPaUpFUlVZaUxDSmhiR2NpT2lKa2FYSWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wLi5RdURKNXBJZ21zOU1LcldqSmwxMk5BLnRXb3FrSEFIRzcyY2M3U3k4cm9fR0VCS05feThtVjREazBYNU81NVNVY3g0NEFlby1Kc2R3NGszNUM3X1dDVkwuM01Pd3c5ci1mVS1QelROWDVIZkJSUQ%3D%3D.b4rotud6-2s3tOU21-Y0xclwVkVEioTLhiyRhi5VotNfjzt5vKoM2Ix9Hy_OW9KSpuGMqWsBbFOtR9K2B8E6dw&lang=de

请求：GET（上面的 URL）

RESP：500，内部服务器错误（cas 服务器日志显示 SSL 握手异常，可能服务器尝试访问他在信任库中没有证书的 URL）

我的问题：

1) /oauth2.0/callbackAuthorize 端点是否有任何文档？

2) 为什么 CAS 服务器在 OAuth2 流中发出票证？他不应该生成访问令牌吗？

3) 参数 client_name=CasOAuthClient 来自哪里？CAS 服务器是否试图充当 OAuth2 客户端？

4

1 回答 1

0

1) /oauth2.0/callbackAuthorize 端点是否有任何文档？

是的。有关一般设计说明，请参阅此链接，然后查看pac4j的工作原理。

2) 为什么 CAS 服务器在 OAuth2 流中发出票证？他不应该生成访问令牌吗？

不可以。授权代码流通过访问令牌端点发出 AT。如果您需要来自授权端点的 AT，则需要使用不同的授权类型。有关更多信息，请参阅 OAUTH 规范。

3) 参数 client_name=CasOAuthClient 来自哪里？CAS 服务器是否试图充当 OAuth2 客户端？

从上面的链接，

... CAS 支持的几乎所有协议都以相同的意图运行。给定的 CAS 部署配备了一个嵌入式“插件”，该插件知道如何使用 SAML2 和 CAS、OAuth2 和 CAS，或 OpenID Connect 和 CAS 或其他什么。当您考虑以下具有启用 OAuth2 的客户端应用程序的身份验证流程时，该等式的右侧始终是 CAS：

  • CAS 部署已开启 OAuth2 插件。
  • OAuth2 授权请求被提交到相关的 CAS 端点。
  • OAuth2 插件验证请求并将其转换为 CAS 身份验证请求！
  • 身份验证请求被路由到相关的 CAS 登录端点。
  • 用户进行身份验证，CAS 将流程路由回 OAuth2 插件，并为该插件颁发了服务票证。
  • OAuth2 插件尝试验证该票证以检索必要的用户配置文件和属性。
  • 然后，OAuth2 插件通过将配置文件和经过验证的断言转换和转换为客户端应用程序可能需要的内容，继续发出正确的 OAuth2 响应。

另外，从这个链接中提取：

...所有协议都是 CAS 服务器的客户端，它们使用 CAS 协议与之交互。这是在请求/浏览器级别完成的，而不是通过高度定制的 web 流在内部做事，这样会相互纠缠。CAS 中存在的协议模块对 CAS 身份验证流程/引擎的内部内部工作进行零假设。他们像对待外部 CAS 服务器一样对待它；唯一的区别是，他们直接坐在 CAS 服务器中，但他们仍然完全不知道这一事实。简单地说，在我们的示例中，SAML2 模块基本上说：“这个传入的请求需要经过身份验证。所以我会将它路由到 CAS 服务器进行身份验证，当它返回时，我会尽我所能”。

于 2020-04-24T08:30:18.193 回答