基于CAS构建通用的单点登录解决策略（二）：CAS消费者端搭建及单点下载测试

原创

小哥 3年前 (2022-11-02) 阅读数 11 #PHP

文章标签 PHP Laravel

客户端配置

首先，我们为单点登录测试创建两个客户端 Web 应用 testapp 和 otherapp (如果对应的应用程序以前已经存在，则不需要重复创建它)。 testapp 例如，对于初始化配置和演示， otherapp 顺着葫芦走就行了。

和 CAS 就像在服务器端一样，我们需要加入。 Laravel 在应用程序中 CAS PHP 客户端与 CAS Server 进行交流。CAS 官方为 PHP 该语言提供了一个客户端实现 phpCAS ，此外，Laravel 生态学也是基于 phpCAS 已实施扩展包 subfission/cas ，扩展包封装了该对。 phpCAS 操作，所以在我们安装这个扩展包之后，我们可以 testapp 在客户端通过。 phpCAS 与服务端 blog56 该应用程序具有单点登录交互。

安装配置

首先通过 Composer 安装新的 testapp 应用：

composer create-project laravel/laravel testapp --prefer-dist -vvv

我们配置应用程序的域名 app.test 。然后转到项目的根目录并安装它。 subfission/cas 扩展包：

composer require subfission/cas

下一步，在 config/app.php 注册服务提供商和门面：

// 在 providers 添加此配置
/*

Package Service Providers...
*/
\Subfission\Cas\CasServiceProvider::class,

// 在 aliases 添加此配置
Cas => \Subfission\Cas\Facades\Cas::class,

添加以下两个中间件。 app/Http/Kernel.php 的 $routeMiddleware 该属性用于单点登录判断：

cas.auth => \Subfission\Cas\Middleware\CASAuth::class,
cas.guest => \Subfission\Cas\Middleware\RedirectCASAuthenticated::class,

完成上述配置后，释放 CAS 客户端扩展包配置文件 cas.php 到 config 目录下：

php artisan vendor:publish --provider="Subfission\Cas\CasServiceProvider"

然后修改 .env 环境配置，以便可以完成此操作 CAS 客户端配置：

CAS_HOSTNAME=blog56.test
CAS_REAL_HOSTS=blog56.test
CAS_LOGOUT_URL=https://blog56.test/cas/logout
CAS_LOGOUT_REDIRECT=http://app.test
CAS_REDIRECT_PATH=http://app.test/user
CAS_ENABLE_SAML=false

在这里，我们配置 CAS 服务器域名，退出 URL，以及服务器退出登录后对应的客户端退回地址，最后配置 CAS_ENABLE_SAML 为 false 因为服务端目前不支持。 SAML。

路由定义

完成上述配置后，打开 routes/web.php ，按如下方式定义与身份验证相关的路由：

Route::get(/login, function () {
return cas()->authenticate();
});

Route::middleware(cas.auth)->get(/logout, function () {
cas()->logout();
});

Route::middleware(cas.auth)->get(/user, function () {
return cas()->user();
});

用户访问登录路径 /login 将进行鉴权判断，如果已经鉴权，则跳转到鉴权页面，否则跳转 CAS 服务器端做出判断。

用户访问退出路由 /logout 将首先在当地退出，然后 CAS 服务器退出并向其他系统发送退出通知，然后跳转到客户端退出地址。

用户访问需要身份验证的路由。 /user 如果没有鉴权，则先进行单点登录鉴权，如果已经鉴权，则返回鉴权用户信息。

另一个测试应用程序程序

另一个测试应用程序程序 otherapp 唯一的区别是客户端域名与上面的安装配置操作完全相同。 other.test ，将对应的配置值更改为该域名。

至此，我们已经完成了 CAS 所有服务器和客户端的构建和配置工作，然后您就可以测试单点登录过程。

测试前的准备工作

修改服务器端时区配置

由于是在单点登录过程中生成的。 Ticket 有一个过期时间，所以它需要在服务端。 blog56 应用内修改 config/app.php 的 timezone 默认配置值：

timezone => Asia/Shanghai,

当然，最好是把 testapp 和 otherapp 两个客户端应用程序程序的相应配置值也进行了这样的调整。这样一来，日志中似乎就不会出现时区混乱。

在服务器端注册客户端应用程序程序。

接下来，我们需要 CAS 在服务器中注册客户端应用程序程序服务，在中打开服务器数据库。 cas_services 数据表中注册了两项服务，即 otherapp_auth 和 app_auth ，这两个应用程序均可实现单点登录：

