虽然目前 Spring Security 一片火热,但是 Shiro 的市场依然存在,今天我就来稍微的说一说这两个框架的,方便大家在实际项目中选择适合自己的安全管理框架。
首先我要声明一点,框架无所谓好坏,关键是适合当前项目场景,作为一个年轻的程序员更不应该厚此薄彼,或者拒绝学习某一个框架。
小孩子才做选择题,成年人两个都要学!
所以接下来主要结合我自己的经验来说一说这两个框架的优缺点,没有提到的地方也欢迎大家留言补充。
Spring Security 并非一个新生的事物,它最早不叫 Spring Security ,叫 Acegi Security,叫 Acegi Security 并不是说它和 Spring 就没有关系了,它依然是为 Spring 框架提供安全支持的。事实上,Java 领域的框架,很少有框架能够脱离 Spring 框架独立存在。
当 Spring Security 还叫 Acegi Security 的时候,虽然功能也还可以,但是实际上这个东西并没有广泛流行开来。最重要的原因就是它的配置太过于繁琐,当时网上流传一句话:“每当有人要使用 Acegi Security,就会有一个精灵死去。” 足见 Acegi Security 的配置是多么可怕。直到今天,当人们谈起 Spring Security 的时候,依然在吐槽它的配置繁琐。
后来 Acegi Security 投入 Spring 的怀抱,改名叫 Spring Security,事情才慢慢开始发生变化。新的开发团队一直在尽力简化 Spring Security 的配置,Spring Security 的配置相比 Acegi Security 确实简化了很多。但是在最初的几年里,Spring Security 依然无法得到广泛的使用。
直到有一天 Spring Boot 像谜一般出现在江湖边缘,彻底颠覆了 JavaEE 的世界。一人得道鸡犬升天,自从 Spring Boot 火了之后,Spring 家族的产品都被带了一把,Spring Security 就是受益者之一,从此飞上枝头变凤凰。
Spring Boot/Spring Cloud 现在作为 Java 开发领域最最主流的技术栈,这一点大家应该都没有什么异议,而在 Spring Boot/Spring Cloud 中做安全管理,Spring Security 无疑是最方便的。
你想保护 Spring Boot 中的接口,添加一个 Spring Security 的依赖即可,事情就搞定了,所有接口就保护起来了,甚至不需要一行配置。
有小伙伴可能觉得这个太笼统了,我再举一个实际点的例子。
在微服务架构的项目中,我们可能使用 Eureka 做服务注册中心,默认情况下,Eureka 没有做安全管理,如果你想给 Eureka 添加安全管理,只需要添加 Spring Security 依赖,然后在application.properties 中配置一下用户名密码即可,Eureka 就自动被保护起来了,别人无法轻易访问;然后各个微服务在注册的时候,只需要把注册地址改为 http://username:password@localhost:8080/eureka 即可。类似的例子还有 Spring Cloud Config 中的安全管理。
在微服务这种场景下,如果你想用 Shiro 代替 Spring Security,那 Shiro 代码量绝对非常可观,Spring Security 则可以非常容易的集成到现在流行的 Spring Boot/Spring Cloud 技术栈中,可以和 Spring Boot、Spring Cloud、Spring Social、WebSocket 等非常方便的整合。
所以我说,因为 Spring Boot/Spring Cloud 火爆,让 Spring Security 跟着沾了一把光。
如果是 SSM + Spring Security 的话,我觉得这话有一定道理。
但是如果是 Spring Boot 项目的话,其实并不见得臃肿。Spring Boot 中,通过自动化配置 starter 已经极大的简化了 Spring Security 的配置,我们只需要做少量的定制的就可以实现认证和授权了。
「有人觉得 Spring Security 中概念复杂。」这个是这样的,没错。
Spring Security 由于功能比较多,支持 OAuth2 等原因,就显得比较重量级,不像 Shiro 那样轻便。
但是如果换一个角度,你可能会有不一样的感受。
在 Spring Security 中你会学习到许多安全管理相关的概念,以及常见的安全攻击。这些安全攻击,如果你不是 web 安全方面的专家,很多可能存在的 web 攻击和漏洞你可能很难想到,而 Spring Security 则把这些安全问题都给我们罗列出来并且给出了相应的解决方案。
所以我说,我们学习 Spring Security 的过程,也是在学习 web 安全,各种各样的安全攻击、各种各样的登录方式、各种各样你能想到或者想不到的安全问题,Spring Security 都给我们罗列出来了,并且给出了解决方案,从这个角度来看,你会发现 Spring Security 好像也不是那么让人讨厌。
除了前面和大家介绍的 Spring Security 优势,在微服务中,Spring 官方推出了 Spring Cloud Security 和 Spring Cloud OAuth2,结合微服务这种分布式特性,可以让我们更加方便的在微服务中使用 Spring Security 和 OAuth2,松哥前面的 OAuth2 系列实际上都是基于 Spring Cloud Security 来做的。
可以看到,Spring 官方一直在积极进取,让 Spring Security 能够更好的集成进微服务中。
接下来我们再说说 Apache Shiro。
Apache Shiro 是一个开源安全框架,提供身份验证、授权、密码学和会话管理。Shiro 框架具有直观、易用等特性,同时也能提供健壮的安全性,虽然它的功能不如 Spring Security 那么强大,但是在常规的企业级应用中,其实也够用了。
Shiro 的前身是 JSecurity,2004 年,Les Hazlewood 和 Jeremy Haile 创办了 Jsecurity。当时他们找不到适用于应用程序级别的合适 Java 安全框架,同时又对 JAAS 非常失望,于是就搞了这个东西。
2004 年到 2008 年期间,JSecurity 托管在 SourceForge 上,贡献者包括 Peter Ledbrook、Alan Ditzel 和 Tim Veil。
2008 年,JSecurity 项目贡献给了 Apache 软件基金会(ASF),并被接纳成为 Apache Incubator 项目,由导师管理,目标是成为一个顶级 Apache 项目。期间,Jsecurity 曾短暂更名为 Ki,随后因商标问题被社区更名为“Shiro”。随后项目持续在 Apache Incubator 中孵化,并增加了贡献者 Kalle Korhonen。
2010 年 7 月,Shiro 社区发布了 1.0 版,随后社区创建了其项目管理委员会,并选举 Les Hazlewood 为主席。2010 年 9 月 22 日,Shrio 成为 Apache 软件基金会的顶级项目(TLP)。
Apache Shiro 是一个强大而灵活的开源安全框架,它干净利落地处理身份认证,授权,企业会话管理和加密。Apache Shiro 的首要目标是易于使用和理解。安全有时候是很复杂的,甚至是痛苦的,但它没有必要这样。框架应该尽可能掩盖复杂的地方,露出一个干净而直观的 API,来简化开发人员在应用程序安全上所花费的时间。
以下是你可以用 Apache Shiro 所做的事情:
Apache Shiro 是一个拥有许多功能的综合性的程序安全框架。下面的图表展示了 Shiro 的重点:
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PZZnuwFm-1657539003511)(https://upload-images.jianshu.io/upload_images/28142708-b3c2fe6b4d595b63.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)]
Shiro 中有四大基石——身份验证,授权,会话管理和加密。
除此之外,Shiro 也提供了额外的功能来解决在不同环境下所面临的安全问题,尤其是以下这些:
Shiro 的学习资料并不多,没看到有相关的书籍。张开涛的《跟我学Shiro》是一个非常不错的资料,小伙伴可以搜索了解下。也可以在公众号后台回复 2TB,有相关的视频教程。
就目前而言,Shiro 最大的问题在于和 Spring 家族的产品进行整合的时候非常不便,在 Spring Boot 推出的很长一段时间里,Shiro 都没有提供相应的 starter,后来虽然有一个 shiro-spring-boot-web-starter 出来,但是其实配置并没有简化多少。所以在 Spring Boot/Spring Cloud 技术栈的微服务项目中,Shiro 几乎不存在优势。
但是如果你是传统的 SSM 项目,不是微服务项目,那么无疑使用 Shiro 是最方便省事的,因为它足够简单,足够轻量级。
在公司里做开发,这两个要如何取舍,还是要考虑蛮多东西的。
首先,如果是基于 Spring Boot/Spring Cloud 的微服务项目,Spring Security 无疑是最方便的。
如果是就是普通的 SSM 项目,那么 Shiro 基本上也够用。
另外,选择技术栈的时候,我们可能也要考虑团队内工程师的技术栈,如果工程师更擅长 Shiro,那么无疑 Shiro 是合适的,毕竟让工程师去学习一门新的技术,一来可能影响项目进度,而来也可能给项目埋下许多未知的雷。
对于我们个人来说,小孩子才做选择题,成年人两个都要学。