今天對acegi的頁面標簽做擴展，突然發現找不到tld文件了
Jsp中非常簡單：
<%@ taglib prefix="authz" uri="但記得自己沒有在web.xml中聲明這個標簽，咋就跑起來了呢？google一下，原來authz.tld被打入jar包的META-INF下
呵呵，記錄一下 acegi內置了對CAS的支持。這里的CAS是3.0。建立CAS server是一個比較簡單的事情。CAS server就是一個標準的war文件，把它發布就可以運行。需要做的僅僅是調整登陸和其他一些頁面。先了解一下CAS如何實現SSO。
例子：原有系統A和系統B，現在在它們之間做SSO。
很顯然，系統A和B都是CAS client。首先是訪問系統A，干掉A的登陸頁面，在A的入口判斷有沒有Ticket(票據），如果沒有則重定向到CAS server，在CAS server提供Credential（大多數情況就是用戶名和密碼）。CAS server的作用非常簡單：就是來驗證用戶密碼。正確，則發送Ticket。CAS有5種Ticket，分別是TGC(通過cookie發送的ticket），ST（Service Ticket),PGT,PGTIOU,PT。其中PGT,PGTIOU,PT屬于代理ticket，這里不作討論。具體可以參考
http://www.aygfsteel.com/openssl/archive/2006/04/26/SSO_CASProxy.html
TGC和ST的關系可以打個比方：
我去中央電視塔去玩，結果發現地下還有個海底世界。SSO前我是這么玩的：先去電視塔買張門票，玩完了；再去海底世界買張門票，玩完了。發現真累，兩個景點這么近還要買兩次門票，就不能搞個通票嗎？于是就SSO。于是這樣：我先去電視塔，門衛告訴我你不能進去要買票，于是把我送到通票售票處（CAS server）買票（登錄），買吧，于是給了我兩張票，注意，是兩張，一張發到我手里，上面寫著僅限電視塔使用（ST）；靠，不是通票嗎，咋僅限電視塔使用？別急，還有一張票（TGC）通過cookie發送你看不見。人家說了保證沒問題，我咋辦，這是人家的規矩，那就先去玩吧。出了電視塔我直撲海底世界，
門衛說要海底世界票，不會吧，我買的通票啊，門衛說不著急，又把我送回通票售票處（CAS server），通票售票處（CAS server）一看，發現我有TGC，嘿嘿，這家伙買過票了不用再買（不用再登錄），于是換我一張票（ST）上面寫著僅限海底世界使用，于是我就拿著這張票又去海底世界了。于是我明白了啥是SSO了，不就是把買票改成換票了嗎？
比方完了，最開始的例子也就不往下繼續了。需要注意的是系統A和B整合SSO需要把A、B的用戶密碼集中管理，你說A中我的用戶名是張三，B中是李四，SSO能不能幫我自動識別，回答是不行的。
繼續Acegi的整合。
CAS server是做用戶密碼驗證，具體的權限授權的工作還是在各個單個系統里，也不應該交給它管。做用戶密碼驗證需要AuthenticationHandler。這個具體就是根據Credential返回一個boolean值來判斷你輸入的用戶密碼正不正確。acegi提供了一個實現。
以一個典型的web訪問來說明整個過程
1、用戶訪問一個受acegi安全保護的頁面或業務方法；
2、用戶沒有登陸的話顯然會拋出AuthenticationException
3、配置exceptionTranslationFilter捕獲這個異常重定向到CAS server登陸頁面
serviceProperties里的service屬性即在CAS server登陸完畢后由CAS server重定向回來的頁面
??https://my.company.com/cas/login?service=https%3A%2F%2Fserver.company.com%2Fmyapp%2Fj_acegi_cas_security_check
4、CAS server檢查是否有TGC ，沒有則登陸，登陸后返回。這里屁股后面跟著的即ST，TGC通過cookie一并發送到客戶端。
?? https://server.company.com/myapp/j_acegi_cas_security_check?ticket=ST-0-jhsdfguwgeds
5、配置casProcessingFilter來處理返回ST（和以前的authenticationProcessingFilter比較類似）
6、配置authenticationManager
具體作用的是casAuthenticationProvider，casAuthenticationProvider通過 casProxyTicketValidator來校驗ST
casProxyTicketValidator又具體實現調用了CAS Client library里的ProxyTicketValidator校驗ST，ProxyTicketValidator?就比較有意思了，它做了個HTTPS請求CAS server，結果還是CAS server來校驗ST（繞了一大圈）
?https://my.company.com/cas/proxyValidate?service=https%3A%2F%2Fserver.company.com%2Fmyapp%2Fj_acegi_cas_security_check
?重新回到CAS server，它接受到這個HTTPS請求，檢查ST是否與對這個service發行的ST吻合，吻合的話CAS server就會發回一個肯定的XML回復，里面包含了用戶名（username)。剩下的就EASY了，casProxyTicketValidator解析XML，casProxyDecider處理代理，casAuthoritiesPopulator根據解析后的XML獲得user，最后就是casAuthenticationProvider構造Authentication（這里是CasAuthenticationToken）
7、重新回到casProcessingFilter，它將Authentication放入HttpSession
這樣就完成了整個過程 在web.xml中一般我們這樣配置：
這樣agegi就對所有的url進行了過濾檢查，以一個顯示樹狀菜單為例，它甚至對頁面上的每一個圖片連接都進行了檢查，實際上這是完全沒有必要，可以這樣：
呵呵，檢查范圍縮小了，可是登陸時系統報404錯誤，找不到/j_acegi_security_check，因為/j_acegi_security_check這個路徑是agegi自己的，所以再增加一行攔截過濾就OK
周末公司組織去北戴河旅游。悶熱的天氣、潮濕的空氣，讓人對海邊充滿向往。上次去海邊已是十六年前了，沒有記憶，只有發黃的照片，年幼的我，傻呵呵地笑。十六年前是父親帶我去的，一晃十六年，上個禮拜父親學校放暑假帶奶奶來北京卻沒有時間陪他們，請了一天假帶妹妹去了石景山游樂園，然后是讓女朋友帶著去了趟八達嶺，僅此而已，僅此而已。很是愧疚。
目的地是河北昌黎的黃金海岸。下午五點到達，到達后的第一件事：下海。海浪很大，不會游泳，和女朋友一起站在腰深的地方，泡海。一切都很商業化：廁所，一元；更衣室，一元；熱水淋浴，五元；游泳圈，二十元。。。女朋友屬于很怕水的那種，一看見海浪就往海邊跑，我好點，只要不沒過胸就好。很羨慕那些會游泳的人，遠遠的只能看見他們的一個頭，一個黑點，在海里起伏。其實離海岸越遠海水越平靜，海浪都是靠近海岸的時候才突然變得猛烈起來的。生活，是不是也象這樣呢？
晚上在海邊的大排擋解決了晚飯問題。和女朋友一起去買點東西，價格自然是高。她想吃袋餅干，一問價格，八元！于是劃價，六元。朋友表示不可接受，店老板表示不可再讓。于是向外走，走到門口的時候，店老板突然說，五元！于是又回去四點五元成交。生意都是不斷妥協做成的。
出發前公司租了帳篷，晚上在海邊扎帳篷過夜。真是很奇妙的感覺：外邊海浪打在沙灘上發出巨大的聲響，帳篷里卻是異常的安靜。靜靜地躺在那里，想到了很多的東西。想到了自己的童年，想到了自己的父母，想到了自己的工作，想到了自己的未來。想的最多的還是自己的未來，未來會是什么樣子呢？想起剛到北京找工作那會，經過一家麥當勞門口，巨大而明亮的落地窗戶后，一個年輕的女孩子，吃著炸薯條，仰起她那張無憂無慮的臉。
早上退潮了，朋友興奮地去海灘上撿貝殼。有漁民過來買螃蟹，剛早上六點，他們已經出?；貋砹?。是個晴天。
生活本來是很簡單的，是不是自己把它搞復雜了？

