Java帝國之安全爭斗
1.前言
在Java帝國第三代國王的推動下，帝國對臣民們提供了一個叫做Java 認證與授權服務（Java Authentication Authorization Service, 簡稱JAAS）的東西, 在第四代國王的爭取下， JAAS成功地進入了JDK，成為了標準包的一部分。
國王希望JAAS能夠一統安全領域，像JDBC那樣引發使用的狂潮，成為一個重要的基礎設施，特意設置了一個新職位JAAS大臣，任命了一個自己的心腹去推動這件事情。
可是希望越大，失望就越大，除了幾家利益相關的豪門望族在不斷地搖旗吶喊之外，臣民們對JAAS不屑一顧，沒多少人使用。
2雷秀才
IO大臣這一天在家里閑得無聊， 帶著忠心耿耿的幕僚InputReader 出去微服私訪，來到了京城一個著名的酒館，點了幾樣精致小菜，一壺美酒。還沒開吃，就看到鄰桌的一個書生在唉聲嘆氣。
IO大臣心中一動，就把他叫過來一起聊聊。
原來這位書生是雷秀才，說是家鄉賦稅沉重，都沒法活下去了，特意來京城上訪，無奈不得其法，連門都進不去。
IO大臣起了好奇心，忙問是怎么回事。
雷秀才說：“都是JAAS惹得禍。”
“JAAS？”
“就是認證和授權嘛！” 雷秀才看到對方不知道，略有失望之色。
“認證？ 授權？”
“認證就是確定你是誰， 通常需要驗證對方提供的用戶名和密碼。 授權就是確定你能做什么。比如能否創建賬號，能夠刪除用戶等等。”
“呃呃，想起來了，為什么不用官方的JAAS，帝國的標準還是挺好的嘛，比如JDBC。”
“老先生您有所不知，JDBC標準自然是沒得說， 但是這個JAAS，唉，用起來極為繁瑣，大家都不愿意使用。可是那個JAAS大臣根本不管這些，一直瘋狂地推廣JAAS， 如果不用，就要課以重稅， 我們都活不下去了。”
“這倒是有點麻煩，你們打算怎么辦？” IO大臣先去試探對方套路。
雷秀才壓低了聲音：“不瞞老先生，我們家族已經推出了一個新的認證和授權的系統，叫做JSecurity，想托京城的大人們獻給陛下，把JAAS替換掉。 ”
“哦？！” IO大臣坐直了身體，這可是一件大事！
3JSecurity
IO大臣和InputReader 交換了一下眼色： 一個新的機會到來了！
之前和線程大臣斗，和XML大臣斗，和JDBC/JTA大臣斗，打來打去，殺來殺去，自己也占不到什么便宜。
這一次也許可以把安全領域給抓住！
InputReader問道： “你說說這個JSecurity有什么好處？ ”
“簡單，靈活，好用！比JAAS好用多了！” 雷秀才說。
“太抽象了，來點干貨。”
雷秀才突然警惕起來，只是喝酒，笑而不語。
IO大臣決定打開天窗說亮話： “不瞞你說，我就是當朝的IO大臣，你不用怕，我可以幫你上奏陛下。”
“啊？！” 雷秀才滿臉驚詫之色，沒想到在這里竟然偶遇當朝大員， 看來上午去廟里拜佛是對的，趕緊站起來行禮： “失敬失敬！”
IO大臣說：“現在可以聊聊你的JSecurity了吧？”
雷秀才早有準備，從袖子中抽取出兩張寫滿了代碼的紙，呈給IO大臣和InputReader：
- Subject currentUser = SecurityUtils.getSubject();
- UsernamePasswordToken token = new UsernamePasswordToken("liuxin", "123456");
- currentUser.login( token );
- if (currentUser.hasRole( "admin" )) {
- logger.info("You're Administrator!" );
- }
- if (currentUser.isPermitted( "user:delete" )) {
- logger.info("You can delete any users! be careful!");
- }
- currentUser.logout();
（友情提示：代碼可左右滑動）
IO大臣戴上老花鏡，舉著紙看了半天：“你這里為什么叫做Subject啊？ 怎么不叫User?”
“回大人，這個Subject 是安全領域的一個術語，表示了所謂的‘主體’，既可以代表用戶，也可以代表程序（網絡爬蟲等），我老家的人也覺得這個術語有點難于理解，也想用User這樣通俗易懂的說法，但是考慮到現在很多系統中都有User這個概念，為了避免沖突，還是叫做Subject好了。 ”
InputReader問道：“你那個login方法，要是登錄失敗了怎么辦？ ”
“其實那個方法會拋出異常，需要應用程序處理，我們提供了很多Exception類，分別應對各種情況，比如賬號未知( UnknownAccountException) , 密碼不正確(IncorrectCredentialsException) , 賬戶已鎖(LockedAccountException) , 嘗試次數太多(ExcessiveAttemptsException) 等等。 “
IO大臣說：“但是程序給用戶提供錯誤消息時，一定要提供模糊的信息，不能被別有用心的人利用，對吧？”
“沒錯，大人，給用戶看的錯誤消息一定得是模糊的，例如： 用戶名或者密碼不正確。 ” 雷秀才看到IO大臣開始深入思考了，非常高興。
“這里可以判斷一個用戶擁有什么角色(Role)， 以及有什么權限(Permission)，這個角色和權限直接有什么關系啊？ ” InputStream繼續問道。
“這個比較簡單，角色可以簡單地認為是一些權限的集合，比如admin這個角色，它的權限可能有刪除用戶，查看用戶，修改用戶等，再比如viewer這個角色，可能只有查看用戶的權限了。”
“那個user:delete又是什么意思？” IO大臣目光如炬 。
按照以往的宮廷斗爭經驗，這些細節非得搞清楚不可，要不然被別人抓住把柄，在朝堂上可下不來臺，文武大臣們表面上不動聲色，心里早已把你鄙視千百遍了，自己可不能重蹈JTA大臣的覆轍。
雷秀才道：“那是我們定義的一種權限符號規則，格式是這樣的：資源:操作:實例， 用兩個冒號分開，例如：
user:create:U001 表示對用戶資源實例U001進行create操作
user:create 表示對資源進行create操作，相當于user:create:*
user:*:U001 表示對用戶資源實例01進行所有操作”
IO大臣點了點頭，格式由JSecurity定義，但是數據內容需要應用程序來確定。
InputReader突然說：“大人您記得提出Java注解的安翰林嗎， 如果這個JSecurity支持注解就好了。”
雷秀才說：“支持支持，那個注解挺好用的。”
- @RequiresAuthentication
- public void updateAccount(Account userAccount) {
- //用戶認證了以后才可以執行該方法
- ...
- }
- @RequiresPermissions("account:create")
- public void createAccount(Account account) {
- //用戶必須具備account:create這個權限
- //才能執行該方法
- ...
- }
- @RequiresRoles("admin")
- public void deleteUser(User user) {
- //只有具備admin這個角色的用戶才能執行該方法
- ...
- }
IO大臣覺得此處耳目眾多，不宜久留，提議回自己府上繼續商談。
4Realm
三人回到IO大臣府中，還沒等上茶，InputReader就著急地問道：“你那個代碼看起來挺簡單，只是JSecurity去哪里驗證這些用戶名，密碼，還有權限，角色啊？”
看到問題越來越深入，雷秀才也越來越高興，看來今天真的遇到貴人了。
“這真是一個好問題啊，大人，” 雷秀才說道， “對于每個應用來說，這些安全相關的數據保存的地方可能都不一樣，可能在文本文件中， 數據庫中，或者LDAP服務器中...... 數據格式也不盡相同，有的把用戶叫做user, 有的可能叫做username, 有些把密碼叫做password,有些可能叫做pwd...... 考慮到我們JSecurity是個框架，非得做出一個抽象的概念才行，這個概念就叫做Realm ，聽起來也稍微有點古怪。”
雷秀才不好意思地笑了笑，繼續往下說：“這個Realm 是一個接口，就像一座橋梁，把應用程序特定的數據和我們JSecurity框架能理解的格式給聯系起來！ 它可以把用戶應用特有的安全數據轉化成JSecurity能理解的格式。”
“ 難道每個應用都得提供一個獨特的JDBCRealm/LDAPRealm/IniRealm這樣的實現類嗎？ ” IO大臣表示不滿。
“不不，”雷秀才急忙救火，“為了降低應用程序的負擔，我們的JSecurity框架已經提供了這些缺省的實現，大家在使用的時候只要稍微做點調整就可以， 比如說大人您有個應用程序，用數據庫表存儲了用戶名和密碼，usesr(id ,name, pwd......), 您只要提供一個sql 給JDBCRealm，我們框架就可以自動完成認證了。”
雷秀才又拋出了一張圖。
InputReader 看著這張圖，自動腦補了整個認證的過程：
1. 應用配置使用JDBCRealm （當然得提供數據庫的連接信息)
2. 應用告訴JSecurity 怎么從用戶表中根據用戶名獲取password，關鍵是那條sql：
jdbcRealm.authenticationQuery = select pwd from users where name= ?
3. 用戶執行subject.login操作，JSecurity 使用SQL進行查詢，看看用戶名，密碼是否匹配數據庫的值。
（注： 簡單起見，這里故意忽略了使用salt對密碼做hash的場景）
對于角色和權限，也可以提供類似的sql ，讓JSeurity從數據庫表中獲取相關的數據：
jdbcRealm.userRolesQuery = "SELECT role_name FROM user_roles WHERE user_name = ?"
jdbcRealm.permissionsQuery = "SELECT permission FROM roles_permissions WHERE role_name = ?"
“一個應用程序要是配置了多個Realm ，認證時該怎么處理？” InputReader繼續刨根問底。
雷秀才暗自佩服InputReader心思縝密， 說道：“我們定義了一個接口，叫做AuthenticationStrategy， 用來定義認證多個Realm時該怎么處理， 我們也提供了幾個默認的實現，比如FirstSuccessfulStrategy，只要遇到一個Realm認證成功就算成功；或者AllSuccessfulStrategy，必須所有的Realm都認證成功。”
InputReader點點頭，看來他們考慮得挺仔細。很明顯，對于授權，也可以定義類似的策略。
雷秀才畫了一張圖，展示了認證和授權的架構：
5Session管理
“嗯，我覺得對于認證和授權，你們做得很不錯了！” IO大臣試圖總結。
“大人，我們還支持一些很誘人的功能。例如Session管理。 ”
“Session ？ 那不是Tomcat之類的 Web Container要做的事情嗎？” InputReader 問道。
“是啊，所以一般情況下，你想用Session，必須得有個像Tomcat, Jetty這樣的Web Container才行，但是如果你使用了我們的JSecurity， 根本不用什么Tomcat, Jetty，我們對Session內置是支持的，也就是說即使是桌面應用，也可以使用Session：”
Subject currentUser = SecurityUtils.getSubject();
Session session = currentUser.getSession();
session.setAttribute( "someKey", someValue);
“這是個不錯的賣點啊！” InputReader 對IO大臣使眼色。
“還有什么功能？ ” IO大臣胃口不小。
“我們還提供了一些工具類，可以進行加密， 當然了，我們還對Web開發提供了強大的支持。”
“大人，屬下覺得這個API設計得確實挺簡單的，比那個JAAS清爽多了”。InputReader對IO大臣說道。
6尾聲
IO大臣很高興，意氣風發，充滿正義，他鏗鏘有力地說：“ 我們陛下乃一代圣君，但是被JAAS這些大臣給蒙蔽了，這樣下去，民不聊生，Java帝國就要亡了，明天老夫就去參它一本！”
雷秀才看到當朝大員肯為自己出頭，感動得無以復加。
可是InputReader拉過IO大臣悄悄地說：“大人，這個JAAS歷經兩代國王的努力才進入JDK， 充分代表了豪門望族的利益，再說JAAS大臣是國王身邊的紅人， 不可能說廢就廢，您要這么上奏，肯定碰釘子， 還得曲線救國。”
“曲線救國？”
“屬下建議先讓這個JSecurity 開源了， 讓它加入著名的民間組織Apache，先讓臣民們用起來，咱們暗中再資助一下，這么好用的東西肯定能形成氣候， 等到呈星火燎原之勢，我們的陛下也不得不讓步，到時候JAAS大臣估計就要倒臺了。”
IO大臣點頭贊許。
第二天，雷秀才被送往Apache , 在那里JSeurity被改名為Shiro，開始向民間傳播。
果然，幾年以后，越來越多的人喜歡上了Shiro, JAAS備受冷落，國王見狀，只好讓JAAS大臣回家養老去了。
【本文為51CTO專欄作者“劉欣”的原創稿件，轉載請通過作者微信公眾號coderising獲取授權】
