spring-security-demo/method-security/docs/02-spel-reference.md

← 01 · how it runs · chapter index · next: self-invocation →

02 · The SpEL reference

Run: java -cp target/classes:$(cat cp.txt) com.ankurm.methodsec.Demo4SpelReference Output: output/demo4.txt, output/demo9-with-parameters.txt, output/demo9-without-parameters.txt Source: Demo4SpelReference.java, Demo9ParameterNames.java

Every row below is a real annotated method on a real proxied bean in Demo4, invoked as two different users. Nothing here is transcribed from documentation.

Predicates

Expression	Meaning
hasRole('ADMIN')	authority ROLE_ADMIN (prefix configurable)
hasAnyRole('A','B')	any of them
hasAllRoles('A','B')	all of them
hasAuthority('report:read')	the authority string, verbatim, no prefix
hasAnyAuthority(..) / hasAllAuthorities(..)	as above
isAuthenticated()	authenticated and not anonymous
isFullyAuthenticated()	authenticated, not anonymous, not remember-me
isRememberMe() / isAnonymous()	the two it excludes
permitAll / denyAll	constants; also callable as permitAll() / denyAll()
hasPermission(target, permission)	delegates to a PermissionEvaluator bean
hasPermission(id, 'type', permission)	the id/type overload

hasAllRoles and hasAllAuthorities are easy to miss — they are on SecurityExpressionRoot alongside the any variants.

The root object

MethodSecurityExpressionRoot (package-private, extends SecurityExpressionRoot<MethodInvocation>) exposes exactly:

Reference	Available in	What it is
authentication	everywhere	the Authentication
principal	everywhere	authentication.getPrincipal()
returnObject	@PostAuthorize, @PostFilter	the value the method returned
filterObject	@PreFilter, @PostFilter	the element currently being tested
#root.this	everywhere	the target object
read, write, create, delete, admin	everywhere	String constants for hasPermission(..)

There is no positional access to arguments. #root.args[0] fails with

EL1008E: Property or field 'args' cannot be found on object of type
'org.springframework.security.access.expression.method.MethodSecurityExpressionRoot'

Arguments are bound by name, which brings us to the flag.

#parameterName needs -parameters

@PreAuthorize("#owner == authentication.name") resolves #owner through a ParameterNameDiscoverer. Java only keeps parameter names in the class file when javac is given -parameters. Without it the name is arg0, #owner resolves to nothing, and the comparison is false.

The same class, same expression, two compilations — demo9-with-parameters.txt versus demo9-without-parameters.txt:

compiled with -parameters : true          compiled with -parameters : false
byParameterName param[0]  : owner         byParameterName param[0]  : arg0
alice → #owner == name    : ALLOWED       alice → #owner == name    : DENIED

It fails closed, which is the good direction, but it fails silently — the rule being enforced is not the rule you wrote. Spring Boot's Maven and Gradle plugins set -parameters for you; a hand-rolled build, a shaded jar, or a module compiled by a different toolchain may not. @P("alias") from org.springframework.security.core.parameters does not depend on the flag, because the name lives in the annotation.

Beans and types

@beanName.method(...) resolves a bean from the context, which is the cleanest way to move a non-trivial rule out of a string literal and into testable code:

@PreAuthorize("@accountPolicy.canRead(authentication, #id)")
public Account read(long id) { ... }

T(java.time.LocalDate).now().year >= 2020 works too. It is legal, and it is a warning sign: an expression that needs a type reference is an expression that wants to be a bean method.

Role prefix and hierarchy, in 7.1

Both moved. AbstractSecurityExpressionHandler.setRoleHierarchy(..) is deprecated in Spring Security 7.1 — the compiler says so, which is how this module found out. The current knob is an AuthorizationManagerFactory:

@Bean
static AuthorizationManagerFactory<MethodInvocation> authorizationManagerFactory() {
    DefaultAuthorizationManagerFactory<MethodInvocation> factory = new DefaultAuthorizationManagerFactory<>();
    factory.setRoleHierarchy(RoleHierarchyImpl.withDefaultRolePrefix()
        .role("ADMIN").implies("USER")
        .role("USER").implies("GUEST")
        .build());
    factory.setRolePrefix("ROLE_");
    return factory;
}

PrePostMethodSecurityConfiguration autowires both an AuthorizationManagerFactory and a bare RoleHierarchy bean (@Autowired(required = false) on each), so a plain RoleHierarchy bean still works. The factory is where the prefix and the hierarchy now live together, and it is the one that is not deprecated.

Verified in output/demo4.txt: with the hierarchy above, root holding only ROLE_ADMIN passes hasRole('GUEST').

← 01 · how it runs · chapter index · next: self-invocation →