Java帝國之安全爭鬥

來自：碼農翻身（微訊號：coderising）

在Java帝國第三代國王的推動下，帝國對臣民們提供了一個叫做Java 認證與授權服務（Java Authentication Authorization Service, 簡稱JAAS）的東西, 在第四代國王的爭取下， JAAS成功地進入了JDK，成為了標準包的一部分。

國王希望JAAS能夠一統安全領域，像JDBC那樣引發使用的狂潮，成為一個重要的基礎設施，特意設定了一個新職位JAAS大臣，任命了一個自己的心腹去推動這件事情。

可是希望越大，失望就越大，除了幾家利益相關的豪門望族在不斷地搖旗吶喊之外，臣民們對JAAS不屑一顧，沒多少人使用。

IO大臣這一天在家裡閑得無聊， 帶著忠心耿耿的幕僚InputReader 出去微服私訪，來到了京城一個著名的酒館，點了幾樣精緻小菜，一壺美酒。還沒開吃，就看到鄰桌的一個書生在唉聲嘆氣。

IO大臣心中一動，就把他叫過來一起聊聊。

原來這位書生是雷秀才，說是家鄉賦稅沉重，都沒法活下去了，特意來京城上訪，無奈不得其法，連門都進不去。

IO大臣起了好奇心，忙問是怎麼回事。

雷秀才說：“都是JAAS惹得禍。”

“JAAS？”

“就是認證和授權嘛！”  雷秀才看到對方不知道，略有失望之色。

“認證？ 授權？”

“認證就是確定你是誰， 通常需要驗證對方提供的使用者名稱和密碼。  授權就是確定你能做什麼。比如能否建立賬號，能夠刪除使用者等等。”

“呃呃，想起來了，為什麼不用官方的JAAS，帝國的標準還是挺好的嘛，比如JDBC。”

“老先生您有所不知，JDBC標準自然是沒得說， 但是這個JAAS，唉，用起來極為繁瑣，大家都不願意使用。可是那個JAAS大臣根本不管這些，一直瘋狂地推廣JAAS， 如果不用，就要課以重稅， 我們都活不下去了。”

“這倒是有點麻煩，你們打算怎麼辦？”  IO大臣先去試探對方套路。

雷秀才壓低了聲音：“不瞞老先生，我們家族已經推出了一個新的認證和授權的系統，叫做JSecurity，想託京城的大人們獻給陛下，把JAAS替換掉。 ”

“哦？！”  IO大臣坐直了身體，這可是一件大事！

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大臣的覆轍。

（傳送門： Java帝國之宮廷內鬥(1)， Java帝國之宮廷內鬥(2)）

雷秀才道：“那是我們定義的一種許可權符號規則，格式是這樣的：資源:操作:實體， 用兩個冒號分開，例如：

user:create:U001 表示對使用者資源實體U001進行create操作

user:create 表示對資源進行create操作，相當於user:create:*

user:*:U001    表示對使用者資源實體01進行所有操作”

IO大臣點了點頭，格式由JSecurity定義，但是資料內容需要應用程式來確定。

InputReader突然說：“大人您記得提出Java註解的安翰林嗎， 如果這個JSecurity支援註解就好了。”

（傳送門： Java註解是怎麼成功上位的？）

雷秀才說：“支援支援，那個註解挺好用的。”

@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大臣覺得此處耳目眾多，不宜久留，提議回自己府上繼續商談。

三人回到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點點頭，看來他們考慮得挺仔細。很明顯，對於授權，也可以定義類似的策略。

雷秀才畫了一張圖，展示了認證和授權的架構：

“嗯，我覺得對於認證和授權，你們做得很不錯了！”  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大臣說道。

IO大臣很高興，意氣風發，充滿正義，他鏗鏘有力地說：“  我們陛下乃一代聖君，但是被JAAS這些大臣給矇蔽了，這樣下去，民不聊生，Java帝國就要亡了，明天老夫就去參它一本！”

雷秀才看到當朝大員肯為自己出頭，感動得無以復加。

可是InputReader拉過IO大臣悄悄地說：“大人，這個JAAS歷經兩代國王的努力才進入JDK， 充分代表了豪門望族的利益，再說JAAS大臣是國王身邊的紅人， 不可能說廢就廢，您要這麼上奏，肯定碰釘子， 還得曲線救國。”

“曲線救國？”

“屬下建議先讓這個JSecurity 開源了， 讓它加入著名的民間組織Apache，先讓臣民們用起來，咱們暗中再資助一下，這麼好用的東西肯定能形成氣候， 等到呈星火燎原之勢，我們的陛下也不得不讓步，到時候JAAS大臣估計就要倒臺了。”

IO大臣點頭贊許。

第二天，雷秀才被送往Apache , 在那裡JSeurity被改名為Shiro，開始向民間傳播。

果然，幾年以後，越來越多的人喜歡上了Shiro, JAAS備受冷落，國王見狀，只好讓JAAS大臣回家養老去了。

●編號644，輸入編號直達本文

●輸入m獲取文章目錄

更多推薦《18個技術類公眾微信》