The authentication and authorization starts with extending the class WebSecurityConfigurerAdapter. This class provides AppSecurityConfig the inherited methods that are important in establishing the users, channels, and request endpoints for the authentication and authorization rules.

First, it has HttpSecurity that applies web-based security rules for specific HTTP or HTTPS requests. It has a built-in antMatchers() that will scrutinize which URL requests will be covered by the authentication rules and which will not. This method can also determine which HTTP methods are allowed to be authenticated or not. In the meantime, HttpSecurity only allows /login.html, /login.html?error=true and /after_logout.html to be executed without user authentication.

Moreover, the API has http.formLogin().loginPage(), which determines what view page will be the entry point for authentication. Likewise, it also has the methods http.formLogin().logoutUrl() and http.formLogin().logoutSuccessUrl() to register views related to logout processing. In XML-based context definitions, this API class is equivalent to the <http> element in Spring Security's namespace configuration.

Second, the configuration has the WebSecurity class that has the ignoring() method that will identify which URL request will not be subject to security rules at the general level. Restrictions through this class are often applied to static resources such as JavaScript, CSS, and image paths.

Lastly, it provides AuthenticationManagerBuilder, which has methods such as inMemoryAuthentication(), used in creating usernames, passwords, and roles. The inMemoryAuthentication() is the most basic and internal way of setting up user details. When it comes creating roles, it has the method roles() which asks for the role name without the prefix "ROLE_". It is authorities() that has the expression format "ROLE_XXX".

After completing the security model AppSecurityConfig, we apply this to our SpringContextConfig, not only to execute all the rules, but to create eventually the springSecurityFilterChain, which is considered the core API repository of the Spring Security architecture. In order for springSecurityFilterChain to be functional at runtime, the delegatingFilterProxy filter class must be registered in ServletContext by implementing AbstractSecurityWebApplicationInitializer. The filter rolls out all the security rules imposed by AppSecurityConfig. In this recipe, using Filter.Registration to add the filter to ServletContext gives us an exception:

SEVERE [localhost-startStop-1] org.apache.catalina.core.StandardContext.filterStart Exception starting filter delegatingFilterProxy 
 org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'delegatingFilterProxy' available 

Once AppSecurityConfig is loaded, it imposes one entry point to the application through the URL /login.html. This security model will just redirect the user from an authentication error to the URL request /login.html?error=true. It requires the user to log out properly to protect the application through /logout.html.

This recipe hasn't covered CSRF yet, use http.csrf().disable() for now. CSRF will be discussed in a later recipe. At this point, Spring Security 4.2.2 has been set up over Spring 5.0 MVC.