- 浏览: 168406 次
- 性别:
- 来自: 北京
-
文章分类
最新评论
<!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><!--[if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning /> <w:DrawingGridVerticalSpacing>7.8 磅</w:DrawingGridVerticalSpacing> <w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery> <w:DisplayVerticalDrawingGridEvery>2</w:DisplayVerticalDrawingGridEvery> <w:Compatibility> <w:SpaceForUL /> <w:BalanceSingleByteDoubleByteWidth /> <w:DoNotLeaveBackslashAlone /> <w:ULTrailSpace /> <w:DoNotExpandShiftReturn /> <w:AdjustLineHeightInTable /> <w:BreakWrappedTables /> <w:SnapToGridInCell /> <w:WrapTextWithPunct /> <w:UseAsianBreakRules /> <w:UseFELayout /> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--> <!--[if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:宋体; mso-ascii-font-family:"Times New Roman"; mso-hansi-font-family:"Times New Roman";} table.MsoTableGrid {mso-style-name:网格型; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; border:solid windowtext 1.0pt; mso-border-alt:solid windowtext .5pt; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-border-insideh:.5pt solid windowtext; mso-border-insidev:.5pt solid windowtext; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; mso-pagination:none; font-size:10.0pt; font-family:宋体; mso-ascii-font-family:"Times New Roman"; mso-hansi-font-family:"Times New Roman";} </style> <![endif]-->
Spring Security优劣之我见
拜读了Spring Security相关帖子和Spring Security参考文档。现将我理解的Spring Security写下来和大家共享。
本文目的是从Spring Security能够提供的功能、以及基本原理角度分析，并不深入到如何编码。然后反过来，审查我们的软件系统需要哪些权限控制。进而评审Spring Security的适用性。
本文力求文字简单，概念也简单。
--------------------------------------------------------------
文章大纲：
Spring Security 如何控制权限
概要
与WEB系统的集成
控制内容
细粒度权限控制
我们理想中的权限管理
客户对权限管理的需求
开发中遇到的难点
我们理想的权限管理
Spring Security的评价
优点
缺点
--------------------------------------------------------------
Spring Security如何控制权限
概要
Spring使用由Filter组成的Chain，来判断权限。如下图所示：
<!--[if gte vml 1]><v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75" o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f"> <v:stroke joinstyle="miter" /> <v:formulas> <v:f eqn="if lineDrawn pixelLineWidth 0" /> <v:f eqn="sum @0 1 0" /> <v:f eqn="sum 0 0 @1" /> <v:f eqn="prod @2 1 2" /> <v:f eqn="prod @3 21600 pixelWidth" /> <v:f eqn="prod @3 21600 pixelHeight" /> <v:f eqn="sum @0 0 1" /> <v:f eqn="prod @6 1 2" /> <v:f eqn="prod @7 21600 pixelWidth" /> <v:f eqn="sum @8 21600 0" /> <v:f eqn="prod @7 21600 pixelHeight" /> <v:f eqn="sum @10 21600 0" /> </v:formulas> <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect" /> <o:lock v:ext="edit" aspectratio="t" /> </v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" style="width:414.75pt; height:174pt" mce_style="width:414.75pt; height:174pt"> <v:imagedata src="file:///C:\DOCUME~1\back\LOCALS~1\Temp\msohtml1\01\clip_image001.png" mce_src="file:///C:\DOCUME~1\back\LOCALS~1\Temp\msohtml1\01\clip_image001.png" o:title=""Ĥ" /> </v:shape><![endif]--><!--[if !vml]--><!--[endif]-->
Spring预定义了很多out-of-boxed filter供开发者直接使用。
每个Filter一般情况下（有些Filter是abstract的），都和配置文件的一个元素（有的情况下可能是属性）对应。
比如：AUTHENTICATION_PROCESSING_FILTER，对应配置文件里面的：http/form-login元素。
如果Spring提供的Filter不能满足系统的权限功能，开发者可以自定义Filter，然后把Filter放在某个Filter Chain的某个位置。可以替换掉原有Filter Chain的某个Filter，也可以放在某个Filter之前或者之后。
总之，Spring Security采用Filter Chain模式判断权限，Spring提供了一些Filter，也支持开发者自定义Filter。
与WEB系统的集成
使用Java EE的Filter（非Spring的Filter）机制，将需要权限判断的url，“牵引”给Spring的Filter Chain即可。
一般情况下，将所有的url都引入Filter Chain。当然也可以在web.xml配置需要权限判断的url（配置filter-mapping/url-pattern）。Spring的配置文件也支持过滤掉不需要权限判断的url（配置http/intercept-url元素）。
控制内容
Spring Security提供了如下内容的控制：
<!--[if !supportLists]-->1. <!--[endif]-->url；
<!--[if !supportLists]-->2. <!--[endif]-->bean method；
<!--[if !supportLists]-->3. <!--[endif]-->http session。
url：可以分为需要权限判断的url，不需要权限判断的url，登录表单url。通过我对spring相关帖子和参考文档的阅读，需要权限判断的url。仅限于做角色判断，就是说判断当前用户是否具有指定的角色。
bean method：Spring支持对Service layer method做权限判断。通过我对spring相关帖子和参考文档的阅读，也仅限于做角色判断。配置方式有2种：
<!--[if !supportLists]-->1. <!--[endif]-->写在Java源代码里面，如：@Secured("ROLE_TELLER")（该方法只有具有TELLER角色的用户能够访问，否则抛出异常）；
<!--[if !supportLists]-->2. <!--[endif]-->写在配置文件里面，如：<protect method="set*" access="ROLE_ADMIN" />（该bean的所有set方法，只有具有ADMIN角色的用户能够访问，否则抛出异常）。
http session：控制一个用户名是否能重复登录，以及重复登录次数，并非重试密码次数。
另外，Spring Security还提供了如下一些功能：
<!--[if !supportLists]-->1. <!--[endif]-->remember me，记住我；
<!--[if !supportLists]-->2. <!--[endif]-->form-login登录控制；
<!--[if !supportLists]-->3. <!--[endif]-->多种身份认证功能；
<!--[if !supportLists]-->4. <!--[endif]-->用户密码加密和“salt”功能；
<!--[if !supportLists]-->5. <!--[endif]-->http协议控制；
<!--[if !supportLists]-->6. <!--[endif]-->访问端口控制；
<!--[if !supportLists]-->7. <!--[endif]-->Pre-Invocation & After-Invocation。
remember me，记住我：还记得浏览器采用cookie记住用户名和密码自动登录吗？好像就是这个（不知道我理解错了没有，应该没有。只是我不大敢相信）。使用这个功能，开发者在登录页面，使用spring自定义的标签。
form-login登录控制：有些页面不允许匿名访问，那么当匿名访问这些页面的时候，将弹出（或者转到）form-login窗口（或者页面）。这里又牵引出2个问题：1，输入用户名和密码后怎样验证；2，密码是否需要加密，怎么加密。
多种身份认证功能：Spring提供了丰富的用户身份认证功能。身份认证是什么意思？比如您告诉我“我是神仙”。那么我会问您“凭什么证明您是神仙”。这就是身份认证。认证手段一般是保存到数据库表的用户名/密码，usb key，ldap等。一般情况下，我们都使用用户名/密码的。
用户密码加密和“salt”功能：密码采用md5，还是sha加密算法。如果我们对密码加密的时候，不想仅仅对密码加密，还想把用户名和密码放在一起加密做为加密后的密码。那么使用salt吧。salt支持也读取用户的其他属性，不仅是用户名。
http协议控制：哪些url，必须采用https访问呢？哪些url必须采用http访问呢？哪些又两者都可以呢？通过这个配置。
访问端口控制：类似http协议控制，控制url和访问端口之间的关系。
Pre-Invocation & After-Invocation：在方法调用之前做权限判断，还是方法调用之后做权限判断呢？一般情况下是之前调用。也有情况下是之后调用。具体例子可以看官方文档（22.3小节）。
细粒度权限控制
由上面分析，我们看到url、method的权限判断，都仅限于用户角色权限判断。事实上Spring使用投票（Voter）机制，来做权限判断。用户角色权限也是一种投票。
投票这个词，听起来不容易懂。举例：董事会开会，各个股东投票以表决决议是否通过。Spring的角色投票器，只会投出一票。我们平时所说的投票至少要2张票吧，一张还叫什么投票。Spring的投票有3种结果：允许、拒绝和弃权。弃权？真的有点晕。呵呵，这种情况下还弃权。
那么投票器，如何集成到Spring的Filter里面呢？
Spring的Filter一般都由一个Manager支撑着。比如accessDecisionManager，可以由RoleVoter和BasicAclEntryVoter提供投票。accessDecisionManager根据RoleVoter，BasicAclEntryVoter投票结果，做出决策判断。
细粒度（数据级）的权限控制，Spring Security提供了一种模型以及相关实现。下面我简要说说这个模型。
举例：张三授权查询华北区域客户资料，李四授权查询华南区域客户资料。那么，首先会对所有客户记录做个标示（相当于取个id），然后在acl-entry表给张三授权华北所有客户访问权限；给李四华南区域所有客户权限。表记录大致是这样的：
|
访问用户 |
被访问数据 |
授权操作 |
|
张三 |
华北电力客户1 |
读取 |
|
张三 |
华北电力客户2 |
读取 |
|
李四 |
华南电力客户1 |
读取 |
|
… |
… |
… |
这个模型的缺点是非常明显的：
<!--[if !supportLists]-->1. <!--[endif]-->和业务数据绑定死了，业务数据的增/删，需要维护该权限表；
<!--[if !supportLists]-->2. <!--[endif]-->在大数据量的情况下，系统效率低下。
因此，开发者需要自己书写投票器了。
我们理想中的权限管理
客户对权限管理的需求
这里是指我们服务的最终用户，而不是软件开发者。客户对权限管理的需求，大体可以概括如下：
<!--[if !supportLists]-->1. <!--[endif]-->自主灵活地管理角色、角色权限，并将角色赋予系统相关用户；
<!--[if !supportLists]-->2. <!--[endif]-->数据安全。系统展现数据是满足权限的，在系统内部搜索数据也必须在相应权限访问内，对系统数据进行增加、修改、删除必须是满足权限的；
<!--[if !supportLists]-->3. <!--[endif]-->没有功能的按钮、菜单、数据等等，就不要在界面上出现了。
开发中遇到的难点
管理用户、角色、权限，以及三者之间的关系，这种典型的RBAC模型，非常容易，没有任何困难。
困难的是，数据级权限控制。这是和业务直接挂钩的，最复杂，而且会经常因为客户需求表达不到位、开发人员需求理解不到位、系统框架库表结构发生变化，而不断变化的。
这种变化，不仅需要编码，而且还需要重新测试。甚至这种变化会波及到其他模块，甚至整个系统。
系统开发经历几次变化下来，代码里面散布着if/else，散布着sql语句。导致bad smell。
我们理想的权限管理
我们期望的权限管理，应该具有这么几个特性：
<!--[if !supportLists]-->1. <!--[endif]-->能实现角色级权限；能实现数据级权限；
<!--[if !supportLists]-->2. <!--[endif]-->简单、易操作，能够应对各种需求；
<!--[if !supportLists]-->3. <!--[endif]-->应对需求变更能力强；
<!--[if !supportLists]-->4. <!--[endif]-->最好有相关界面，比如权限管理界面、角色管理界面，角色和权限关系维护界面，用户和角色关系维护界面。如果没有界面，也是可以接受的。毕竟这些页面需要最终用户来使用，不同用户对系统的界面要求不同。因此我们并不期望统一的管理界面。
Spring Security的评价
在Spring Security世界里，可以区分出哪些资源可以匿名访问，哪些需要角色权限，又是哪个页面提供登录功能；怎样进行用户身份认证，用户的密码如何加密。哪些资源必须使用https协议，资源和访问端口有怎样的对应关系。
下面就优点和缺点对Spring Security进行点评。
优点
总体说来Spring Security具有以下几个优点：
<!--[if !supportLists]-->1. <!--[endif]-->提供了一套权限框架，这套框架是可行的；
<!--[if !supportLists]-->2. <!--[endif]-->提供了很多用户身份认证功能，可以节约大量开发工作；
<!--[if !supportLists]-->3. <!--[endif]-->提供了角色判断功能，这点既是优点又是缺点；
<!--[if !supportLists]-->4. <!--[endif]-->提供了form-login、remember me等控制。
其中2、4两点，对于我们中国开发者（我对国外系统不大了解），可用性并不大。我们的系统大多采用用户名/密码身份认证模式，大多公司都有可复用代码。form-login、remember me等这些功能，并不是难以开发，而且可用之处也并不多。
缺点
我个人认为Spring Security存在以下几个硬伤：
<!--[if !supportLists]-->1. <!--[endif]-->角色被“编码”到配置文件和源文件，这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中，客户可能并不能确定有哪些角色，以及角色怎么分配给系统用户。角色大多需要等到系统上线后，才能确定。这些编码有：
<!--[if !supportLists]-->a) <!--[endif]-->url的权限控制，<intercept-url pattern="/**" access="ROLE_USER" />；
<!--[if !supportLists]-->b) <!--[endif]-->java方法的权限控制，@Secured("IS_AUTHENTICATED_ANONYMOUSLY")；
<!--[if !supportLists]-->c) <!--[endif]-->java方法的权限控制，<protect method="set*" access="ROLE_ADMIN" />；
<!--[if !supportLists]-->2. <!--[endif]-->RBCA这种被广泛运用的模型，没有在Spring Security体现出来；
<!--[if !supportLists]-->3. <!--[endif]-->Spring Security没有提供好的细粒度（数据级）权限方案，提供的缺省实现维护工作量大，在大数据量情况下，几乎不可用；
<!--[if !supportLists]-->4. <!--[endif]-->Spring Security对于用户、角色、权限之间的关系，没有提供任何一种维护界面。不过从Spring Security角度看，确实没有必要有界面。角色创建、角色和权限直接的关系，都被“编码”到配置文件和源文件了；
<!--[if !supportLists]-->5. <!--[endif]-->Spring Security学习难度大，配置文件还是很多。我承认有很多高手，但我们也看到有很多新人加入软件开发领域。付出如此大的学习代价，获得这么一点点好处，个人觉得并不值得。
附言：
本人在JavaEye创建“权限管理”圈子快2周了，吸引不少网友进来。我感到很高兴，也很荣幸。由于Spring Security运用范围还是比较广的，所以我打算好好学习一下，把学习经验和大家分享一下。
欢迎大家加入“权限管理”圈子讨论，探讨对权限管理的认识、看法、建议等等。
http://accessmanager.group.iteye.com/
评论
1. 角色被“编码”到配置文件和源文件，这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中，客户可能并不能确定有哪些角色，以及角色怎么分配给系统用户。角色大多需要等到系统上线后，才能确定。这些编码有：
a) url的权限控制，<intercept-url pattern="/**" access="ROLE_USER" />；
b) java方法的权限控制，@Secured("IS_AUTHENTICATED_ANONYMOUSLY")；
c) java方法的权限控制，<protect method="set*" access="ROLE_ADMIN" />；
从Acegi时代就支持了, 主要是重新实现下FilterInvocationDefinitionSource这个类.
参考SpringSide
http://www.springside.org.cn/docs/reference/Acegi4.htm
2. RBCA这种被广泛运用的模型，没有在Spring Security体现出来；
Spring Security支持RBCA, Spring Security sample里是users和authorities两层权限控制, 再加一层role或二层没什么本质区别.
以前做过一个系统权限控制比较麻烦,分了user,role,permission,resource四层.
3. Spring Security没有提供好的细粒度（数据级）权限方案，提供的缺省实现维护工作量大，在大数据量情况下，几乎不可用；
数据级权限控制,觉得LZ提的可能是ACL(Access Control Lists) Based Security. ACL和RBAC这两种安全控制模型差异很大,这个貌似Spring Security不支持的吧? 有了解的童鞋可以跟贴解释下
http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsACLBasedSecurity.html
ROLE应该粗粒度的控制，通常是平行的，不适合做细粒度的控制.
权限集合通常是树形的，一个大集合里面包括小集合，甚至一个大集合里面的两个小集合部分重叠。大集合包括基本权限，小集合包括特殊权限，把某个用户置于一个圈子里，那他应具有所有包含他的圈子的权限。
ROLE_1,ROLE_2,ROLE_1_2,ROLE_2_3表示起来不直观，不好管理。所以Spring Security（SS）做完所有事情是不可能的。而SS却能很好的和WEB容器和Bean容器打交到，而且也很完善，所以自己开发一套系统不借助SS,也是耗费很大的，而且不一定没漏洞。
折中的办法是两者结合。成型的权限系统很少是纯SS的,通常SS管大方向和容器打交道，另外一套可以方便嵌入到SS的权限系统。
ACL模型基于这种“圈子”结构可以简化信息量，当然“圈子”的管理工具要做到足够好。
ACL模型最突出的矛盾是ACL信息的粒度和系统能提供的信息容量和通道的矛盾，大粒度的ACL可以将一个圈子里的人设置位是否具有某个权限。但现实情况是企业人员是不断变动的，而且权限也是不断变化的，权限回收和授予的矛盾就成了主要矛盾。
一个权限控制的物件被控制得越精细，需要的数据流量就越大，权限的回收和授予造成的瓶颈就越大。单一数据库或者LDAP的解决方式越来越难满足了，将来的发展方向应该放在云计算、MapReduce、分布式存储。
所以我觉得难点应该在权限的管理和权限可以被怎么存取。
http://metadmin.iteye.com/blog/359533
Spring Security的模型非常简单，只是通过5张表来建立访问关系。User、Role、Resource和他们互相之间的关联表。所以用户自定义角色，也只是在这5张表的数据中做文章。比如说，你要新建一个用户，只是往User表中添加记录；新建一个角色，只是往Role里面添加一条记录；新建一种访问资源，在Resource表中添加记录。并且在互相之间的关联表中指明用户的角色和资源访问关系。
Spring Security对于所有未列在配置中的URL，默认也会走所有的Filter链，所以完全不必在配置文件中对URL与角色的关系做一一指定，你甚至可以在runtime的时候指定上面提到的5张表的关系。这样就可以做到用户自定义角色和资源访问权限了。
至于说到数据访问权限，我的经验还不够丰富，在我看来很难建立一套成熟而松耦合的机制，所以我对楼主所谓不需要写一行代码就能完成数据访问权限非常好奇，楼主可以另开一贴向大家交流一下。
那个role就是角色了。
实现的方法：
1、实现UserDetailsService的public UserDetails loadUserByUsername(String username)
从数据库取用户资料，返回的这个UserDetails 包括用户名、密码、状态还有该用户关联的角色。
2、实现FilterInvocationDefinitionSource的public ConfigAttributeDefinition getAttributes(Object obj)，此方法根据请求的URL从数据库找到对应的资源及该资源关联的角色。
3、当然，前提是你的数据库里有这些表：user、role、resource、user_role、role_resource
剩下的事情就由SpringSecurity来计算了，比如投票决定某人是否可以访问某url、调用某方法
讨论的role是基于这个问题的。
角色被“编码”到配置文件和源文件，这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中，客户可能并不能确定有哪些角色，以及角色怎么分配给系统用户。角色大多需要等到系统上线后，才能确定。这些编码有：
请教一下downpour，您说的Spring Security也可以让最终用户控制角色，您采取什么好的方法呢？
我想到的方法是：将官方文档的role理解成权限，然后想rbac模型那样维护角色、权限和用户之间关系。
Spring Security层次，覆盖UserDetails.getAuthorities() 的SQL语句。不值得是否可行，我没有实验过。
Spring Security对数据级的权限控制模型，不好。我也不会说是Spring Security的错，只会说这是缺点。
这种数据级权限控制，是否能够通用。这个主题，我研究了4年多了。目前，我们实现到可以不用编码就能把权限给配出来。
那个role就是角色了。
实现的方法：
1、实现UserDetailsService的public UserDetails loadUserByUsername(String username)
从数据库取用户资料，返回的这个UserDetails 包括用户名、密码、状态还有该用户关联的角色。
2、实现FilterInvocationDefinitionSource的public ConfigAttributeDefinition getAttributes(Object obj)，此方法根据请求的URL从数据库找到对应的资源及该资源关联的角色。
3、当然，前提是你的数据库里有这些表：user、role、resource、user_role、role_resource
剩下的事情就由SpringSecurity来计算了，比如投票决定某人是否可以访问某url、调用某方法
请采用spring security试试，配置文件简化了非常多。
请教一下downpour，您说的Spring Security也可以让最终用户控制角色，您采取什么好的方法呢？
我想到的方法是：将官方文档的role理解成权限，然后想rbac模型那样维护角色、权限和用户之间关系。
Spring Security层次，覆盖UserDetails.getAuthorities() 的SQL语句。不值得是否可行，我没有实验过。
Spring Security对数据级的权限控制模型，不好。我也不会说是Spring Security的错，只会说这是缺点。
这种数据级权限控制，是否能够通用。这个主题，我研究了4年多了。目前，我们实现到可以不用编码就能把权限给配出来。
a) url的权限控制，<intercept-url pattern="/**" access="ROLE_USER" />；
b) java方法的权限控制，@Secured("IS_AUTHENTICATED_ANONYMOUSLY")；
c) java方法的权限控制，<protect method="set*" access="ROLE_ADMIN" />；
实际上Spring Security是可以对角色进行定义的，最终用户也可以自由创建并控制角色。所以这并不是Spring Security的问题。
目前Spring Security提供了比较简化的配置方式，但是我用下来，由于许多内容都需要覆盖默认的实现方式来配合项目，所以使用起来还是会碰到不少困难的。对初学者来说，的确有些学习的坡度。
另外就是Spring Security对于数据访问权限的控制，的确没有提供一个很完善的解决方案，ACL的实现方式我个人不是很赞同其中的理念。不过我认为这不能作为Spring Security的错，因为本身它的模型基础就比较简单，对于数据访问层面的权限解决，往往要深入到具体的SQL层面，这样就需要一个自上而下的一个完整的方案，这样的方案，在我看来是无法通用的。
to：开发中遇到的难点中
确实存在这样的问题，不过对于数据级别的权限控制，可以通过对Spring Security进行封装，提供给用户一个灵活的，可配置的数据权限管理功能。
Spring Security这套框架是可行的。数据级别的权限控制，力度很弱，需要开发者自己写VOTER。
您说的“封装”是指Voter呢？还是什么呢？望赐教。
能说的详细一点吗？？？
如果Spring Security仅限于做角色判断，那就很有问题啊。这个跟广泛使用的RBAC是矛盾的啊。
当时看到spring security文档，这么写，简直不敢相信。
确实存在这样的问题，不过对于数据级别的权限控制，可以通过对Spring Security进行封装，提供给用户一个灵活的，可配置的数据权限管理功能。
Spring Security这套框架是可行的。数据级别的权限控制，力度很弱，需要开发者自己写VOTER。
您说的“封装”是指Voter呢？还是什么呢？望赐教。
<div class="quote_div"><br />
<h2><span style="font-family: 黑体;">缺点</span></h2>
<p class="MsoNormal"><span style="font-family: 宋体;">我个人认为</span><span lang="EN-US">Spring
Security</span><span style="font-family: 宋体;">存在以下几个硬伤：</span></p>
<p class="MsoNormal" style="margin-left: 21pt; text-indent: -21pt;"><!--[if !supportLists]--><span lang="EN-US"><span>1.<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal; font-family: "Times New Roman";"> </span></span></span><!--[endif]--><span style="font-family: 宋体;">角色被“编码”到配置文件和源文件，这样最终用户就不能创建角色了。但最终用户期望自己来控制角色。因为在项目实施过程中，客户可能并不能确定有哪些角色，以及角色怎么分配给系统用户。角色大多需要等到系统上线后，才能确定。这些编码有：</span></p>
<p class="MsoNormal" style="margin-left: 42pt; text-indent: -21pt;"><!--[if !supportLists]--><span lang="EN-US"><span>a)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal; font-family: "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-US">url</span><span style="font-family: 宋体;">的权限控制，</span><span lang="EN-US"><intercept-url
pattern="/**" access="ROLE_USER" /></span><span style="font-family: 宋体;">；</span></p>
<p class="MsoNormal" style="margin-left: 42pt; text-indent: -21pt;"><!--[if !supportLists]--><span lang="EN-US"><span>b)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal; font-family: "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-US">java</span><span style="font-family: 宋体;">方法的权限控制，</span><span lang="EN-US">@Secured("IS_AUTHENTICATED_ANONYMOUSLY")</span><span style="font-family: 宋体;">；</span></p>
<p class="MsoNormal" style="margin-left: 42pt; text-indent: -21pt;"><!--[if !supportLists]--><span lang="EN-US"><span>c)<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-size-adjust: none; font-stretch: normal; font-family: "Times New Roman";"> </span></span></span><!--[endif]--><span lang="EN-US">java</span><span style="font-family: 宋体;">方法的权限控制，</span><span lang="EN-US"><protect
method="set*" access="ROLE_ADMIN" /></span><span style="font-family: 宋体;">；</span></p>
</div>
<p><br /><br />在 RBAC（用户-角色-权限）中，“角色”在中间层次，用于组织“权限”，可以把同一个“权限”分配给不同的“角色”。</p>
<p>所以各个功能模块中真正判断的是用户是否拥有某个“权限”，而不是“角色”。<br /><br />如果Spring Security仅限于做角色判断，那就很有问题啊。这个跟广泛使用的RBAC是矛盾的啊。</p>
<p> </p>
确实存在这样的问题，不过对于数据级别的权限控制，可以通过对Spring Security进行封装，提供给用户一个灵活的，可配置的数据权限管理功能。
发表评论
相关推荐
- **Spring Boot 如何进行安全控制，如使用 Spring Security？** - **Spring Boot 如何实现微服务间的通信，如使用 Spring Cloud？** 这些都是 Spring Boot 面试中可能会问到的问题，了解并掌握这些知识点将有助于...
3. **集成能力**：Spring MVC作为Spring框架的一部分，可以无缝集成Spring的其他模块，如Spring Data、Spring Security等，这对于大型企业级应用来说是一个显著优势。Struct2虽然也能与其他框架集成，但可能需要更多...
主要包含以下框架：docker、dubbo、elasticsearch、fastDFS、Git、hashMap、jvm、MongoDB、mybatis、nio、rabbitMQ、Redis、rocketMQ、socket编程、spring、springboot、springcloud、springsecurity、多线程、异常...
3. 安全性：利用Spring Security等安全框架，系统可以实现用户认证和授权，保护数据安全。 4. 移动友好：Vue.js的响应式设计，使得系统在不同设备上都能良好运行，满足移动办公需求。 总结，"springboot+vue营商...
总结，这个案例提供了一个从传统SSM框架向SpringBoot过渡的实例，帮助开发者理解两种框架的不同特性和优劣，以及如何进行系统升级。在实际开发中，根据项目需求选择合适的框架，结合最佳实践，能有效提升开发效率和...
5. **用户认证与授权**: 使用Spring Security或JWT进行用户身份验证和权限控制，确保系统安全。 6. **数据库设计**: 可能包括用户表、课程表、评价表等，涉及关系数据库的设计和优化。 7. **前端技术**: 可能使用...
源代码可能提供了对比SOAP和REST的实例，展示它们在复杂性和效率上的差异，以及在特定场景下的优劣选择。 5. 安全性与认证： Web服务的安全性是关键，包括WS-Security、OAuth、JWT等协议可能在源代码中有所体现。...
首先，SpringBoot 2.0是Java开发者的首选框架之一，它简化了传统的Spring应用程序的创建和部署过程，提供了自动配置、内嵌Servlet容器、健康检查和管理端点等功能。在这个项目中，SpringBoot作为基础框架，负责处理...
- **安全性考虑**：采用Spring Security框架来实现系统的身份认证和授权，保护敏感信息的安全。 #### 六、系统优势 - **高效性**：利用SpringBoot框架快速搭建系统架构，提高开发效率。 - **灵活性**：通过模块化...
- **安全性**：考虑到用户隐私和数据安全，可能应用了HTTPS、JWT令牌或Spring Security等安全措施。 总的来说，这个基于Java的KTV点歌系统源码为学习者提供了深入理解Web开发、Java技术以及娱乐系统设计的实践机会...
以下是我个人对Java中常用工具类的总结，主要涉及了加密、文件上传和日期处理等核心领域。 1. **加密工具类**： - `java.security` 包下的 `MessageDigest` 类用于实现消息摘要算法，如MD5和SHA，常用于数据完整性...
Remoting服务是BlazeDS的核心功能之一，它使得客户端可以直接调用服务器上的Java方法，就像它们是本地函数一样。这大大简化了客户端与服务器之间的通信，并减少了网络延迟。 4. **数据推送（Live Data Services）*...
关系型数据库如MySQL、PostgreSQL和非关系型数据库如MongoDB、Redis各有优劣，开发者需根据项目需求选择合适的数据库。 4. **服务器和部署**：Web应用运行在服务器上，开发者需要了解如何配置和管理服务器，以及...