官术网_书友最值得收藏!

Authentication

One of the fundamental ways to secure a resource is to make sure that the caller is who they claim to be. This process of checking credentials and making sure that they are genuine is called authentication.

The following diagram shows the fundamental process Spring Security uses to address this core security requirement. The figure is generic and can be used to explain all the various authentication methods that the framework supports:

Figure 02: Authentication architecture

As detailed in Chapter 1Overview of Spring 5 and Spring Security 5 (in the Working of Spring Security section), Spring Security has a series of servlet filters (a filter chain). When a request reaches the server, it is intercepted by this series of filters (Step 1 in the preceding diagram).

In the reactive world (with the new Spring WebFlux web application framework), filters are written quite differently than traditional filters (such as those used in the Spring MVC web application framework). Having said that, the fundamental mechanism remains the same for both. We have a dedicated chapter explaining how to convert a Spring Security application to Spring MVC and Spring WebFlux where we will cover these aspects in a bit more detail.

The Servlet filter code execution in the filter chain keeps skipping until the right filter is reached. Once it reaches the right authentication filter based on the authentication mechanism used, it extracts the supplied credentials (most commonly a username and password) from the caller. Using the supplied values (here, we have a username and password), the filter (UsernamePasswordAuthenticationFilter) creates an Authentication object (in the preceding diagram, UsernamePasswordAuthenticationToken is created using the username and password supplied in Step 2). The Authentication object created in Step 2 is then used to call the authenticate method in theAuthenticationManager interface:

public interface AuthenticationManager {
Authentication authenticate(Authentication authentication)
throws AuthenticationException;
}

The actual implementation is provided by ProviderManager, which has a list of configured AuthenticationProvider.

public interface AuthenticationProvider {
Authentication authenticate(Authentication authentication)
throws AuthenticationException;
boolean supports(Class<?> authentication);
}

The request passes through various providers and, in due course, tries to authenticate the request. There are a number of AuthenticationProvider as part of Spring Security.

In the diagram at the start of the chapter, AuthenticationProvider requires user details (some providers require this, but some don't), which are provided in UserDetailsService:

public interface UserDetailsService {
UserDetails loadUserByUsername(String username) throws
UsernameNotFoundException;
}

UserDetailsService retrieves UserDetails (and implements the User interface) using the supplied username.

If all goes well, Spring Security creates a fully populated Authentication object (authenticate: true, granted authority list and username), which will contain various necessary details. The Authentication object is stored in the SecurityContext object by the filter for future use.

The authenticate method in AuthenticationManager can return the following:

  • An Authentication object with authenticated=true, if Spring Security can validate the supplied user credentials
  • An AuthenticationException, if Spring Security finds that the supplied user credentials are invalid
  • null, if Spring Security cannot decide whether it is true or false (confused state)
主站蜘蛛池模板: 辉南县| 苍溪县| 宜宾县| 吕梁市| 新晃| 道真| 洛隆县| 临颍县| 永泰县| 泾川县| 连南| 普兰店市| 巴马| 赣榆县| 拜泉县| 枣强县| 汝州市| 竹山县| 沁阳市| 湖口县| 马鞍山市| 曲麻莱县| 福清市| 淳安县| 金沙县| 万源市| 银川市| 梓潼县| 龙陵县| 南部县| 曲松县| 昆明市| 台南市| 巴彦淖尔市| 贺兰县| 绵阳市| 十堰市| 惠水县| 浠水县| 枞阳县| 清水县|