我需要让一个遗留应用程序开始使用 spring security 3。
这个应用已经有它的安全数据模型：
到目前为止非常简单。我可以编写我的自定义usersByUsernameQuery 和authoritiesByUsernameQuery。
问题是有另一个表指示角色可以执行的操作（即@Service层方法）：
因此管理员可以启用/禁用角色通过 Web 界面访问操作，而无需重新部署应用程序。
例如，我仍然可以使用 @Secure('ROLE_ADMIN') 注释业务方法，但我的自定义 UserDetailsService 必须至少知道受保护的方法名称，这样我才能执行正确的查询。
所以，问题是：我的自定义 UserDetailsService 有没有办法拦截正在保护的方法的名称？
【问题讨论】：
标签： java jdbc spring-security legacy
听起来您的访问决策是基于“操作角色”，而不是用户角色，因此在 Spring Security 约束中直接使用“操作角色”可能会更好。这本质上是一种 RBAC 方法，其中用户角色与允许他们执行的操作之间存在映射。
您可以在AuthenticationProvider 而不是UserDetailsService 中解决该问题，方法是在其中添加一个映射层，将用户角色（由UserDetailsService 提供）转换为用户在应用程序中拥有的权限.这些将构成由AuthenticationProvider 创建的Authentication 对象中返回的权限集合。
映射层将直接使用您的管理界面提供的数据。
您可能想看看 Mike Weisner 的 this presentation，其中涵盖了类似的材料等内容。
并不是说 Spring Security 3.1 将包含一个额外的 GrantedAuthorityMapper 策略，以便更容易插入此类映射。
【讨论】：
UserDetailsService。很简单。我喜欢“操作角色”这个概念，它确实描述了这种类型的安全策略。