Einführung in die Spring Method Security

1. Einleitung

Einfach ausgedrückt unterstützt Spring Security die Autorisierungssemantik auf Methodenebene.

In der Regel können wir unsere Serviceschicht sichern, indem wir beispielsweise einschränken, welche Rollen eine bestimmte Methode ausführen können, und sie mithilfe der speziellen Unterstützung für Sicherheitstests auf Methodenebene testen.

In diesem Artikel werden wir zunächst die Verwendung einiger Sicherheitsanmerkungen überprüfen. Dann konzentrieren wir uns darauf, unsere Methodensicherheit mit verschiedenen Strategien zu testen.

2. Aktivieren der Methodensicherheit

Um Spring Method Security verwenden zu können, müssen Sie zunächst die Abhängigkeit spring-security-config hinzufügen :

 org.springframework.security spring-security-config 

Wir können die neueste Version auf Maven Central finden.

Wenn wir Spring Boot verwenden möchten, können wir die Spring-Boot-Starter-Sicherheitsabhängigkeit verwenden, die Spring-Security-Config enthält :

 org.springframework.boot spring-boot-starter-security 

Auch hier ist die neueste Version auf Maven Central zu finden.

Als nächstes müssen wir die globale Methodensicherheit aktivieren:

@Configuration @EnableGlobalMethodSecurity( prePostEnabled = true, securedEnabled = true, jsr250Enabled = true) public class MethodSecurityConfig extends GlobalMethodSecurityConfiguration { }
  • Die Eigenschaft prePostEnabled aktiviert Spring Security-Annotationen vor / nach dem Annotieren
  • Die Eigenschaft secureEnabled bestimmt, ob die Annotation @Secured aktiviert werden soll
  • Mit der Eigenschaft jsr250Enabled können wir die Annotation @RoleAllowed verwenden

Wir werden im nächsten Abschnitt mehr über diese Anmerkungen erfahren.

3. Anwenden der Methodensicherheit

3.1. Verwenden von @Secured Annotation

Die Annotation @Secured wird verwendet, um eine Liste der Rollen in einer Methode anzugeben. Daher kann ein Benutzer nur dann auf diese Methode zugreifen, wenn er mindestens eine der angegebenen Rollen hat.

Definieren wir eine getUsername- Methode:

@Secured("ROLE_VIEWER") public String getUsername() { SecurityContext securityContext = SecurityContextHolder.getContext(); return securityContext.getAuthentication().getName(); }

Hier definiert die Annotation @Secured („ROLE_VIEWER“), dass nur Benutzer mit der Rolle ROLE_VIEWER die Methode getUsername ausführen können .

Außerdem können wir eine Liste von Rollen in einer @ Secured- Annotation definieren:

@Secured({ "ROLE_VIEWER", "ROLE_EDITOR" }) public boolean isValidUsername(String username) { return userRoleRepository.isValidUsername(username); }

In diesem Fall gibt die Konfiguration an, dass ein Benutzer, der über ROLE_VIEWER oder ROLE_EDITOR verfügt, die Methode isValidUsername aufrufen kann.

Die Annotation @Secured unterstützt keine Spring Expression Language (SpEL).

3.2. Verwenden von @RoleAllowed Annotation

Die @RoleAllowed Anmerkung ist die JSR-250 Äquivalent Anmerkung der @Secured Anmerkung .

Grundsätzlich können wir die Annotation @RoleAllowed auf ähnliche Weise wie @Secured verwenden . Daher könnten wir die Methoden getUsername und isValidUsername neu definieren :

