CAS單點登錄-Service配置（七）

簡介

cas客戶端接入稱之爲service，必須經過cas的允許才能進行登錄，當然不同的客戶端可以做不同的事情，其中包括：

自定義主題（各客戶端登錄頁自定義）
自定義屬性（服務屬性（固定）與用戶屬性（動態））
自定義協議
自定義登錄後跳轉方式，跳轉路徑
授權策略（拒絕屬性、可登錄時間範圍限制、等等）
拒絕授權模式

接下來來一個FAQ

A: 什麼是service，根cas有什麼關係？
B: service是使用型cas是服務型，cas好比遊樂園，service好比來遊樂園的遊客
A: 那service如何對接cas？service如何知道是否被允許接入？
B: 好比遊客需要進入遊樂園，那麼遊客需要門票，獲取門票有多種方式，可以用手機校驗碼，或者身份證進行獲取。當然如果是犯罪分子門票都買不了，更何況進去遊樂園
A: 具體service如何作爲客戶端使用？
B: 好比買門票，必須填寫身份證號、手機號、付款等流程，當然也可以通過不同渠道購買，cas也有不同的客戶端實現，cas client、pac4j等
A: service接入有何好處？
B: 被接入的service無需進行輸入密碼即可進入系統，好比A-service（OA系統）登錄了，B-service（賬單系統），C-service（CRM系統）無需再次登錄，傳統的方式有10個八個系統進行登錄，用戶會瘋掉，開發員也需要管理多個系統的帳號數據

說了一大推，不如來點正事，例如怎麼配置，如何管理，馬上馬上~~

實戰

持久化策略：

InMemory XML(通過spring bean進行內存存儲)
JSON(通過json文件存儲) 推薦 ❤❤❤
YAML(通過yml文件存儲)
Mongo(文檔數據庫持久化)推薦 ❤❤❤❤❤
JPA(關係型數據庫持久化)
DynameDb
LDAP
Cochbase

在sso初步上線時推薦採用json文件存儲，後面逐步多服務注入時推薦採用Mongo進行存儲，採用cas-management進行採用UI進行管理我們的數據，目前階段，持久化策略必須和cas進行配置一致才能生效

本章進行service的json配置及介紹，下一章進行cas-management配置

JSON 配置

需求：對所有http://localhost開頭請求的service進行允許認證

在resources/services下新建文件Localhost-10000002.json

{
  "@class": "org.apereo.cas.services.RegexRegisteredService",
  "serviceId": "^(http)://localhost.*",
  "name": "本地服務",
  "id": 10000002,
  "description": "這是一個本地允許的服務，通過localhost訪問都允許通過",
  "evaluationOrder": 1
}

注意：

json文件名字規則爲${name}-${id}.json,id必須爲json文件內容id一致

json文件解釋：

@class：必須爲org.apereo.cas.services.RegisteredService的實現類，對其他屬性進行一個json反射對象，常用的有RegexRegisteredService，匹配策略爲id的正則表達式
serviceId：唯一的服務id
name：服務名稱，會顯示在默認登錄頁
id：全局唯一標誌
description：服務描述，會顯示在默認登錄頁
evaluationOrder：匹配爭取時的執行循序

除了以上說的還有很多配置策略以及節點，具體看官方文檔,配置不同的RegisteredService也會有稍微不一樣

啓用識別

上面新建了json文件cas還不知道要去識別json，需要打開開關

application.properties

#開啓識別json文件，默認false
cas.serviceRegistry.initFromJson=true

#自動掃描服務配置，默認開啓
#cas.serviceRegistry.watcherEnabled=true
#120秒掃描一遍
#cas.serviceRegistry.repeatInterval=120000
#延遲15秒開啓
#cas.serviceRegistry.startDelay=15000

#默認json/yml資源加載路徑爲resources/services
#cas.serviceRegistry.config.location=classpath:/services