需求說明
不同的項目對於權限管理的需求也不同。以上海市人社管理系統爲例，權限管理主要管理的是不同單位與不同職級的工作人員所能夠操作的功能限制。可以通過組權限進行以單位爲基準的權限管理，少部分根據職級的再進行單獨管理（需求量比較小，不成規模體系，如主管單位操作基層單位功能），再將個人權限與組權限掛鉤。
詳細設計
1. 創建功能：基本信息，如所屬模塊、頁面路徑、所屬菜單等
2. 創建組：組別不同，訪問權限不同
3. 創建用戶：用戶所屬單位（級別）不同，組別不同，如根據省市/區縣/街道設置組別
4. 創建組與權限關聯：每個組所關聯的功能都有所不同，即權限不同
5. 創建用戶與組關聯：系統根據組別賦權（方式：返回無權限、加載限定功能等）
6. 創建用戶與權限關聯：系統根據用戶賦權，通常是組權限和用戶權限聯表查，開發者通常用來賦全部權限
實現方式
實現的方式有很多種，主要分前後端，至於是前端卡口還是後端卡口看業務，比如單位分級別，省市的，區的，街道的，每個級別的權限都不同，這就意味着可以操作的範圍不同。
如果說能明顯從id的設置看出來，比如00打頭是省市的，那麼就前端卡，但實際上後端也可以卡，就是一樣的判斷放後端。如果卡口放前端，那麼肯定權限相關的字段要能獲取到，比如直接放在session裏面（登錄的時候），這樣就能卡到權限了。
再打個比方，如果業務複雜一點，比如有一個功能是數據的查詢統計，省市獲取下級單位的彙總數據，區單位獲取街道的彙總數據，這個肯定也是權限管理的一部分，因爲你要判斷權限再去做統計，那麼這個情況下，前端還是後端？那就看在你的系統裏，哪個更便利且更利於系統的開發維護。
和朋友也討論過這個問題，他提出AOP的思想，比如每次請求判斷用戶權限，決定返回的頁面，也可以，但如果在功能重合性較多的項目中，區分主頁獲取是更簡單直接省系統消耗的方式吧。
權限配置
日常開發環境，如svn的權限、oracle庫表的訪問讀寫權限、linux文件權限等，歸根結底也是從開發需求發展而來，逐漸演變爲通過修改屬性配置就可以改變操作範圍的程度。