一、???????????? 考慮實現

1、? 系統權限考慮繼續采用原先實現方式，在構造功能樹和樹狀菜單時作出權限判斷；

2、? 數據庫操作權限考慮應用 Acegi 擴展，在業務層對相應的瀏覽 / 增加 / 修改 / 刪除的業務方法進行攔截；

3、? 行級數據權限考慮采用 AOP 的方式在用戶訪問相關資源時根據用戶權限動態構造 SQL 注入到業務方法里，再由業務方法傳遞到 DAO 里；

4、? 列級數據權限考慮做入頁面，這里不再討論。

5、? 大集中模式下的權限管理，本質也是行級數據權限，即在每次數據訪問時都需要強制判斷用戶所屬部門 Group 。

一、 權限管理詳細解決方案

用戶、用戶組、角色設計如下：

Principal 即為權限主體

1、? 系統權限授權

web 頁面：

頁面上顯示兩棵樹：左側顯示用戶、用戶組和角色樹，右側顯示功能模塊樹，功能模塊樹的節點上跟兩個復選框，分別是可見 / 可再授權。點擊用戶、用戶組和角色樹上的節點對相應權限主體進行授權。

很顯然可再授權權限包含可見權限。

數據庫實現：

用 ACL 實現，表設計如下：

資源 ID ，權限主體 ID ，權限主體 TYPE ，資源 TYPE ，資源操作權限，條件查詢語句 queryStr 。

