一般來說都是去整合或者整合cas，但是今天記錄的確是反著來的，即把cas從現有系統中給剔除掉，不用它了。
遇到乙個場景是這樣子的：需要將原有的cas認證體系去除掉（其他團隊做的乙個門戶系統），換做乙個另乙個簡易的認證中心。為了保持系統的擴充套件性，需要在盡量不修改原來的**的基礎上完成遷移。
要盡量少的改動原有**，那麼就從源頭上開始修改，也就是去修改過濾器。
增加配置開關，根據配置來啟用或關閉原cas所有的filter
改造使用者驗證邏輯
新增filter去新的認證中心去驗證使用者資訊
改造使用者資訊獲取方式
在此過程中遇到的主要的乙個問題是獲取使用者資訊時，原cas是通過request.getuserprincipal()來進行獲取的，但是新的認證中心並沒有採取這種方式，所以取到的一定是空的，並且request介面中並沒有提供request.setuserprincipal()來設定認證主體的方法。
最後全域性搜尋了一下，發現在httpservletrequest的實現類request中有setuserprincipal(principal principal)方法來設定認證主體，並且通過除錯發現，filter中傳入的servletrequest實際上是requestfacade，而requestfacade中則存在乙個request字段，於是乎，就可以通過反射來獲取到這個request的物件例項，從而把認證主體給set進去。
關鍵**：
public
void
dofilter
(servletrequest servletrequest, servletresponse servletresponse, filterchain filterchain)
throws ioexception, servletexception
catch
(illegalacces***ception e)
field.
setaccessible
(accessible);}
}}
另乙個問題是在驗證失敗重定向response到登陸頁面的時候出現了跨域問題，導致返回的response一直為空，但是瀏覽器中並沒有明確提示是跨域導致的，所以得設定下允許跨域就行。
cas作為認證中心，功能確實多，並且對各種認認證協議的支援性也很好，但是太過臃腫，很多功能是用不上的，啟動也較慢，可控度和自由性也比較低，比如找了半天沒找到能夠自定義ticket（或者tgt和gt）的生成邏輯（也可能有但還沒發現？）所以個人覺得能自己開發還是自己開發個認證中心，全流程自己控制，用著也舒服。
時間真的可以**一切嗎？不，**一切的只能是自己，我想我做到了
CAS客戶端認證流程
step 1 瀏覽器向cas客戶端發起登陸請求，cas客戶端生成 登陸url 並把瀏覽器重定向到該url 登陸url https cas server login?service 其中 cas server host cas認證伺服器的網域名稱 cas server port cas認證伺服器的ip...
關於CAS客戶端部署實現
最近專案組需要進行單點登入功能的實現，引用的是cas框架。這裡就簡單整理一下關於cas框架的客戶端實現，相對而言還是比較簡單的。1.在web.xml中新增cas框架的四大過濾器。2.需要修改原始登入servlet，將登入請求 或重定向到casfilter過濾器下的url位址，通過過濾 到單點登入介面...
CAS 客戶端獲取Credentials額外資訊
服務端的配置 1 在deployercontext.xml中加上attributerepository 2 配置，這裡配置需要從資料庫讀取的屬性，這裡參考了這篇 3 另外由於我用的是http協議，所以還需要配置serviceregistrydao，讓attributerepository返回資訊 4...