We Keep Coding

Lazy initialise spring security at runtime + reload spring security configuration

Spring usually eagerly loading the spring security configuration while starting the application. I'm using OAuth with Spring Security
I'm maintaining a configuration table for storing the SSO related values (like jwk-url, client_id, client_secret). This values will be populated by an admin user via CRUD in the same spring boot application.
Then only the jwk-url is available to be configure in the Spring security configuration (refer below code - jwkSetUri(...)). This would not available at the application startup.
So I wanted to initialise the spring security configuration after the value is loaded into the table, like a lazy loading (#Lazy) at runtime. I know how to do Lazy loading of a regular class/service.
But still I'm not sure how to invoke the configure(HttpSecurity http) method at runtime and how to p
ass the HttpSecurity parameter. When I just try invoke new ResourceServerConfiguration() like a lazy loading at runtime, I don't see the configure() method is called. (Or) this class needs to be maintained as bean and lazy load whenever needed. But still not sure about how to call configure() in code.
Another thing is how to refresh/reload the spring security configuration at runtime, if the JWK url is changed by admin. Then only the spring security configuration can take effect of the changes.
#Configuration
#EnableWebSecurity
public class ResourceServerConfiguration extends WebSecurityConfigurerAdapter {
#Override
public void configure(HttpSecurity http) throws Exception {
http.cors()
.and()
.csrf().disable()
.sessionManagement()
.sessionCreationPolicy(SessionCreationPolicy.STATELESS).and()
.authorizeRequests()
.anyRequest().authenticated()
.and()
.oauth2ResourceServer()
.authenticationEntryPoint(oAuth2AuthenticationEntryPoint)
.accessDeniedHandler(oAuth2AccessDeniedHandler)
.jwt()
// Some Auth server URL which would be fetch from table
.jwkSetUri(ssoConfigService.getActiveSSOCertificateURL());
// Eg. http://localhost:8090/auth/realms/demo-app/protocol/openid-connect/certs
}
}
I have already referred these links. But it doesn't help for my purpose. Any help would be appreciated.
How do I lazy load Spring Security?
How to reload the Configure method of WebSecurityConfigurerAdapter when the application is up and running
Modify Spring Security Config at Runtime
Configure Spring HTTP Security at Runtime

Please, check this link Customizing CORS Filtering at Runtime that include a similar use case related to your but for him, he needed to change allowed origins dynamically. They decide to create a new filter and simple extends OncePerRequestFilter.
Take in account to check the OAuth2ResourceServerProperties for your use case.
UPDATING:
Try with this code for this scenario:
Another thing is how to refresh/reload the spring security configuration at runtime, if the JWK url is changed by admin. Then only the spring security configuration can take effect of the changes.
#Override
public void configure(HttpSecurity http) throws Exception {
http.cors()
.and()
.csrf().disable()
.sessionManagement()
.sessionCreationPolicy(SessionCreationPolicy.STATELESS).and()
.authorizeRequests()
.anyRequest().authenticated()
// TODO: test with and without this and check if work for you
.and()
.oauth2ResourceServer()
.authenticationEntryPoint(oAuth2AuthenticationEntryPoint)
.accessDeniedHandler(oAuth2AccessDeniedHandler)
.jwt()
// Some Auth server URL which would be fetch from table
.jwkSetUri(ssoConfigService.getActiveSSOCertificateURL());
// Eg. http://localhost:8090/auth/realms/demo-app/protocol/openid-connect/certs
http.addFilterBefore(new OncePerRequestFilter() {
// Every time a request occur, this method will be called.
#Override
protected void doFilterInternal(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, FilterChain filterChain) throws ServletException, IOException {
try {
http.oauth2ResourceServer()
.authenticationEntryPoint(oAuth2AuthenticationEntryPoint)
.accessDeniedHandler(oAuth2AccessDeniedHandler)
.jwt()
// Some Auth server URL which would be fetch from table
.jwkSetUri(ssoConfigService.getActiveSSOCertificateURL());
} catch (Exception e) {
e.printStackTrace();
}
}
}, BasicAuthenticationFilter.class);
}
I hope this info can help you.

Ordering custom filters in Spring Security configuration

I have created two custom filters, one responsible for validating JWT and one for handling ExpiredJwtException.
I have found solution to invoke them in the right order there: Multiple Spring Security filters, so that the ExpiredJwtException is properly caught:
http.antMatcher("jwtRequestFilter/exceptionHandlerFilter/**")
.addFilterBefore(exceptionHandlerFilter, FilterSecurityInterceptor.class)
.antMatcher("jwtRequestFilter/**")
.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class);
After some refactoring it turned out that all I need to make it work is:
http.antMatcher("jwtRequestFilter/**")
.addFilterBefore(exceptionHandlerFilter, FilterSecurityInterceptor.class)
.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class);
But I don't get how does the antMatcher method work here. Either antMatcher("jwtRequestFilter/exceptionHandlerFilter/**") or antMatcher("jwtRequestFilter/**") is needed to remain correct order.
How does expressions in antMatcher work? Does ** means other filters in the chain and jwtRequestFilter on the beginning of the expression means it is last filter?