說明：

權限主體 TYPE? 三種： user/group/role

資源 TYPE??? ???? 兩種： function/method? 此時對系統權限來說是 function

條件查詢語句 queryStr??? 數據范圍控制 ? 此時對系統權限該字段無效

對象：

用戶保存授權信息時，先刪除該權限主體 ID 的授權記錄，再更新。

2、? 數據庫操作權限授權

這里引入一個新的對象：數據庫操作資源對象 ? DataResource

表設計如下：

ID ， NAME ， parentId ， resStr ， resType ， desc

說明如下：

ID

NAME 資源名稱 例如：新增用戶

parentId

resStr? 業務方法地址 例如： com.way.sevice.UserService.addUser

resType 資源類型，分兩種： abstract/detail? 抽象 / 具體

desc? 描述說明

例子：

對用戶管理進行數據庫操作權限授權

新建“用戶管理”做父節點，選擇資源類型為“抽象”

在“用戶管理”下再依次新增“新增用戶”、“瀏覽用戶”、“修改用戶”、“刪除用戶”四個子節點，選擇資源類型為“具體”

如果系統自己來判斷存儲就是葉子節點是“具體”，其他為“抽象”

web 頁面：

頁面上顯示兩棵樹：左側顯示用戶、用戶組和角色樹，右側顯示數據庫操作資源對象樹，數據庫操作資源對象樹的葉子節點的一級父節點上跟一個數據范圍限定 button ，點擊后彈出窗口輸入限定條件；葉子節點上跟一個復選框。點擊用戶、用戶組和角色樹上的節點對相應權限主體進行授權

授權信息存入 ACL 表中

資源 TYPE 為 method

3、? 行級數據權限授權

已在上面做了說明即數據范圍限定

4、? 大集中模式下的權限授權

其實所謂大集中模式控制的也不過是數據范圍，考慮是所有相關表全部增加 groupId 字段，新增時添入該字段，讀出時進行判斷

web 頁面：

“組織和用戶管理”模塊中，每個組織中都允許設定一個管理員，一旦設定管理員，該組織就進入大集中模式，即所有該組織的數據與其他同級組織互相隔離，僅上級組織可見。同時說明一點的是：該管理員與系統總的管理員權限一樣，不同的是數據范圍僅限制與該組織內部。

綜述：

實際的授權部分采用了 ACL ，所以授權比較簡單和直觀

系統資源和數據庫操作資源分開兩個表存儲，這樣可能會給用戶帶來不便，也就是授權時還需要切換，但這種不便似乎不好解決，因為一個是粗粒度的一個是細粒度的。