Spring Security之基于方法配置权限

前言

Spring Security有两种配置方式，今天重点是绍基于方法配置的方式。

基于方法配置权限

这个主要是有一些注解提供给大家使用，今天来给大家一个demo（参考自官方sample）。

maven就不多累赘了。重点看看配置。

• 基于角色配置

/**
 * 启用方法安全：@EnableMethodSecurity
 * 
 * 启用@secured注解: **securedEnabled = true**
 * <p>会导入配置：SecuredMethodSecurityConfiguration<p>
 * 
 * 启用@PreAuthorize@PostAuthorize@PreFilter@PostFilter：**prePostEnabled = false**
 * <p>会导入配置：PrePostMethodSecurityConfiguration</p>
 * 
 * 启用jsr250相关的安全注解：**jsr250Enabled = true**
 * <p>会导入配置：Jsr250MethodSecurityConfiguration</p>
 * <p>jsr250包括@RolesAllowed@PermitAll@DenyAll</p>
 */ 
@Configuration
@EnableMethodSecurity(securedEnabled = true, prePostEnabled = true, jsr250Enabled = true)
public class AspectjSecurityConfig {

}

/**
 * 这个类的所有方法都需要有ROLE_USER角色才能执行
 */
@Service
@Secured("ROLE_USER")
public class SecuredService {

	public void secureMethod() {
		// nothing
	}

}

@Service
public class SecuredService {
    

	public void publicMethod() {
		// nothing
	}
    /**
     * 这个方法需要ROLE_USER才能执行
     * 这三种配置方式都是等价的，只是提供支持的Advice不同。
     */ 
	@Secured("ROLE_USER")
    // @RolesAllowed("ROLE_USER")
    // @PreAuthorize("hasRole('ROLE_USER')")
	public void secureMethod() {
		// nothing
	}

	@PreAuthorize("arguments[0] ne 'tony'")
	// @PreAuthorize("filterObject ne 'tony'")
    public void preAuthorize(@RequestParam("userCode") String userCode) {
        // @preAuthorize不会赋值ROOT的filterObject和returnObject，因此无法使用入参。只能使用MethodSecurityExpressionRoot的其他方法
		// 这个方法的实验现象为：不管传什么都能通过表达式
        logger.info("preAuthorize:{}", userCode);
        // nothing
    }

    /** 	
     * 这个入参会被过滤地只剩下与authentication.name一样的
     */ 
	@PreFilter("filterObject == authentication.name")
	public void preFilter(@RequestParam("userCodeList") List<String> userCodeList) {
		// http://localhost:8090/foo/preFilter?userCodeList=leo,tony
        logger.info("preAuthorize:{}", userCode);
	}

    /**
     * 这个方法需要ROLE_USER才能执行
     */ 
	@PostAuthorize("returnObject ne 'tony'")
	public String postAuthorize(@RequestParam("userCode") String userCode) {
		// 传入的是不是tony，会抛出异常: 403
        logger.info("postAuthorize:{}", userCode);
		return userCode;
	}

    @GetMapping("/preAuthorizeSpel")
    @PreAuthorize("hasAuthority('permission:read') || hasRole('ADMIN')")
    public void preAuthorizeHasRole() {
        logger.info("preAuthorizeSpel:{}", userCode);
        // nothing
    }

    /**
     * 这个方法需要ROLE_USER才能执行
     */ 
	@PostFilter("returnObject == authentication.name")
	public List<String> PostFilter(@RequestParam("userCodeList") List<String> userCodeList) {
		// 实验结果就是，传入了的参数有值，但只有跟用户名一样的才会返回
        logger.info("PostFilter:{}", userCodeList);
		return userCodeList;
	}

}

以上就是怎么使用，接着我们看下是如何实现的。

基于方法授权方式的实现原理

前面我们说过，是基于AOP实现的。那么，现在我们从源码层面来看看。

我们可以看到上面按照@EnableMethodSecurity的配置，分别对应地导入三个配置。
但是，我们可以先从AOP的角度设想一下，我们需要的是哪种类型的通知？不妨归类一下：

注解类型	通知类型	描述/备注
@PreFilter@PreAuthorize@Secured以及JSR-250的相关注解	前置通知	这些很明显都是需要先校验/过滤参数再执行目标方法
@PostFilter@PostAuthorize	后置通知	先执行目标方法，再校验/过滤结果集

