I am using spring boot and spring security for web applications. I wanted to apply for no filter on my public API. Now what I am doing is the equality check on the path which is sent by the client and the path which I have hard code if it is equal then I am not applying the filter.
Code sample
protected boolean shouldNotFilter(HttpServletRequest request) throws ServletException {
return request.getRequestURI().equals("api/v1/public/hello"));
}
But this approach is not a good way to do. As in, there can be multiple public endpoints and I can't put an equal check on each of them. I need a solution where I can have all my public endpoints in one place and when the request comes I simply have to check in that one place if it is present then no filter will be applied.
Assuming you are talking about the Spring Security Filters and you may want to expose some APIs publicly.
You may use configure(WebSecurity web) or configure(HttpSecurity http) method to achieve the goal. To prevent the filters to be applied you may use configure(WebSecurity web) method. 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.
#Override
public void configure(WebSecurity web) throws Exception {
web
.ignoring()
.antMatchers("api/v1/public/**");
}
use antMatcher to exclude your public domain.
http.cors().and().csrf().disable().authorizeRequests()
.antMatchers("api/v1/public/**", "/health").permitAll()
.anyRequest()..authenticated();
Usually, closing your app for all and opening for the desired endpoint is the best security practice.
Related
Is it possible to have two API Keys on Swagger and give them different privileges in my API?
For example:
API_KEY_1 : Has access to one Post method
API_KEY_2 : Has access to all of my API
Many thanks
In terms of Spring Security, that all depends on how you authenticate the API keys in your application. Once you've set up the application to validate an API key and create a SecurityContext, your best bet would be to map to one of two different roles, one for limited access, and one for all access. For example:
#Configuration
public static class SecurityConfiguration extends WebSecurityConfigurerAdapter {
#Override
protected void configure(HttpSecurity http) throws Exception {
http
// ...
.authorizeRequests()
.mvcMatchers(HttpMethod.POST, "/some/api").hasAnyRole("BASIC", "ADMIN")
.anyRequest().hasRole("ADMIN");
}
}
More information and examples of authorization can be found in the docs.
Does anybody know if there any way to configure Spring Security in the way that it doesn't change session id if there is some parameter in the request.
For example:
somesite.com/home.jsp?password=encrypted- change session id after
authentication
somesite.com/home.jsp?password=encrypted& keepsessionid - don't
change session id after authentication
I was thinking about filter chain, maybe removing conditionally SessionManagementFilter, but not sure if this is a proper way, and even if this will be working
For someone with the same question. I found the answer. Different session management strategy can be achieved by using multiple http security configuration (inner classes of main security classes). The special case http security configurer should be adjusted to some special request
#Configuration
#Order(1)
public class SpecialCaseSessionHandlingConfig extends WebSecurityConfigurerAdapter {
#Override
protected void configure(HttpSecurity http) throws Exception {
http.requestMatcher(request -> Check1(request))
.authorizeRequests()
.anyRequest().authenticated();
}
}
I'm trying to get a Spring application to allow some requests to public (without login) and some requests to private (with login).
At this point I'd like to just get the public part to work properly.
I have tried most of the example configurations listed on the Spring Security documentation, including all sorts of combinations of anonymous(), and permitAll(). All end up redirecting to the login page.
protected void configure(HttpSecurity http) throws Exception{
http.authorizeRequests()
.antMatchers("/resources/**", "/signup", "/about","/api/home").permitAll()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")
.anyRequest().authenticated()
.and()
// ...
.formLogin();
}
Expected result: items under permitAll() are accessible without logging in
Actual result:
redirect to login page. This shows up in the log: 2019-06-06
17:29:43.593 INFO 56330 --- [ main]
o.s.s.web.DefaultSecurityFilterChain : Creating filter chain: any
request, [org.sprin...
This leads me to believe that it isn't even reading this configuration. Is there any way to fix this?
Thanks!
UPDATE: I tried adding the websecurity ignores, and it doesn't appear to be working still. It appears to still print the "defaultsecuritychain" error so I feel like this may have something to do with it.
UPDATE 2: Added application.properties file under src/main/resources with this line logging.level.org.springframework.security=DEBUG to make it log debug messages.
pastebin.com/2u9k7eHD
Have a look at http://blog.florian-hopf.de/2017/08/spring-security.html, it may explain your use-case in more detail.
My recommendation is to try and use WebSecurity for static and public resources
public void configure(WebSecurity web) throws Exception {
web.ignoring().antMatchers("/resources/**", "/signup", "/about","/api/home");
}
You can achieve your requirements with below configurations. It's a good way to use the URLs which does't require Authentication/Authorization to be placed in WebSecurity using ignoring instead of HttpSecurity as WebScurity will bypass the Spring Security Filter Chain and reduce the execution time
#Override
public void configure(WebSecurity web) throws Exception {
web
.ignoring()
.antMatchers("/resources/**", "/signup", "/about","/api/home");
}
#Override
protected void configure(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/admin/**").hasRole("ADMIN")
.antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")
.anyRequest().authenticated()
.yourConfigurations
}
When you use HttpSecurity and try to permitAll() requests. Your requests will be allowed to be accessed from the Spring Security Filter Chain. This is costly as there will be requests other requests which would also come into this filter chain which needs to be allowed or disallowed based on Authentication/Authorization
But when you use WebSecurity, any requests to "/resources/**", "/signup", "/about","/api/home" will completely by pass the Spring Security Filter Chain all together. It is safe because you don't need any Authentication/Authorization to be in place to see an image or read a javascript file.
Turns out that I was missing the #SpringBootApplication annotation all along in one of my source files. Make sure that's in there and perhaps it will work.
Thank you to all who replied!
I'm working on Server application build in spring-boot based on micro service architecture which is already having Spring Security to handle form based authentication. Now the requirement is that each of the incoming Restful requests will have a country code and area code. I need to validate if the codes passed in path variable are same as local codes or not.
I am not able to figure out how and where to trigger or hook on to Spring Security to add the filter so that each of the requests is validated before it comes to rest controller and in case the codes are not valid, the filter itself sends 400 status code as the response.
I thought there should be something in Spring Security that can be extended or customized to do this?
You need to create your custom filter by extending the GenericFilterBean override the doFilter method.
Then in your custom implementation of WebSecurityConfigurerAdapter add the above custom filter in HttpSecurity.
#Configuration
public class CustomWebSecurityConfigurerAdapter
extends WebSecurityConfigurerAdapter {
#Override
protected void configure(HttpSecurity http) throws Exception {
http.addFilterAfter(
new MyCountryCodeFilter(), BasicAuthenticationFilter.class);
}
}
I don't know what I'm doing wrong, but when I try to secure some REST resources using a ResourceServerConfigurerAdapter it doesn't work. I can only accomplish my goal using #PreAuthorize or setting the security on the WebSecurityConfigurerAdapter.
Actually, the WebSecurityConfigurerAdapter is stealing all possibilities on HttpSecurity settings. I believe that it have something to do with filtering order. I searched for information on the documentation but found it quite vague. I know that on the Spring Boot version 1.5+ the filtering order of ResourceServerConfigurerAdapter has been changed, and I only managed to get it to work after setting a new order on the properties: security.oauth2.resource.filter-order=3
Being more specific, this code (on ResourceServerConfigurerAdapter) doesn't have any result:
#Override
public void configure(HttpSecurity http) throws Exception {
http.requestMatcher(new OAuthRequestedMatcher())
.anonymous().disable()
.authorizeRequests()
.antMatchers(HttpMethod.OPTIONS).permitAll()
.antMatchers("/api/hello").access("hasAnyRole('USER')")
.antMatchers("/api/me").hasAnyRole("USER", "ADMIN");
}
It is only possible to protect "/api/hello" and "/api/me" annotating #PreAuthorize on the controller methods:
#PreAuthorize("hasAnyRole('USER','ADMIN')")
#GetMapping("/api/hello")
public ResponseEntity<?> hello() {
String name = SecurityContextHolder.getContext().getAuthentication().getName();
String msg = String.format("Hello %s", name);
return new ResponseEntity<Object>(msg, HttpStatus.OK);
}
It is working, however, I fear that it could be done in a better way. Any ideas?
After some digging, I found the solution. The problem is indeed related to the filtering order. The guys at Pivotal changed the Oauth2 Resource Filter Order, as you can see in this passage taken from Spring Boot 1.5 release note:
OAuth 2 Resource Filter
The default order of the OAuth2 resource filter has changed from 3 to
SecurityProperties.ACCESS_OVERRIDE_ORDER - 1. This places it after the
actuator endpoints but before the basic authentication filter chain.
The default can be restored by setting
security.oauth2.resource.filter-order = 3
However, as pointed by #ilovkatie on this thread, the order of the WebSecurityConfigurerAdapter was also changed to 100, taken precedence over ResourceServerConfigurerAdapter.
So, instead of changing ResourceServerConfigurerAdapter's order on properties, a more elegant solution would be to use #Order(SecurityProperties.ACCESS_OVERRIDE_ORDER) on WebSecurityConfigurerAdapter.
This will make the resources configuration take precedence over WebSecurityConfigurerAdapter and it will be possible to set security using HttpSecurity on the ResourceServerConfigurerAdapter, making unnecessary to use #PreAuthorize annotation.