The antMatcher method will match the path of incoming requests, it is not related to the names of the filters.
From the Javadoc for antMatcher:
Allows configuring the HttpSecurity to only be invoked when matching the provided ant pattern.
This means that your custom filters (and the rest of the filter chain) will only be invoked if the incoming request matches the ant pattern that you have provided.
Consider this example
http
.antMatcher("/admin/**")
.addFilterBefore(customFilter, UsernamePasswordAuthenticationFilter.class)
// ...
If you make a request to GET "/admin/home", then HttpSecurity will be invoked the request will be processed by customFilter.
If you make a request to GET "/user/home", then HttpSecurity will not be invoked the request won't be processed by customFilter.
To understand how ant-style path matching works, see the Javadoc for AntPathMatcher.

You need HttpSecurity configs per endpoint.
#Configuration
#Order(1)
public class JwtExceptionHandleConfig extends WebSecurityConfigurerAdapter {
#Override
protected void configure(final HttpSecurity http) throws Exception {
final Filter exceptionHandlerFilter = new ExceptionHandlerFilter();
http.antMatcher("/jwtRequestFilter/exceptionHandlerFilter/**")
.addFilterBefore(exceptionHandlerFilter, FilterSecurityInterceptor.class);
}
}
#Configuration
#Order(2)
public class JwtRequestConfig extends WebSecurityConfigurerAdapter {
#Override
protected void configure(final HttpSecurity http) throws Exception {
final Filter jwtRequestFilter = new JwtRequestFilter();
final Filter exceptionHandlerFilter = new ExceptionHandlerFilter();
http.antMatcher("/jwtRequestFilter/**")
.addFilterBefore(jwtRequestFilter, UsernamePasswordAuthenticationFilter.class)
.addFilterBefore(exceptionHandlerFilter, FilterSecurityInterceptor.class);
}
}
See also:
Java configuration for Multiple HttpSecurity

Spring Security ignore path filter still executed when Authorization header present

