I have Spring Boot (1.2.1.RELEASE) application that serves OAuth2 (2.0.6.RELEASE) authorization and resource server in one application inst
Here is the solution to the problem. Take a look at this exemplary Groovy class:
@Configuration
@EnableResourceServer
class ResourceServer extends ResourceServerConfigurerAdapter {
@Value('${oauth.resourceId}')
private String resourceId
@Override
public void configure(HttpSecurity http) throws Exception {
http.csrf().disable()
http.httpBasic().disable()
http.requestMatchers().antMatchers('/admin/**', '/uaa/**')
.and().authorizeRequests()
.antMatchers('/uaa/authenticated/**').authenticated()
.antMatchers('/uaa/register/**').permitAll()
.antMatchers('/uaa/activate/**').permitAll()
.antMatchers('/uaa/password/**').permitAll()
.antMatchers('/uaa/auth/**').permitAll()
.antMatchers('/uaa/account/**').hasAuthority('ADMIN')
.antMatchers('/admin/**').hasAuthority('ADMIN')
.anyRequest().authenticated()
http.sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
}
@Override
public void configure(ResourceServerSecurityConfigurer resources) throws Exception {
resources.resourceId(resourceId);
}
}
Basically, to run OAuth2.0 authentication parallel with web form authentication, you have to put
http.requestMatchers().antMatchers('/path/1/**', '/path/2/**')
to configuration class. My previous configuration missed this important part so only OAuth2.0 took a part in authentication process.
what if you use different endpoints configured with different security?
For the above example, everything with /uaa/** secured with WebSecurityConfigurerAdapter, and /api-docs/** with ResourceServerConfigurerAdapter.
In that case, will filter chains still conflict?
I don't think you should be trying to set up form login or http basic in your ResourceServerConfigurerAdapter, and certainly not if you already have them in your other WebSecurityConfigurerAdapter (you do because they are on by default). It might work, but the authentication and access decisions are so different for an OAuth2 protected resource and a UI that I recommend you keep them separate (as they are in all the samples in github). If you go with the recommendation and continue with the components you already defined, the key to getting this right is to know that the filter chains are tried sequentially and the first one to match wins, so only one of them is going to act on any given request. You have to put request matchers in both chains (or at least the one with the lowest order), and make sure they don't overlap.