SSO统一身份认证——CAS Server6.3.x根据环境读取配置文件（四）

背景

​ 单点登录(SingleSignOn，SSO)，就是通过用户的一次性鉴别登录。当用户在身份认证服务器上登录一次以后，即可获得访问单点登录系统中其他关联系统和应用软件的权限，同时这种实现是不需要管理员对用户的登录状态或其他信息进行修改的，这意味着在多个应用系统中，用户只需一次登录就可以访问所有相互信任的应用系统。这种方式减少了由登录产生的时间消耗，辅助了用户管理，是目前比较流行的。

​ 单点登录的使用场景有很多，C/S、B/S架构的系统均可使用，通常是支持快速配置使用。

​ 业内目前实现SSO的方式有很多种，在ToC场景下互联网公司通常使用的是OAuth2协议，而ToB场景下大家通常是囊括百家，既支持OAuth2又支持CAS，还滴支持LDAP。其造成的原因主要是因为在ToB场景下需要对接SSO的系统通常仅支持某个协议，而这类系统又不是同一个协议导致。
而我当前境况下就是既有ToC场景又有ToB场景，在该种情况下，我开始对其业内的各种协议进行整合集成，这一系列文章将对其业内各个协议从基础到深入、从搭建到二次开发进行记录，同时将其整理出来分享给大家。

简介

​ CAS是Central Authentication Service的缩写，中央认证服务，一种独立开放指令协议。CAS 是 耶鲁大学（Yale University）发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

其主结构由CAS Server、CAS Client两部分组成。下图为官方提供的结构图，大家可以作为参考进行理解。

主结构.png

环境

主要使用的环境如下

服务器系统：windows 10

环境：OpenJDK 11

web中间件：tomcat9

CAS Server：6.3.x

数据库：MariaDB 或 PostgreSQL

证书地址：阿里云证书购买页面-免费证书

快速软件包openjdk11+tomcat9+CASServer.tar

正文

​ 在我们日常进行项目、产品开发时，无法避免的面临各种各样的环境，其主要分为开发环境、测试环境、演示环境、定版环境、开发环境等等，而不同的环境我们需要使用的配置是不一样的，而CAS Sever在我们前面几节来看是需要读取本地配置的（其实是可以走云端的），而打包好后提供给运维的软件包通常是war包，这时我们如何来快速打出来不同环境使用的war包呢。

​ 我进行查阅了官方文档，其是这样讲述的：

Standalone

This is the default configuration mode which indicates that CAS does NOT require connections to an external configuration server and will run in an embedded standalone mode. When this option is turned on, CAS by default will attempt to locate settings and properties inside a given directory indicated under the setting name cas.standalone.configuration-directory and otherwise falls back to using /etc/cas/config as the configuration directory. You may instruct CAS to use this setting via the methods outlined here. There also exists a cas.standalone.configuration-file which can be used to directly feed a collection of properties to CAS in form of a file or classpath resource.

Similar to the Spring Cloud external configuration server, the contents of this directory include (cas|application).(yml|properties) files that can be used to control CAS behavior. Also, note that this configuration directory can be monitored by CAS to auto-pick up changes and refresh the application context as needed. Please review this guide to learn more.

Note that by default, all CAS settings and configuration is controlled via the embedded application.properties file in the CAS server web application. There is also an embedded application.yml file that allows you to override all defaults if you wish to ship the configuration inside the main CAS web application and not rely on externalized configuration files. If you prefer properties to yaml, then application-standalone.properties will override application.properties as well.

Settings found in external configuration files are and will be able to override the defaults provided by CAS. The naming of the configuration files inside the CAS configuration directory follows the below pattern:

  • An application.(properties|yml|yaml) file is always loaded, if found.
  • Settings located inside properties|yml|yaml files whose name matches the value of spring.application.name are loaded (i.e cas.properties) Note: spring.application.name defaults to uppercase CAS but the lowercase name will also be loaded.
  • Settings located inside properties|yml|yaml files whose name matches the value of spring.profiles.active are loaded (i.e ldap.properties).
  • Profile-specific application properties outside of your packaged web application (application-{profile}.properties|yml|yaml) This allows you to, if needed, split your settings into multiple property files and then locate them by assigning their name to the list of active profiles (i.e. spring.profiles.active=standalone,testldap,stagingMfa)

Configuration files are loaded in the following order where spring.profiles.active=standalone,profile1,profile2. Note that the last configuration file loaded will override any duplicate properties from configuration files loaded earlier:

  1. application.(properties|yml|yaml)
  2. (lower case) spring.application.name.(properties|yml|yaml)
  3. spring.application.name.(properties|yml|yaml)
  4. application-standalone.(properties|yml|yaml)
  5. standalone.(properties|yml|yaml)
  6. application-profile1.(properties|yml|yaml)
  7. profile1.(properties|yml|yaml)
  8. application-profile2.(properties|yml|yaml)
  9. profile2.(properties|yml|yaml)

If two configuration files with same base name and different extensions exist, they are processed in the order of properties, yml and then yaml and then groovy (last one processed wins where duplicate properties exist). These external configuration files will override files located in the classpath (e.g. files from src/main/resources in your CAS overlay that end up in WEB-INF/classes) but the internal files are loaded per the spring boot rules which differ from the CAS standalone configuration rules described here (e.g. .properties would not be loaded from classpath but application-.properties would).

Remember

You are advised to not overlay or otherwise modify the built in application.properties or bootstrap.properties files. This will only complicate and weaken your deployment. Instead try to comply with the CAS defaults and bootstrap CAS as much as possible via the defaults, override via application.yml, application-standalone.properties or use the outlined strategies. Likewise, try to instruct CAS to locate configuration files external to its own. Premature optimization will only lead to chaos.

根据上述官方文档，我们选择了Spring boot中常用的一种独立化配置方式，application-{profile}.properties|yml格式

下面我们开始对于之前章节的项目进行拆分并测试。

1、进行创建application-dev.properties与application-pro.properties配置文件

image-20210717175956805

2、将application.properties文件中我们增加的配置参数移动至application-dev.properties文件中。

image-20210717180027240

备注：其实我们配置中的一些公共配置，可以放置到cas.properties配置文件中，cas的名称只需要对应spring.application.name参数即可，待我们后续配置多了再进行分类。

3、修改cas-server\src\main\resources\bootstrap.properties配置文件中spring.profiles.active参数，让其默认加载dev结尾的配置文件。

spring.profiles.active=dev

image-20210717180054491

4、进行重新打包

E:\IdeaProjects\cas-server>gradlew build

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.8.1/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 4s
5 actionable tasks: 3 executed, 2 up-to-date

5、启动进行登录测试

image-20210717175649762

image-20210717175702153

​ 登录成功，说明我们的配置已经生效了。至此，我们就实现了拆分配置文件，日常使用时我们在打包时只需要修改一个参数，即可直接使用相应环境的配置文件了，后续我们再进行研究云配置的方式，请大家持续关注。

本文声明：


知识共享许可协议
本作品由 cn華少 采用 知识共享署名-非商业性使用 4.0 国际许可协议 进行许可。