本篇文章为你整理了Java Configuration :: Spring Security（）的详细内容，包含有 Java Configuration :: Spring Security，希望能帮助你了解 Java Configuration :: Spring Security。
Java ConfigurationGeneral support for Java configuration was added to Spring Framework in Spring 3.1.
Spring Security 3.2 introduced Java configuration to let users configure Spring Security without the use of any XML.
If you are familiar with the Security Namespace Configuration, you should find quite a few similarities between it and Spring Security Java configuration.
Spring Security provides lots of sample applications to demonstrate the use of Spring Security Java Configuration.
The first step is to create our Spring Security Java Configuration.
The configuration creates a Servlet Filter known as the springSecurityFilterChain, which is responsible for all the security (protecting the application URLs, validating submitted username and passwords, redirecting to the log in form, and so on) within your application.
The following example shows the most basic example of a Spring Security Java Configuration:
import org.springframework.context.annotation.*;
import org.springframework.security.config.annotation.authentication.builders.*;
import org.springframework.security.config.annotation.web.configuration.*;
@Configuration
@EnableWebSecurity
public class WebSecurityConfig {
@Bean
public UserDetailsService userDetailsService() {
InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
manager.createUser(User.withDefaultPasswordEncoder().username("user").password("password").roles("USER").build());
return manager;
}
Let the user with a Username of user and a Password of password authenticate with form based authentication
Cache Control (which you can override later in your application to allow caching of your static resources)
AbstractSecurityWebApplicationInitializer
The next step is to register the springSecurityFilterChain with the WAR file.
You can do so in Java configuration with Spring s WebApplicationInitializer support in a Servlet 3.0+ environment.
Not surprisingly, Spring Security provides a base class (AbstractSecurityWebApplicationInitializer) to ensure that the springSecurityFilterChain gets registered for you.
The way in which we use AbstractSecurityWebApplicationInitializer differs depending on if we are already using Spring or if Spring Security is the only Spring component in our application.
AbstractSecurityWebApplicationInitializer without Existing Spring
If you are not using Spring or Spring MVC, you need to pass the WebSecurityConfig to the superclass to ensure the configuration is picked up:
public class SecurityWebApplicationInitializer
extends AbstractSecurityWebApplicationInitializer {
public SecurityWebApplicationInitializer() {
super(WebSecurityConfig.class);
}
Automatically registers the springSecurityFilterChain Filter for every URL in your application.
AbstractSecurityWebApplicationInitializer with Spring MVC
If we use Spring elsewhere in our application, we probably already have a WebApplicationInitializer that is loading our Spring Configuration.
If we use the previous configuration, we would get an error.
Instead, we should register Spring Security with the existing ApplicationContext.
For example, if we use Spring MVC, our SecurityWebApplicationInitializer could look something like the following:
public class SecurityWebApplicationInitializer
extends AbstractSecurityWebApplicationInitializer {
}
This onlys register the springSecurityFilterChain for every URL in your application.
After that, we need to ensure that WebSecurityConfig was loaded in our existing ApplicationInitializer.
For example, if we use Spring MVC it is added in the getRootConfigClasses():
public class MvcWebApplicationInitializer extends
AbstractAnnotationConfigDispatcherServletInitializer {
@Override
protected Class ? [] getRootConfigClasses() {
return new Class[] { WebSecurityConfig.class };
// ... other overrides ...
}
Thus far, our WebSecurityConfig contains only information about how to authenticate our users.
How does Spring Security know that we want to require all users to be authenticated?
How does Spring Security know we want to support form-based authentication?
Actually, there is a configuration class (called SecurityFilterChain) that is being invoked behind the scenes.
It is configured with the following default implementation:
Ensures that any request to our application requires the user to be authenticated
We can configure multiple HttpSecurity instances just as we can have multiple http blocks in XML.
The key is to register multiple SecurityFilterChain @Beans.
The following example has a different configuration for URL s that start with /api/.
public UserDetailsService userDetailsService() throws Exception {
// ensure the passwords are encoded properly
UserBuilder users = User.withDefaultPasswordEncoder();
InMemoryUserDetailsManager manager = new InMemoryUserDetailsManager();
manager.createUser(users.username("user").password("password").roles("USER").build());
manager.createUser(users.username("admin").password("password").roles("USER","ADMIN").build());
return manager;
@Bean
@Order(1) (2)
public SecurityFilterChain apiFilterChain(HttpSecurity http) throws Exception {
http
.securityMatcher("/api/**") (3)
.authorizeHttpRequests(authorize - authorize
.anyRequest().hasRole("ADMIN")
.httpBasic(withDefaults());
return http.build();
@Bean (4)
public SecurityFilterChain formLoginFilterChain(HttpSecurity http) throws Exception {
http
.authorizeHttpRequests(authorize - authorize
.anyRequest().authenticated()
.formLogin(withDefaults());
return http.build();
}
Create an instance of SecurityFilterChain that contains @Order to specify which SecurityFilterChain should be considered first.
The http.securityMatcher states that this HttpSecurity is applicable only to URLs that start with /api/.
Create another instance of SecurityFilterChain.
If the URL does not start with /api/, this configuration is used.
This configuration is considered after apiFilterChain, since it has an @Order value after 1 (no @Order defaults to last).
public class MyCustomDsl extends AbstractHttpConfigurer MyCustomDsl, HttpSecurity {
private boolean flag;
@Override
public void init(HttpSecurity http) throws Exception {
// any method that adds another configurer
// must be done in the init method
http.csrf().disable();
@Override
public void configure(HttpSecurity http) throws Exception {
ApplicationContext context = http.getSharedObject(ApplicationContext.class);
// here we lookup from the ApplicationContext. You can also just create a new instance.
MyFilter myFilter = context.getBean(MyFilter.class);
myFilter.setFlag(flag);
http.addFilterBefore(myFilter, UsernamePasswordAuthenticationFilter.class);
public MyCustomDsl flag(boolean value) {
this.flag = value;
return this;
public static MyCustomDsl customDsl() {
return new MyCustomDsl();
}
This is actually how methods like HttpSecurity.authorizeRequests() are implemented.
If you want, you can have HttpSecurity add MyCustomDsl by default by using SpringFactories.
For example, you can create a resource on the classpath named META-INF/spring.factories with the following contents:
org.springframework.security.config.annotation.web.configurers.AbstractHttpConfigurer = sample.MyCustomDsl
Spring Security s Java configuration does not expose every property of every object that it configures.
This simplifies the configuration for a majority of users.
After all, if every property were exposed, users could use standard bean configuration.
While there are good reasons to not directly expose every property, users may still need more advanced configuration options.
To address this issue, Spring Security introduces the concept of an ObjectPostProcessor, which can be used to modify or replace many of the Object instances created by the Java Configuration.
For example, to configure the filterSecurityPublishAuthorizationSuccess property on FilterSecurityInterceptor, you can use the following:
.anyRequest().authenticated()
.withObjectPostProcessor(new ObjectPostProcessor FilterSecurityInterceptor () {
public O extends FilterSecurityInterceptor O postProcess(
O fsi) {
fsi.setPublishAuthorizationSuccess(true);
return fsi;
return http.build();
}
以上就是Java Configuration :: Spring Security（）的详细内容，想要了解更多 Java Configuration :: Spring Security的内容，请持续关注盛行IT软件开发工作室。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。