接着我们来看看Spring Security的设计：

AuthorizationManagerBeforeMethodInterceptor

在执行方法之前进行鉴权，这也意味着，当权限不足时，他会抛出异常。
实际上，他是一个通用的增强，全取决于你怎么使用它。
在SpringSecurity的配置里，他可以负责@PreAuthor，也可以负责@Secured，甚至还能负责jsr250的相关注解。
需要提醒一点，一个实例对象只能一种注解哈。

但是，大家有没有想过一个问题：为什么@PreAuthor@Secured以及jsr250的相关注解，都能交给他来处理？
又或者说，他的设计是如何将这三者的处理抽象统一起来的？更具体一点，此三者有何共同之处，可以进行抽象和统一的？？

要回答这个问题，我们需要先从这个三者的入手：
共同点：

都需要在执行方法前进行权限校验，校验不通过则都需要抛出异常，阻断方法调用。

异同点：

注解	配置描述	执行
@PreAuthorize	配置的是SPEL表达式	通过执行表达式来得出是否满足访问权限
@Secured	指定角色	需要校验当前用户是否拥有指定角色
jsr250的@PermitAll	-	任何人都可以访问
jsr250的@DenyAll	-	任何人都不能访问
jsr250的@RolesAllowed	指定角色	需要校验当前用户是否拥有指定角色

从共同点出发，本质上无非就是鉴权嘛，这不是很符合Spring Security的AuthorizationManager的职责吗？
然后就是不同点，我们发现无非就是权限的配置来源不同需要解析不同的注解咯。
有了这个思路，接下来我们翻找源码，理解起来就容易多了。