@RolesAllowed("ROLE_VIEWER") public String getUsername2() { //... } @RolesAllowed({ "ROLE_VIEWER", "ROLE_EDITOR" }) public boolean isValidUsername2(String username) { //... }

In ähnlicher Weise nur der Benutzer, die Rolle ROLE_VIEWER ausführen kann getUsername2 .

Wiederum kann ein Benutzer isValidUsername2 nur aufrufen, wenn er mindestens eine der Rollen ROLE_VIEWER oder ROLER_EDITOR hat .

3.3. Verwenden von @ PreAuthorize- und @ PostAuthorize- Anmerkungen

Sowohl @ PreAuthorize- als auch @ PostAuthorize- Annotationen bieten eine ausdrucksbasierte Zugriffssteuerung. Daher können Prädikate mit SpEL (Spring Expression Language) geschrieben werden.

Die Annotation @PreAuthorize überprüft den angegebenen Ausdruck vor der Eingabe der Methode , während die Annotation @PostAuthorize ihn nach der Ausführung der Methode überprüft und das Ergebnis ändern kann .

Deklarieren wir nun eine getUsernameInUpperCase- Methode wie folgt :

@PreAuthorize("hasRole('ROLE_VIEWER')") public String getUsernameInUpperCase() { return getUsername().toUpperCase(); }

Das @PreAuthorize ("hasRole ('ROLE_VIEWER')") hat dieselbe Bedeutung wie @Secured ("ROLE_VIEWER"), das wir im vorherigen Abschnitt verwendet haben. Weitere Informationen zu Sicherheitsausdrücken finden Sie in früheren Artikeln.

Folglich kann die Anmerkung @Secured ({"ROLE_VIEWER", "ROLE_EDITOR"}) durch @PreAuthorize ("hasRole" ("ROLE_VIEWER") oder hasRole ("ROLE_EDITOR") ersetzt werden.

@PreAuthorize("hasRole('ROLE_VIEWER') or hasRole('ROLE_EDITOR')") public boolean isValidUsername3(String username) { //... }

Darüber hinaus können wir das Methodenargument tatsächlich als Teil des Ausdrucks verwenden :

@PreAuthorize("#username == authentication.principal.username") public String getMyRoles(String username) { //... }

Hier kann ein Benutzer die Methode getMyRoles nur aufrufen , wenn der Wert des Arguments Benutzername mit dem Benutzernamen des aktuellen Principals übereinstimmt.

Es ist zu beachten, dass @ PreAuthorize- Ausdrücke durch @ PostAuthorize- Ausdrücke ersetzt werden können .

Lassen Sie uns getMyRoles umschreiben :

@PostAuthorize("#username == authentication.principal.username") public String getMyRoles2(String username) { //... }

Im vorherigen Beispiel würde sich die Autorisierung jedoch nach der Ausführung der Zielmethode verzögern.

Darüber hinaus bietet die Annotation @PostAuthorize die Möglichkeit, auf das Methodenergebnis zuzugreifen :

@PostAuthorize ("returnObject.username == authentication.principal.nickName") public CustomUser loadUserDetail(String username) { return userRoleRepository.loadUserByUserName(username); }

In this example, the loadUserDetail method would only execute successfully if the username of the returned CustomUser is equal to the current authentication principal's nickname.

In this section, we mostly use simple Spring expressions. For more complex scenarios, we could create custom security expressions.

3.4. Using @PreFilter and @PostFilter Annotations

Spring Security provides the @PreFilter annotation to filter a collection argument before executing the method:

@PreFilter("filterObject != authentication.principal.username") public String joinUsernames(List usernames) { return usernames.stream().collect(Collectors.joining(";")); }

In this example, we're joining all usernames except for the one who is authenticated.

Here, in our expression, we use the name filterObject to represent the current object in the collection.

However, if the method has more than one argument which is a collection type, we need to use the filterTarget property to specify which argument we want to filter:

@PreFilter (value = "filterObject != authentication.principal.username", filterTarget = "usernames") public String joinUsernamesAndRoles( List usernames, List roles) { return usernames.stream().collect(Collectors.joining(";")) + ":" + roles.stream().collect(Collectors.joining(";")); }

Additionally, we can also filter the returned collection of a method by using @PostFilter annotation:

@PostFilter("filterObject != authentication.principal.username") public List getAllUsernamesExceptCurrent() { return userRoleRepository.getAllUsernames(); }

In this case, the name filterObject refers to the current object in the returned collection.

With that configuration, Spring Security will iterate through the returned list and remove any value matching the principal's username.

Spring Security – @PreFilter and @PostFilter article describes both annotations in greater detail.

3.5. Method Security Meta-Annotation

We typically find ourselves in a situation where we protect different methods using the same security configuration.

In this case, we can define a security meta-annotation:

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) @PreAuthorize("hasRole('VIEWER')") public @interface IsViewer { }

Next, we can directly use the @IsViewer annotation to secure our method:

@IsViewer public String getUsername4() { //... }

Security meta-annotations are a great idea because they add more semantics and decouple our business logic from the security framework.

3.6. Security Annotation at the Class Level

If we find ourselves using the same security annotation for every method within one class, we can consider putting that annotation at class level:

@Service @PreAuthorize("hasRole('ROLE_ADMIN')") public class SystemService { public String getSystemYear(){ //... } public String getSystemDate(){ //... } }

In above example, the security rule hasRole(‘ROLE_ADMIN') will be applied to both getSystemYear and getSystemDate methods.

3.7. Multiple Security Annotations on a Method

We can also use multiple security annotations on one method:

@PreAuthorize("#username == authentication.principal.username") @PostAuthorize("returnObject.username == authentication.principal.nickName") public CustomUser securedLoadUserDetail(String username) { return userRoleRepository.loadUserByUserName(username); }

Hence, Spring will verify authorization both before and after the execution of the securedLoadUserDetail method.

4. Important Considerations

There are two points we'd like to remind regarding method security:

  • By default, Spring AOP proxying is used to apply method security – if a secured method A is called by another method within the same class, security in A is ignored altogether. This means method A will execute without any security checking. The same applies to private methods
  • Spring SecurityContext is thread-bound – by default, the security context isn't propagated to child-threads. For more information, we can refer to Spring Security Context Propagation article

5. Testing Method Security

5.1. Configuration

To test Spring Security with JUnit, we need the spring-security-test dependency:

 org.springframework.security spring-security-test 

We don't need to specify the dependency version because we're using the Spring Boot plugin. We can find the latest version of this dependency on Maven Central.

Next, let's configure a simple Spring Integration test by specifying the runner and the ApplicationContext configuration:

@RunWith(SpringRunner.class) @ContextConfiguration public class MethodSecurityIntegrationTest { // ... }

5.2. Testing Username and Roles

Now that our configuration is ready, let's try to test our getUsername method which we secured with the @Secured(“ROLE_VIEWER”) annotation:

@Secured("ROLE_VIEWER") public String getUsername() { SecurityContext securityContext = SecurityContextHolder.getContext(); return securityContext.getAuthentication().getName(); }

Since we use the @Secured annotation here, it requires a user to be authenticated to invoke the method. Otherwise, we'll get an AuthenticationCredentialsNotFoundException.

Hence, we need to provide a user to test our secured method. To achieve this, we decorate the test method with @WithMockUser and provide a user and roles:

@Test @WithMockUser(username = "john", roles = { "VIEWER" }) public void givenRoleViewer_whenCallGetUsername_thenReturnUsername() { String userName = userRoleService.getUsername(); assertEquals("john", userName); }

We've provided an authenticated user whose username is john and whose role is ROLE_VIEWER. If we don't specify the username or role, the default username is user and default role is ROLE_USER.

Note that it isn't necessary to add the ROLE_ prefix here, Spring Security will add that prefix automatically.

If we don't want to have that prefix, we can consider using authority instead of role.

For example, let's declare a getUsernameInLowerCase method:

@PreAuthorize("hasAuthority('SYS_ADMIN')") public String getUsernameLC(){ return getUsername().toLowerCase(); }

We could test that using authorities:

@Test @WithMockUser(username = "JOHN", authorities = { "SYS_ADMIN" }) public void givenAuthoritySysAdmin_whenCallGetUsernameLC_thenReturnUsername() { String username = userRoleService.getUsernameInLowerCase(); assertEquals("john", username); }

Conveniently, if we want to use the same user for many test cases, we can declare the @WithMockUser annotation at test class:

@RunWith(SpringRunner.class) @ContextConfiguration @WithMockUser(username = "john", roles = { "VIEWER" }) public class MockUserAtClassLevelIntegrationTest { //... }

If we wanted to run our test as an anonymous user, we could use the @WithAnonymousUser annotation:

@Test(expected = AccessDeniedException.class) @WithAnonymousUser public void givenAnomynousUser_whenCallGetUsername_thenAccessDenied() { userRoleService.getUsername(); }

In the example above, we expect an AccessDeniedException because the anonymous user isn't granted the role ROLE_VIEWER or the authority SYS_ADMIN.

5.3. Testing With a Custom UserDetailsService

For most applications, it's common to use a custom class as authentication principal. In this case, the custom class needs to implement the org.springframework.security.core.userdetails.UserDetails interface.

In this article, we declare a CustomUser class which extends the existing implementation of UserDetails, which is org.springframework.security.core.userdetails.User:

public class CustomUser extends User { private String nickName; // getter and setter }

Let's take back the example with the @PostAuthorize annotation in section 3:

@PostAuthorize("returnObject.username == authentication.principal.nickName") public CustomUser loadUserDetail(String username) { return userRoleRepository.loadUserByUserName(username); }

In this case, the method would only execute successfully if the username of the returned CustomUser is equal to the current authentication principal's nickname.

If we wanted to test that method, we could provide an implementation of UserDetailsService which could load our CustomUser based on the username:

@Test @WithUserDetails( value = "john", userDetailsServiceBeanName = "userDetailService") public void whenJohn_callLoadUserDetail_thenOK() { CustomUser user = userService.loadUserDetail("jane"); assertEquals("jane", user.getNickName()); }

Here, the @WithUserDetails annotation states that we'll use a UserDetailsService to initialize our authenticated user. The service is referred by the userDetailsServiceBeanName property. This UserDetailsService might be a real implementation or a fake for testing purposes.

Additionally, the service will use the value of the property value as the username to load UserDetails.

Conveniently, we can also decorate with a @WithUserDetails annotation at the class level, similarly to what we did with the @WithMockUser annotation.

5.4. Testing With Meta Annotations

We often find ourselves reusing the same user/roles over and over again in various tests.

For these situations, it's convenient to create a meta-annotation.

Taking back the previous example @WithMockUser(username=”john”, roles={“VIEWER”}), we can declare a meta-annotation as:

@Retention(RetentionPolicy.RUNTIME) @WithMockUser(value = "john", roles = "VIEWER") public @interface WithMockJohnViewer { }

Then we can simply use @WithMockJohnViewer in our test:

@Test @WithMockJohnViewer public void givenMockedJohnViewer_whenCallGetUsername_thenReturnUsername() { String userName = userRoleService.getUsername(); assertEquals("john", userName); }

Likewise, we can use meta-annotations to create domain-specific users using @WithUserDetails.

6. Conclusion

In this tutorial, we've explored various options for using Method Security in Spring Security.

We also have gone through a few techniques to easily test method security and learned how to reuse mocked users in different tests.

All examples of this tutorial can be found over on Github.