I have a fully working spring security process set up with some paths requiring authentication (via a token) and others I want to keep open and accessible without token. The issue I am running into is that when a request comes in to one of those open paths without the Authorization header, then the filters are ignored and the proper response is generated. However, when the Authorization header is present, even though on the ignored path, the request goes through the entire security filter chain when the ideal procedure would be to entirely skip the filter chain.
Below is my configuration.
#Override
public void configure(WebSecurity web) throws Exception {
web.ignoring()
.antMatchers(DEFAULT_IGNORE_REQUESTS);
}
#Override
protected void configure(HttpSecurity http) throws Exception {
authenticationTokenHeaderFilter.setAuthenticationManager(authenticationManager);
http.authorizeRequests()
.antMatchers("/example/**")
.authenticated()
.and()
.exceptionHandling()
.accessDeniedHandler((request, response, accessDeniedException) -> {
response.sendError(HttpServletResponse.SC_FORBIDDEN, accessDeniedException.getMessage());
})
.authenticationEntryPoint(new HttpAuthenticationEntryPoint())
.and()
.sessionManagement()
.sessionCreationPolicy(SessionCreationPolicy.STATELESS)
.and()
.cors()
.and()
.csrf().disable()
.addFilter(authenticationTokenHeaderFilter)
.addFilterBefore(new ExceptionTranslationFilter(
new Http403ForbiddenEntryPoint()),
authenticationTokenHeaderFilter.getClass()
);
}
public class AuthenticationTokenHeaderFilter extends AbstractPreAuthenticatedProcessingFilter {
#Override
protected Object getPreAuthenticatedPrincipal(HttpServletRequest httpServletRequest) {
return httpServletRequest.getHeader(HttpHeaders.AUTHORIZATION);
}
#Override
protected Object getPreAuthenticatedCredentials(HttpServletRequest httpServletRequest) {
return "N/A";
}
#Override
#Autowired
public void setAuthenticationManager(AuthenticationManager authenticationManager) {
super.setAuthenticationManager(authenticationManager);
}
}
I have additionally tried putting the ignored paths to the HttpSecurity with permitAll() with no success.
Clarification
String[] DEFAULT_IGNORE_REQUESTS = new String[]{ "/actuator" };
In what is described above, any requests going to /example/** should go through the security chain and through my filter to make sure the user is authenticated. Any requests going to /actuator should not go through the security filter chain. The /example/** works correctly and as expected. The /actuator however does not.
When I make a request without the Authorization header, the security chain is not invoked.
When I make a request with the Authorization header present, the security chain is invoked and the Authorization value (token) is verified. In the event that the token is invalid, a custom exception gets thrown inside the filter. Even though the error gets thrown, I get the expected response from /actuator with a 200. The thrown error in this case however gets logged and a stack trace gets generated, which I do not want as it's not an error in that case.

In Spring Boot, any #Bean of type Filter gets added as a servlet filter. What's most likely happening is that your filter is being added as a filter entirely separate from the filter chain.
Instead of declaring your filter as a #Bean, you could initialize AuthenticationTokenHeaderFilter in your WebSecurityConfigurerAdapter and set the AuthenticationManager directly (which you already do anyways). So you can remove the #Autowired annotation in the filter.

Correct use of WebSecurity in WebSecurityConfigurerAdapter

In my Spring Boot application based on version 1.3.0.BUILD-SNAPSHOT, I have the static resources (images, css, js) in the static folder under resources.
I see some examples related to security configuration like the following:
#Configuration
#EnableWebSecurity
public class WebSecurityConfig extends WebSecurityConfigurerAdapter {
#Override
public void configure(final WebSecurity web) throws Exception {
web.ignoring()
.antMatchers("/static/**");
}
}
Is that example correct?
What should be the effect?
How to verify that it works (e.g. doing a request to localhost:8080/something?
What cool things can I do with WebSecurity?

Your example means that Spring (Web) Security is ignoring URL patterns that match the expression you have defined ("/static/**"). This URL is skipped by Spring Security, therefore not secured.
Allows adding RequestMatcher instances that should that Spring Security should ignore. Web Security provided by Spring Security (including the SecurityContext) will not be available on HttpServletRequest that match. Typically the requests that are registered should be that of only static resources. For requests that are dynamic, consider mapping the request to allow all users instead.
See WebSecurity API documentation for more info.
You can have as many URL patterns secured or unsecured as you want.
With Spring Security you have authentication and access control features for the web layer of an application. You can also restrict users who have a specified role to access a particular URL and so on.
Read the Spring Security reference for more details:
http://docs.spring.io/spring-security/site/docs/current/reference/html/
Ordering Priority of URL Patterns
When matching the specified patterns against an incoming request, the matching is done in the order in which the elements are declared. So the most specific matches patterns should come first and the most general should come last.
There are multiple children to the http.authorizeRequests() method
each matcher is considered in the order they were declared.
Patterns are always evaluated in the order they are defined. Thus it is important that more specific patterns are defined higher in the list than less specific patterns.
Read here for more details:
http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#filter-security-interceptor
Example 1
General use of WebSecurity ignoring() method omits Spring Security and none of Spring Security’s features will be available.
WebSecurity is based above HttpSecurity
(in an XML configuration you can write this: <http pattern="/resources/**" security="none"/>).
#Override
public void configure(WebSecurity web) throws Exception {
web
.ignoring()
.antMatchers("/resources/**")
.antMatchers("/publics/**");
}
#Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/publics/**").hasRole("USER") // no effect
.anyRequest().authenticated();
}
WebSecurity in the above example lets Spring ignore /resources/** and /publics/**. Therefore the .antMatchers("/publics/**").hasRole("USER") in HttpSecurity is unconsidered.
This will omit the request pattern from the security filter chain entirely.
Note that anything matching this path will then have no authentication or authorization services applied and will be freely accessible.
Example 2
Patterns are always evaluated in order. The below matching is invalid because the first matches every request and will never apply the second match:
#Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/**").hasRole("USER")
.antMatchers("/admin/**").hasRole("ADMIN"):
}

Well in the code you shared, if you had your static files i.e. CSS/JS etc in a folder called static then all your static resources will be added to the page whereas if you left out
web.ignoring()
.antMatchers("/static/**");
none of your static resources will be loaded.
Spring Security is extremely powerful, Spring has great documentation so you should just go read about it fully appreciate/understand it.
Here is a
link

Spring Security 3.1.3 request querystring stripped

I am securing my application using Spring Security 3.1.3 and I have a requirement to allow users to login via a link in a third-party application.
However, the link in the third-party application will redirect to a specific resource and not to the login page, where the resource that the user wishes
to access will be defined as a querystring parameter. So, for example, the link would be of the form :
//server.com/app/build/panel.jsp?resourceid='blah'
When a user clicks this link they should be taken to the login page defined in my Spring Security configuration and if authenticated then should be redirected
to the original link including the querystring parameter. The querystring parameter has no influence on how the user should be authenticated it's
merely an id of resource.
Now, this all works fine apart from the querystring, which gets stripped by Spring Security before it enters the request processing flow.
This is shown in the debug output from Spring Security;
org.springframework.security.web.savedrequest.HttpSessionRequestCache: DefaultSavedRequest added to Session:
DefaultSavedRequest[http://server.com:8080/app/build/panel.jsp]
ie, the querystring is not saved and resourceid='blah' has been removed.
Note, I'm currently using Ant matching. I have no need to actually match against the querystring.
In earlier versions of Spring Security, it seemed like you could influence this behaviour by using a BeanPostProcessor as per this post,
Spring Security - Url with request parameters rules ignored. But the method
DefaultFilterInvocationSecurityMetadataSource.setStripQueryStringFromUrls() has been removed from Spring Security 3.1.3.
How do I configure Spring Security to not strip the querystring from the original request? So that when the user is redirected after the login to
the original URL the querystring parameter will be retained?
Many Thanks
Howard

U can get it from SuccessHandler
SecurityConfiguration class
#Configuration
#EnableWebSecurity
public class SecurityConfiguration extends WebSecurityConfigurerAdapter {
#Autowired
SuccessHandler getSuccessHandler;
#Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.antMatchers("/dashboard/**",
"/feedback/**"
).access("hasRole('ROLE_SYSTEM_ADMIN') or hasRole('ROLE_COMPANY_ADMIN')")
.and().formLogin().loginPage("/login").successHandler(getSuccessHandler)
.loginProcessingUrl("/login").usernameParameter("ssoId").passwordParameter("password")
.and().csrf()
.and().exceptionHandling().accessDeniedPage("/Access_Denied")
.and()
.sessionManagement().invalidSessionUrl("/login").maximumSessions(1).expiredUrl("/login").and().sessionAuthenticationErrorUrl("/login").sessionFixation().migrateSession()
.sessionCreationPolicy(SessionCreationPolicy.ALWAYS); //always, IF_REQUIRED,never ,stateless
http.logout()
.logoutUrl("/logout")
.logoutSuccessUrl("/login")
.invalidateHttpSession(true)
.permitAll();
}
#Override
public void configure(WebSecurity web) throws Exception {
web
.ignoring()
.antMatchers("/static/**")
.antMatchers("/images/**");
}
}
SuccessHandler class
#Component
public class SuccessHandler implements AuthenticationSuccessHandler {
#Override
public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,
Authentication authentication) throws IOException, ServletException {
HttpSession session = request.getSession();
response.sendRedirect(request.getContextPath() + "/dashboard/index");
}
}

Is basically the success handler.
You can take a look at this example:
#Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/login*")
.permitAll()
.anyRequest()
.authenticated()
.and()
.formLogin()
.successHandler(new RefererAuthenticationSuccessHandler());
}
More info about it : http://www.baeldung.com/spring-security-redirect-login

For others on a similar issue, refer the link:
https://docs.spring.io/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
Extract:There is a danger that when an application is deployed in a container which does not strip path parameters from these values, an attacker could add them to the requested URL in order to cause a pattern match to succeed or fail unexpectedly.
However this stripping is meant to firmly protect the pattern matching for login. It doesnt means the query parameters are not available from the HTTP request, they should be.