public final class AuthorizationManagerBeforeMethodInterceptor
		implements Ordered, MethodInterceptor, PointcutAdvisor, AopInfrastructureBean {
	// 构造器，需要传入Pointcut，和AuthorizationManager<MethodInvocation>，以便校验权限。
	public AuthorizationManagerBeforeMethodInterceptor(Pointcut pointcut,
			AuthorizationManager<MethodInvocation> authorizationManager) {
		Assert.notNull(pointcut, "pointcut cannot be null");
		Assert.notNull(authorizationManager, "authorizationManager cannot be null");
		this.pointcut = pointcut;
		this.authorizationManager = authorizationManager;
	}

	/**
	 * 创建负责处理@PreAuthorize的增强
	 */
	public static AuthorizationManagerBeforeMethodInterceptor preAuthorize(
			PreAuthorizeAuthorizationManager authorizationManager) {
		AuthorizationManagerBeforeMethodInterceptor interceptor = new AuthorizationManagerBeforeMethodInterceptor(
				AuthorizationMethodPointcuts.forAnnotations(PreAuthorize.class), authorizationManager);
		interceptor.setOrder(AuthorizationInterceptorsOrder.PRE_AUTHORIZE.getOrder());
		return interceptor;
	}

	/**
	 * 创建负责处理@Secured
	 */
	public static AuthorizationManagerBeforeMethodInterceptor secured(
			SecuredAuthorizationManager authorizationManager) {
		AuthorizationManagerBeforeMethodInterceptor interceptor = new AuthorizationManagerBeforeMethodInterceptor(
				AuthorizationMethodPointcuts.forAnnotations(Secured.class), authorizationManager);
		interceptor.setOrder(AuthorizationInterceptorsOrder.SECURED.getOrder());
		return interceptor;
	}

	/**
	 * 创建负责处理jsr250相关注解: @RolesAllow@PermitAll@DenyAll
	 */
	public static AuthorizationManagerBeforeMethodInterceptor jsr250(Jsr250AuthorizationManager authorizationManager) {
		AuthorizationManagerBeforeMethodInterceptor interceptor = new AuthorizationManagerBeforeMethodInterceptor(
				AuthorizationMethodPointcuts.forAnnotations(RolesAllowed.class, DenyAll.class, PermitAll.class),
				authorizationManager);
		interceptor.setOrder(AuthorizationInterceptorsOrder.JSR250.getOrder());
		return interceptor;
	}
	
	@Override
	public Object invoke(MethodInvocation mi) throws Throwable {
		// 校验权限
		attemptAuthorization(mi);
		return mi.proceed();
	}
	
	private void attemptAuthorization(MethodInvocation mi) {
		// 通过AuthorizationManager校验权限，这意味者AuthorizationManager必须具备解析相关注解的能力，实际上他交给了另外一个组件，后面会说到。
		AuthorizationDecision decision = this.authorizationManager.check(this.authentication, mi);
		// 发布授权事件
		this.eventPublisher.publishAuthorizationEvent(this.authentication, mi, decision);
		// 不通过就抛出访问拒绝异常
		if (decision != null && !decision.isGranted()) {
			throw new AccessDeniedException("Access Denied");
		}
	}

从源码，我们可以发现之前分析的三类注解，只需要一个MethodInterceptor。而他们的不同之处则由AuthorizationManager这个同一个的接口进行统一调度。
对应地：

注解	AuthorizationManager
@PreAuthorize	PreAuthorizeAuthorizationManager
@Secured	SecuredAuthorizationManager
jsr250的注解	Jsr250AuthorizationManager

• SecuredAuthorizationManager：

public final class SecuredAuthorizationManager implements AuthorizationManager<MethodInvocation> {
	// 这是个最为简单的AuthorizationManager实现，无非就是将当前用户的权限与所需要的权限进行比较，如果找到就认为拥有访问权限。
	private AuthorizationManager<Collection<String>> authoritiesAuthorizationManager = new AuthoritiesAuthorizationManager();
	// 缓存已经解析过的方法所对应的权限
	private final Map<MethodClassKey, Set<String>> cachedAuthorities = new ConcurrentHashMap<>();

	@Override
	public AuthorizationDecision check(Supplier<Authentication> authentication, MethodInvocation mi) {
		// 获取目标方法配置的访问权限
		Set<String> authorities = getAuthorities(mi);
		// 比较权限，从authoritiesAuthorizationManager.check方法的入参也能大概猜到怎么实现
		return authorities.isEmpty() ? null : this.authoritiesAuthorizationManager.check(authentication, authorities);
	}

	private Set<String> getAuthorities(MethodInvocation methodInvocation) {
		Method method = methodInvocation.getMethod();
		Object target = methodInvocation.getThis();
		Class<?> targetClass = (target != null) ? target.getClass() : null;
		MethodClassKey cacheKey = new MethodClassKey(method, targetClass);
		// 如果尚未存在相关缓存，则进行解析。
		// 由此可见，只有当目标方法被第一次执行/调用的时候才会出发解析动作
		return this.cachedAuthorities.computeIfAbsent(cacheKey, (k) -> resolveAuthorities(method, targetClass));
	}

	private Set<String> resolveAuthorities(Method method, Class<?> targetClass) {
		Method specificMethod = AopUtils.getMostSpecificMethod(method, targetClass);
		// 尝试在方法上寻找目标注解@Secured
		Secured secured = findSecuredAnnotation(specificMethod);
		// 返回@Secured注解所配置的权限
		return (secured != null) ? Set.of(secured.value()) : Collections.emptySet();
	}
}

• Jsr250AuthorizationManager
  相较于SecuredAuthorizationManager，他负责的则是3个注解，而不是一个。

public final class Jsr250AuthorizationManager implements AuthorizationManager<MethodInvocation> {
	// 这是AuthorizationManager的注册器
	// 因为要处理三个注解，每个注解的处理逻辑虽然简单，但是确实不一样。
	// 而每个方法存在的注解也不一样
	private final Jsr250AuthorizationManagerRegistry registry = new Jsr250AuthorizationManagerRegistry();

	@Override
	public AuthorizationDecision check(Supplier<Authentication> authentication, MethodInvocation methodInvocation) {
		// 根据方法，从注册器中获取对应的AuthorizationManager
		AuthorizationManager<MethodInvocation> delegate = this.registry.getManager(methodInvocation);
		// 执行授权校验逻辑
		return delegate.check(authentication, methodInvocation);
	}

	// 这是Jsr250AuthorizationManager的内部类
	private final class Jsr250AuthorizationManagerRegistry extends AbstractAuthorizationManagerRegistry {
		@NonNull
		@Override
		AuthorizationManager<MethodInvocation> resolveManager(Method method, Class<?> targetClass) {
			// 解析注解
			Annotation annotation = findJsr250Annotation(method, targetClass);
			if (annotation instanceof DenyAll) {
				// 返回一个lambda表达式构建的AuthorizationManager，其实现为：直接返回拒绝访问
				return (a, o) -> new AuthorizationDecision(false);
			}
			if (annotation instanceof PermitAll) {
				// 返回一个lambda表达式构建的AuthorizationManager，其实现为：直接返回允许访问
				return (a, o) -> new AuthorizationDecision(true);
			}
			if (annotation instanceof RolesAllowed) {
				RolesAllowed rolesAllowed = (RolesAllowed) annotation;
				// 返回与@Secured一样的AuthorityAuthorizationManager
				return AuthorityAuthorizationManager.hasAnyRole(Jsr250AuthorizationManager.this.rolePrefix,
						rolesAllowed.value());
			}
			// 这里应当看到，这三个注解的判断顺序。事实上，在解析注解的时候，只会返回其中之一。
			// 而jsr250的注解也是不能同时使用的，只能用其中一个。
			return NULL_MANAGER;
		}
	}
}

abstract class AbstractAuthorizationManagerRegistry {
	private final Map<MethodClassKey, AuthorizationManager<MethodInvocation>> cachedManagers = new ConcurrentHashMap<>();

	final AuthorizationManager<MethodInvocation> getManager(MethodInvocation methodInvocation) {
		Method method = methodInvocation.getMethod();
		Object target = methodInvocation.getThis();
		Class<?> targetClass = (target != null) ? target.getClass() : null;
		MethodClassKey cacheKey = new MethodClassKey(method, targetClass);
		// 这里就跟@Secured类似了，只不过其需要兼顾3个注解，因此value变成了AuthorizationManager
		return this.cachedManagers.computeIfAbsent(cacheKey, (k) -> resolveManager(method, targetClass));
	}	
	
	abstract AuthorizationManager<MethodInvocation> resolveManager(Method method, Class<?> targetClass);
}

• PreAuthorizeAuthorizationManager
  与他的同伴不同，他可是要支持SPEL的。

public final class PreAuthorizeAuthorizationManager implements AuthorizationManager<MethodInvocation> {
	private PreAuthorizeExpressionAttributeRegistry registry = new PreAuthorizeExpressionAttributeRegistry();

	@Override
	public AuthorizationDecision check(Supplier<Authentication> authentication, MethodInvocation mi) {
		// 通过方法，从注册器获取ExpressionAttribute。
		ExpressionAttribute attribute = this.registry.getAttribute(mi);
		if (attribute == ExpressionAttribute.NULL_ATTRIBUTE) {
			return null;
		}
		// 通过注册器找到ExpressionHandler，并创建EvaluationContext
		EvaluationContext ctx = this.registry.getExpressionHandler().createEvaluationContext(authentication, mi);
		// 执行SPEL表达式
		boolean granted = ExpressionUtils.evaluateAsBoolean(attribute.getExpression(), ctx);
		// 返回决策：是否允许访问
		return new ExpressionAuthorizationDecision(granted, attribute.getExpression());
	}
}

这里我们看到了为了支持SPEL的第一个抽象：ExpressionAttribute。他最重要的使命就是记录表达式。
再来看看，最为重要的：PreAuthorizeExpressionAttributeRegistry

final class PreAuthorizeExpressionAttributeRegistry extends AbstractExpressionAttributeRegistry<ExpressionAttribute> {
	private final MethodSecurityExpressionHandler expressionHandler;

	@Override
	ExpressionAttribute resolveAttribute(Method method, Class<?> targetClass) {
		Method specificMethod = AopUtils.getMostSpecificMethod(method, targetClass);
		// 寻找@PreAuthorize注解
		PreAuthorize preAuthorize = findPreAuthorizeAnnotation(specificMethod);
		if (preAuthorize == null) {
			return ExpressionAttribute.NULL_ATTRIBUTE;
		}
		// 解析表达式
		Expression preAuthorizeExpression = this.expressionHandler.getExpressionParser()
			.parseExpression(preAuthorize.value());
		// 返回解析到的表达式
		return new ExpressionAttribute(preAuthorizeExpression);
	}
}

abstract class AbstractExpressionAttributeRegistry<T extends ExpressionAttribute> {
	// 缓存方法对应的表达式
	private final Map<MethodClassKey, T> cachedAttributes = new ConcurrentHashMap<>();

	final T getAttribute(Method method, Class<?> targetClass) {
		MethodClassKey cacheKey = new MethodClassKey(method, targetClass);
		// 解析并缓存表达式
		return this.cachedAttributes.computeIfAbsent(cacheKey, (k) -> resolveAttribute(method, targetClass));
	}
}

AuthorizationManagerAfterMethodInterceptor

他与前面介绍的MethodInterceptor相呼应，一前一后，你从名字就能发现。只不过与前者相比，目前他只有一个注解需要关注@PostAuthorize。

public final class AuthorizationManagerAfterMethodInterceptor
		implements Ordered, MethodInterceptor, PointcutAdvisor, AopInfrastructureBean {

	private final AuthorizationManager<MethodInvocationResult> authorizationManager;
	
	@Override
	public Object invoke(MethodInvocation mi) throws Throwable {
		// 先执行
		Object result = mi.proceed();
		// 再校验。这里应当注意到他的入参包括方法返回值
		attemptAuthorization(mi, result);
		return result;
	}
	
	private void attemptAuthorization(MethodInvocation mi, Object result) {
		// 熟悉的配方，只不过入参变成了方法返回值罢了
		MethodInvocationResult object = new MethodInvocationResult(mi, result);
		AuthorizationDecision decision = this.authorizationManager.check(this.authentication, object);

		this.eventPublisher.publishAuthorizationEvent(this.authentication, object, decision);
		if (decision != null && !decision.isGranted()) {
			throw new AccessDeniedException("Access Denied");
		}
	}
}

public final class PostAuthorizeAuthorizationManager implements AuthorizationManager<MethodInvocationResult> {

	private PostAuthorizeExpressionAttributeRegistry registry = new PostAuthorizeExpressionAttributeRegistry();
	
	@Override
	public AuthorizationDecision check(Supplier<Authentication> authentication, MethodInvocationResult mi) {
		ExpressionAttribute attribute = this.registry.getAttribute(mi.getMethodInvocation());
		if (attribute == ExpressionAttribute.NULL_ATTRIBUTE) {
			return null;
		}

		MethodSecurityExpressionHandler expressionHandler = this.registry.getExpressionHandler();
		EvaluationContext ctx = expressionHandler.createEvaluationContext(authentication, mi.getMethodInvocation());
		expressionHandler.setReturnObject(mi.getResult(), ctx);

		boolean granted = ExpressionUtils.evaluateAsBoolean(attribute.getExpression(), ctx);
		return new ExpressionAuthorizationDecision(granted, attribute.getExpression());
	}
}

经过了前面的分析，这里也就没啥多说的了。与@PreAuthorize很相似。

PreFilterAuthorizationMethodInterceptor

负责处理@PreFilter注解的方法调用。

public final class PreFilterAuthorizationMethodInterceptor
		implements Ordered, MethodInterceptor, PointcutAdvisor, AopInfrastructureBean {

	public PreFilterAuthorizationMethodInterceptor() {
		// 默认处理的是@PreFilter
		this.pointcut = AuthorizationMethodPointcuts.forAnnotations(PreFilter.class);
	}
	// ...

	@Override
	public Object invoke(MethodInvocation mi) throws Throwable {
		// 从属性注册器中获取到目标方法解析好的@PreFilter的相关属性信息。
		PreFilterExpressionAttributeRegistry.PreFilterExpressionAttribute attribute = this.registry.getAttribute(mi);
		if (attribute == PreFilterExpressionAttributeRegistry.PreFilterExpressionAttribute.NULL_ATTRIBUTE) {
			return mi.proceed();
		}
		// 从属性注册器中获取对应的SPEL的表达式处理器，以便创建SPEL的上下文
		MethodSecurityExpressionHandler expressionHandler = this.registry.getExpressionHandler();
		EvaluationContext ctx = expressionHandler.createEvaluationContext(this.authentication, mi);
		// 从表达式上下文中获取需要过滤的目标
		Object filterTarget = findFilterTarget(attribute.getFilterTarget(), ctx, mi);
		// 根据SPEL表达式执行过滤
		expressionHandler.filter(filterTarget, attribute.getExpression(), ctx);
		// 执行目标方法
		return mi.proceed();
	}

	// ...
}

可以看出，与@PreAuthorize类似，只是少了一层AuthorizationManager的封装。原因也很简单，AuthorizationManager是用来鉴权的，而@PreFilter不需要鉴权。
只需要过滤参数即可。因此他也不会抛出访问异常。

PostFilterAuthorizationMethodInterceptor

负责处理@PostFilter。

public final class PostFilterAuthorizationMethodInterceptor
		implements Ordered, MethodInterceptor, PointcutAdvisor, AopInfrastructureBean {
	// 这个注册器与PreAuthorizeExpressionAttributeRegistry类似，都继承同一个父类。
	// 只有解析的注解不一样，对应ExpressionAttribute稍稍不一样，前者记录有方法参数，而后者记录有方法返回值。
	private PostFilterExpressionAttributeRegistry registry = new PostFilterExpressionAttributeRegistry();

	public PostFilterAuthorizationMethodInterceptor() {
		this.pointcut = AuthorizationMethodPointcuts.forAnnotations(PostFilter.class);
	}
	
	@Override
	public Object invoke(MethodInvocation mi) throws Throwable {
		// 先执行了方法，获得返回值
		Object returnedObject = mi.proceed();
		ExpressionAttribute attribute = this.registry.getAttribute(mi);
		if (attribute == ExpressionAttribute.NULL_ATTRIBUTE) {
			return returnedObject;
		}
		// 获取ExpressionHandler，创建EvaluationContext
		MethodSecurityExpressionHandler expressionHandler = this.registry.getExpressionHandler();
		EvaluationContext ctx = expressionHandler.createEvaluationContext(this.authentication, mi);
		// 执行过滤逻辑
		return expressionHandler.filter(returnedObject, attribute.getExpression(), ctx);
	}

我们可以看到@PostFilter，只是对返回进行过滤，同样也不会抛出访问异常。

小结

分析完源码之后，我们不难发现，每一个类都很小，且每一个方法都足够简单。这点是值得大家学习的。
当然，不能盲目。因为作为一款优秀的框架，必须要具备良好的可扩展性。通过分析和抽象，能够很好起到这个作用。这是框架源码设计者所追求的。
但是其弊端也很明显，那就是一个完整的功能实现，往往需要诸多组件协作完成，初学者很难入门。因此，在实际业务开发过程中，不能盲目地追求这种扩展性。
同时，面对复杂业务时，不妨多分析，是否可以像框架源码的设计者那样思考？当然，设计完成后，需要留下相当的文档。

总结

各方法注解的应用场景

注解	应用场景	实现原理
@Secured	配置需要满足的权限，可以是角色名或者权限	基于AuthorityAuthorizationManager
JSR-250的@PermitAll	任何人都可以访问	基于lambda表达式实现的简单的AuthorizationManager
JSR-250的@DenyAll	任何人都不能访问	基于lambda表达式实现的简单的AuthorizationManager
JSR-250的@RolesAllowed	配置需要满足的权限，可以是角色名或者权限。可以于@Secured相互取代。	基于AuthorityAuthorizationManager，可以于@Secured相互取代。
@PreAuthorize	用于在方法调用之前鉴权，支持方法入参作为表达式的一部分	基于SPEL表达式
@PostAuthorize	用于在方法调用之后鉴权，支持方法返回值作为表达式的一部分	基于SPEL表达式
@PreFilter	用于过滤方法入参	基于SPEL表达式
@PostFilter	用于过滤方法返回值	基于SPEL表达式

在搞清楚了各注解的用处和使用后，我们在回过头来看，我们可以使用哪些授权方式：

1. RBAC(基于角色的访问控制)
   这个除了@PreFilter@PostFilter，其他注解都能实现。SPEL可以使用hasAnyRole("ADMIN","USER")

后记

至此，我们应该算全方面聊完了基于方法注解怎么配置权限这个话题。不管各个注解的使用场景，亦或者其实现原理，还是各种设计思路。
下一节，我们将聊聊基于HttpRequest的权限配置方式。这个直接使用倒是简单，但是想要定制就必须深入理解其设计和原理。加油。

参照

Method Security

Spring Security的@PreAythorize、@PostAuthorize、@PreFilter 和@PostFilter