This tutorial shows how to Secure a REST Service using Spring and Spring Security 3.1<\/strong> with Java based configuration. The article will focus on how to set up the Security Configuration specifically for the REST API using a Login and Cookie approach.<\/p>\n The architecture of Spring Security is based entirely on Servlet Filters and, as such, comes before Spring MVC in regards to the processing of HTTP requests. Keeping this in mind, to begin with, a filter<\/strong> needs to be declared in the web.xml<\/em> of the application:<\/p>\n The filter must necessarily be named \u2018springSecurityFilterChain\u2019<\/em>\u00a0 to match the default bean created by Spring Security in the container.<\/p>\n Note that the defined filter is not the actual class implementing the security logic but a DelegatingFilterProxy<\/em> with the purpose of delegating the Filter\u2019s methods to an internal bean. This is done so that the target bean can still benefit from the Spring context lifecycle and flexibility.<\/p>\n The URL pattern used to configure the Filter is \/*<\/em><\/strong> even though the entire web service is mapped to \/api\/*<\/em><\/strong> so that the security configuration has the option to secure other possible mappings as well, if required.<\/p>\n Most of the configuration is done using the security namespace<\/strong> \u2013 for this to be enabled, the schema locations must be defined and pointed to the correct 3.1 XSD versions. The namespace is designed so that it expresses the common uses of Spring Security while still providing hooks raw beans to accommodate more advanced scenarios.<\/p>\n The <http><\/em> element is the main container element for HTTP security configuration. In the current implementation, it only secured a single mapping: \/api\/admin\/**<\/em>. Note that the mapping is relative to the root context<\/strong> of the web application, not to the rest<\/em> Servlet; this is because the entire security configuration lives in the root Spring context and not in the child context of the Servlet. In a standard web application, the authentication process may be automatically triggered when the client tries to access a secured resource without being authenticated \u2013 this is usually done by redirecting to a login page so that the user can enter credentials. However, for a REST Web Service <\/strong>this behavior doesn\u2019t make much sense \u2013 Authentication should only be done by a request to the correct URI and all other requests should simply fail with a 401 UNAUTHORIZED<\/strong> status code if the user is not authenticated.<\/p>\n Spring Security handles this automatic triggering of the authentication process with the concept of an Entry Point<\/strong> \u2013 this is a required part of the configuration, and can be injected via the entry-point-ref<\/em> attribute of the <http><\/em> element. Keeping in mind that this functionality doesn\u2019t make sense in the context of the REST Service, the new custom entry point is defined to simply return 401 whenever it is triggered:<\/p>\n There are multiple ways to do Authentication for a REST API \u2013 one of the default Spring Security provides is Form Login<\/strong> \u2013 which uses an authentication processing filter \u2013 org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter<\/em>.<\/p>\n The <form-login><\/em> element will create this filter and will also allow us to set our custom authentication success handler on it. This can also be done manually by using the <custom-filter><\/em> element to register a filter at the position FORM_LOGIN_FILTER<\/em> \u2013 but the namespace support is flexible enough.<\/p>\n Note that for a standard web application, the auto-config <\/em><\/strong>attribute of the <http> element <\/em>is shorthand syntax for some useful security configuration. While this may be appropriate for some very simple configurations, it doesn\u2019t fit and should not be used for a REST API.<\/p>\n By default, form login will answer a successful authentication request with a 301 MOVED PERMANENTLY<\/strong> status code; this makes sense in the context of an actual login form which needs to redirect after login. For a RESTful web service however, the desired response for a successful authentication should be 200 OK<\/strong>.<\/p>\n This is done by injecting a custom authentication success handler<\/strong> in the form login filter, to replace the default one. The new handler implements the exact same login as the default org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler<\/em> with one notable difference \u2013 the redirect logic is removed:<\/p>\n The authentication process uses an in-memory provider<\/strong> to perform authentication \u2013 this is meant to simplify the configuration as a production implementation of these artifacts is outside the scope of this post.<\/p>\n Now let\u2019s see how we can authenticate against the REST API \u2013 the URL for login is\u00a0\/j_spring_security_check<\/em> \u2013 and a simple curl<\/em> command performing login would be:<\/p>\n This request will return the Cookie which will then be used by any subsequent request against the REST Service.<\/p>\n We can use curl<\/em> to authentication and store the cookie it receives in a file<\/strong>:<\/p>\n Then we can use the cookie from the file<\/strong> to do further authenticated requests:<\/p>\n This authenticated request will correctly result in a 200 OK<\/strong>:<\/p>\n The Spring core dependencies<\/a> necessary for a web application and for the REST Service have been discussed in detail. For security, we\u2019ll need to add: spring-security-web<\/em> and spring-security-config<\/em> \u2013 all of these have also been covered in the Maven for Spring Security<\/a> tutorial.<\/p>\n It\u2019s worth paying close attention to the way Maven will resolve the older Spring dependencies \u2013 the resolution strategy will start causing problems<\/a> once the security artifacts are added to the pom. To address this problem, some of the core dependencies will need to be overridden in order to keep them at the right version.<\/p>\n This post covered the basic security configuration and implementation for a RESTful Service using Spring Security 3.1<\/strong>, discussing the web.xml<\/em>, the security configuration, the HTTP status codes for the authentication process and the Maven resolution of the security artifacts.<\/p>\n The implementation of this Spring Security REST Tutorial can be found in the github project<\/a> \u2013 this is an Eclipse based project, so it should be easy to import and run as it is. 1. Overview This tutorial shows how to Secure a REST Service using Spring and Spring Security 3.1 with Java based configuration. The article will focus on how to set up the Security Configuration specifically for the REST API using a Login and Cookie approach. 2. Spring Security in the web.xml The architecture of Spring Security …<\/p>\n","protected":false},"author":104,"featured_media":242,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[54,30,125],"class_list":["post-16830","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-enterprise-java","tag-restful-web-services","tag-spring","tag-spring-security"],"yoast_head":"\n2. Spring Security in the web.xml<\/em><\/h2>\n
<filter>\r\n <filter-name>springSecurityFilterChain<\/filter-name>\r\n <filter-class>org.springframework.web.filter.DelegatingFilterProxy<\/filter-class>\r\n<\/filter>\r\n<filter-mapping>\r\n <filter-name>springSecurityFilterChain<\/filter-name>\r\n <url-pattern>\/*<\/url-pattern>\r\n<\/filter-mapping><\/pre>\n
3. The Security Configuration<\/h2>\n
<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<beans:beans\r\n xmlns=\"http:\/\/www.springframework.org\/schema\/security\"\r\n xmlns:xsi=\"http:\/\/www.w3.org\/2001\/XMLSchema-instance\"\r\n xmlns:beans=\"http:\/\/www.springframework.org\/schema\/beans\"\r\n xmlns:sec=\"http:\/\/www.springframework.org\/schema\/security\"\r\n xsi:schemaLocation=\"\r\n http:\/\/www.springframework.org\/schema\/security \r\n http:\/\/www.springframework.org\/schema\/security\/spring-security-3.1.xsd\r\n http:\/\/www.springframework.org\/schema\/beans \r\n http:\/\/www.springframework.org\/schema\/beans\/spring-beans-3.2.xsd\">\r\n\r\n <http entry-point-ref=\"restAuthenticationEntryPoint\">\r\n <intercept-url pattern=\"\/api\/admin\/**\" access=\"ROLE_ADMIN\"\/>\r\n\r\n <form-login authentication-success-handler-ref=\"mySuccessHandler\" \/>\r\n\r\n <logout \/>\r\n <\/http>\r\n\r\n <beans:bean id=\"mySuccessHandler\"\r\n class=\"org.rest.security.MySavedRequestAwareAuthenticationSuccessHandler\"\/>\r\n\r\n <authentication-manager alias=\"authenticationManager\">\r\n <authentication-provider>\r\n <user-service>\r\n <user name=\"temporary\" password=\"temporary\" authorities=\"ROLE_ADMIN\"\/>\r\n <user name=\"user\" password=\"user\" authorities=\"ROLE_USER\"\/>\r\n <\/user-service>\r\n <\/authentication-provider>\r\n <\/authentication-manager>\r\n\r\n<\/beans:beans><\/pre>\n
3.1. The <http><\/em> element<\/h4>\n
3.2. The Entry Point<\/h4>\n
@Component( \"restAuthenticationEntryPoint\" )\r\npublic class RestAuthenticationEntryPoint implements AuthenticationEntryPoint{\r\n\r\n @Override\r\n public void commence( HttpServletRequest request, HttpServletResponse response, \r\n AuthenticationException authException ) throws IOException{\r\n response.sendError( HttpServletResponse.SC_UNAUTHORIZED, \"Unauthorized\" );\r\n }\r\n}<\/pre>\n3.3. The Login Form for REST<\/h4>\n
3.4. Authentication should return 200 instead of 301<\/h4>\n
public class MySavedRequestAwareAuthenticationSuccessHandler \r\n extends SimpleUrlAuthenticationSuccessHandler {\r\n\r\n private RequestCache requestCache = new HttpSessionRequestCache();\r\n\r\n @Override\r\n public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response, \r\n Authentication authentication) throws ServletException, IOException {\r\n SavedRequest savedRequest = requestCache.getRequest(request, response);\r\n\r\n if (savedRequest == null) {\r\n clearAuthenticationAttributes(request);\r\n return;\r\n }\r\n String targetUrlParam = getTargetUrlParameter();\r\n if (isAlwaysUseDefaultTargetUrl() || \r\n (targetUrlParam != null && \r\n StringUtils.hasText(request.getParameter(targetUrlParam)))) {\r\n requestCache.removeRequest(request, response);\r\n clearAuthenticationAttributes(request);\r\n return;\r\n }\r\n\r\n clearAuthenticationAttributes(request);\r\n }\r\n\r\n public void setRequestCache(RequestCache requestCache) {\r\n this.requestCache = requestCache;\r\n }\r\n}<\/pre>\n3.5. The Authentication Manager and Provider<\/h4>\n
3.6 Finally \u2013 Authentication against the running REST Service<\/h4>\n
curl -i -X POST -d j_username=user -d j_password=userPass\r\nhttp:\/\/localhost:8080\/spring-security-rest\/j_spring_security_check<\/pre>\n
curl -i -X POST -d j_username=user -d j_password=userPass -c \/opt\/cookies.txt\r\nhttp:\/\/localhost:8080\/spring-security-rest\/j_spring_security_check<\/pre>\n
curl -i --header \"Accept:application\/json\" -X GET -b \/opt\/cookies.txt \r\nhttp:\/\/localhost:8080\/spring-security-rest\/api\/foos<\/pre>\n
HTTP\/1.1 200 OK\r\nServer: Apache-Coyote\/1.1\r\nContent-Type: application\/json;charset=UTF-8\r\nTransfer-Encoding: chunked\r\nDate: Wed, 24 Jul 2013 20:31:13 GMT\r\n\r\n[{\"id\":0,\"name\":\"JbidXc\"}]<\/pre>\n4. Maven and other trouble<\/h2>\n
5. Conclusion<\/h2>\n
\n <\/p>\n