控制器（Web请求 antMatcher）安全性与方法（服务）级安全性

控制器（Web请求/ antMatcher）安全性与方法（服务）级安全性

Web安全和方法安全是保护应用程序安全的两种不同方法，请参阅Spring Security
Reference
：

为什么不仅仅使用web.xml安全性？

假设您正在开发基于Spring的企业应用程序。通常需要解决四个安全问题：身份验证，Web请求安全性，服务层安全性（即，实现业务逻辑的方法）和域对象实例的安全性（即不同的域对象具有不同的权限）。牢记以下典型要求：

[…]

1. Web请求安全性：
   Servlet规范提供了一种保护请求URI的方法。但是，这些URI只能以Servlet规范自己的受限URI路径格式表示。Spring
   Security提供了一种更为全面的方法。例如，您可以使用Ant路径或正则表达式，可以考虑URI的一部分，而不仅仅是请求的页面（例如，可以考虑HTTP
   GET参数），并且可以实现自己的配置数据的运行时源。这意味着您的Web请求安全性可以在Webapp的实际执行过程中动态更改。
   
   

2. 服务层和域对象安全性：
   Servlet规范中缺少对服务层安全性或域对象实例安全性的支持，这表示对多层应用程序的严重限制。通常，开发人员要么忽略这些要求，要么在其MVC控制器代码中实现安全逻辑（或者更糟的是在视图内部）。这种方法有严重的缺点：

一个。 关注点分离：
授权是一个横切关注点，应照此实施。MVC控制器或实现授权代码的视图使测试控制器和授权逻辑更加困难，调试更加困难，并且通常会导致代码重复。

b。 对富客户端和Web服务的支持：
如果最终必须支持其他客户端类型，则嵌入在Web层中的任何授权代码都是不可重用的。应该考虑到Spring远程出口商仅出口服务层bean（而不是MVC控制器）。这样，授权逻辑需要位于服务层中以支持多种客户端类型。

C。 分层问题：
MVC控制器或视图只是错误的体系结构层，无法实现有关服务层方法或域对象实例的授权决策。尽管可以将主体传递到服务层以使其能够做出授权决策，但这样做会在每个服务层方法上引入一个附加参数。一种更优雅的方法是使用ThreadLocal来容纳Principal，尽管这可能会增加开发时间，以至于仅使用专用的安全框架就变得更加经济（基于成本效益）。

d。 授权代码质量：
Web框架经常被提及为“它们使做正确的事变得更容易，而做错事则更难”。安全框架是相同的，因为它们以抽象的方式设计用于多种用途。从头开始编写自己的授权代码并不能提供框架所提供的“设计检查”，而且内部授权代码通常将缺乏广泛部署，同行评审和新版本带来的改进。

Spring Security建议方法安全性，请参阅Spring Security
Reference：

10.1.4请求匹配和HttpFirewall

[…]

在实践中，我们建议您在服务层使用方法安全性来控制对应用程序的访问，并且不要完全依赖于在Web应用程序级别定义的安全性约束的使用。URL会发生变化，很难考虑应用程序可能支持的所有可能的URL以及如何处理请求。您应该尝试限制自己使用一些简单易懂的简单蚂蚁路径。始终尝试使用“默认拒绝”方法，在此方法中，您最后定义了一个全包通配符（/或），并拒绝访问。

在服务层定义的安全性更健壮，更难绕开，因此您应该始终利用Spring Security的方法安全性选项。

Spring Security建议在服务层而不是在单个Web控制器上应用方法安全性，请参阅Spring Security
Reference：

我已经将Spring Security的元素添加到了我的应用程序上下文中，但是如果我向Spring
MVC控制器bean（Struts *** 作等）添加了安全注释，那么它们似乎没有作用。

[…]

通常，我们建议在服务层而不是单个Web控制器上应用方法安全性。