然后在 cas_service_hosts 数据表绑定了上述服务对应的域名：

在服务器端创建一个测试用户。

最后，在服务方面通过。 Tinker 创建用于测试的新用户：

如此一来，单点登录所需的所有环境、配置、数据等准备工作都已完成。以下是单点登录测试演示的正式步骤。

测试单点登录实施流程。

在浏览器中访问 CAS 客户端应用程序 testapp 访问需要在以下位置进行身份验证的路由： http://app.test/user ，则页面将被重定向 CAS 服务器登录页面： https://blog56.test/cas/login?service=http%3A%2F%2Fapp.test%2Fuser&gateway=true ，并自动将退回地址带到链接中：

此时，如果您访问 app.test 一句话，就会看到 Cookie 一个新的已添加到 CASAuth ，该 Cookie 用于设置 CAS 单点登录身份验证 Session ID。

回到 blog56.test 登录页面，填写上一步创建的测试用户帐号信息，登录后页面跳转 http://app.test/user 并打印出用户身份。 ID —— 用户名信息，如果你想获得完整的用户信息，你可以传入。 CAS 服务器端实施支持 SAML 实现协议的接口，或者访问客户端。 CAS 服务端 API 获取用户信息的步骤：

其中，在将认证用户信息返回给客户端之前还有另一个步骤。 CAS 单点登录实现原理中提到的身份验证操作。上述认证的全面实施情况如下：

CAS 服务器登录成功后，一个 Ticket然后把它存起来。 cas_tickets 表（5有效时间为分钟)；
根据提供的客户端重定向链接。 service 参数和刚刚生成的 Ticket 合并成一个新的 URL： http://app.test/user?ticket={TicketValue} ，重定向回客户端；
客户端传递此消息 Ticket 请求 CAS 服务器验证界面： https://blog56.test/cas/serviceValidate?ticket={TicketValue}&service=http%3A%2F%2Fapp.test%2Fuser ，则定位对应的验证逻辑 Leo108CASHttpControllersValidateController@v2ServiceValidateAction ，根据 ticket 参数查询数据库是否有对应的记录，是否过期，如果不存在或已经过期，则验证失败，否则验证成功，则数据表对应。 Ticket 记录删除，然后将认证用户信息返回给客户端应用程序；
客户端应用程序验证成功后，根据 Cookie 中的 CASAuth 作为 Session ID 将返回的鉴权用户标识信息存储到 Session 中，至此，用户就完成了单点登录认证操作。下次用户在客户端应用程序访问认证路由时，就是一个基于客户端 CASAuth Cookie 实现的 Session 认证判断，不用再去了 CAS 服务器端进行验证。

testapp 应用程序已完成登录身份验证。我们走吧 otherapp 身份验证操作。

我们在浏览器中访问 http://otherapp.test/login 在这一点上，由于 otherapp 尚未执行登录身份验证，因此将重定向 https://blog56.test/cas/login ，同时在 otherapp 写一个 CASAuth Cookie，由于 blog56.test 仍在登录，因此它将 otherapp 应用程序会生成一个 Ticket 并返回该客户端应用程序，相应流程和 testapp 完全一样， otherapp 根据这个 ticket 去 CAS 服务器端身份验证接口 https://blog56.test/cas/serviceValidate 将身份验证用户信息返回到 otherapp ， otherapp 使用先前创建的 CASAuth Cookie 作为 Session ID根据返回的认证用户信息设置 Session，从而完成 otherapp 登录身份验证。

在整个过程中，我们只是处于第一阶段 testapp.test 在中执行登录身份验证时 CAS 服务器执行登录操作，其他子系统的后续登录认证只需由服务器分配即可。 Ticket 并基于该 Ticket 身份验证就足够了，所以访问可信系统之间的身份验证资源也是一种登录。这种信任得到了实现 CAS 服务端注册审核客户端应用程序来完成授权的。而且基于 CAS 实施单点登录的好处是它不受与主域名相同的条件的限制，只要它是主域名。 CAS 服务器信任的客户端可以基于 CAS 服务器登录中心完成登录认证。

结合此示例，请返回并查看上一教程中的介绍。 CAS 单点登录原则这完全可以理解吗？在云雾中不再有感觉？

在下一教程中，我们将继续关注 CAS 单点登录扩展，演示如何实施 CAS 单点登录系统统一出境操作。