HttpServletRequest
is the starting point of a Java web application. To configure web security, you need to set up a filter that provides various security features. To enable Spring Security, add filter and their mapping in the web.xml
file.
The first step is to configure DelegatingFilterProxy
instance in web.xml
while securing the web application's URL access with Spring Security.
In the web.xml
file, you'll find the following code:
<!—Spring Security --> <filter> <filter-name>springSecurityFilterChain</filter-name> <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> </filter> <filter-mapping> <filter-name>springSecurityFilterChain</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>
The DelegatingFilterProxy
filter class, which is a special servlet filter, doesn't do much by itself. It delegates the control to an implementation of javax.servlet.Filter
, which is registered as a special bean with ID is springSecurityFilterChain
in Spring application context. In the earlier code snippet, we added /*
, which will map to all the HTTP requests and go to this springSecurityFilterChain
.
In the preceding code snippet, we declared the URL pattern /*
, which requires some level of granted authority and prevents other users without authority from accessing the resources behind those URLs.
If we are planning to separate the entire security specific configuration into a separate configuration file named Spring-Security.xml
, we must change the security namespace to be the primary namespace for that file. Here, there are no security prefixed elements.
In the Spring-Security.xml
file, you'll find the following code:
<beans:beans xmlns="http://www.springframework.org/schema/security" xmlns:beans="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.1.xsd http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.1.xsd"> <http auto-config="true"> <intercept-url pattern='/employeeList' access='ROLE_USER,ROLE_ADMIN ' /> <intercept-url pattern='/employeeAdd' access='ROLE_USER' /> <intercept-url pattern='/employeeDelete' access='ROLE_ADMIN' /> </http> <authentication-manager> <authentication-provider> <user-service> <user name="admin" password="adminpassword" authorities="ROLE_ADMIN" /> <user name="ravisoni" password="mypassword" authorities="ROLE_USER" /> </user-service> </authentication-provider> </authentication-manager> </beans:beans>
The preceding configuration file has been divided into two major sections, as shown in previous code snippet:
<http>
tag and <intercept-url>
tag; these define what you want to secure<authentication-manager>
, <authentication-provider>
, and <user-service>
tags; these define how you want to secureWeb security is enabled using the <http>
tag. This tag is the container element for the HTTP security configuration. To define the Spring Security configuration for HTTP requests, we must first define the <http>
tag, which automatically sets up FilterChainProxy
. The auto-config=true
attribute automatically configures the basic Spring Security Services that a web application needs. This can be fine-tuned with the corresponding subelements in it.
The <intercept-url>
element is defined inside the <http>
configuration element. It restricts access to specific URLs. The <intercept-url>
tag defines the URL pattern and set of access attributes that are required to access URLs. It is mandatory to include a wildcard at the end of the URL pattern, and failing to do so will allow a hacker to skip the security check by appending arbitrary request parameter. The access attributes decide if the user can access the URLs. In most cases, access attributes are defined in terms of roles. In the previous code snippet, users with the ROLE_USER
role are able to access the /employeeList
and /employeeAdd
URLs. However, to delete an employee via the /employeeDelete
URL, a user must have the ROLE_ADMI
role.
The <authentication-manager>
tag used to process authentication information. The <authentication-provider>
tag is nested inside the <authentication-manager>
tag, and used to define credential information and the roles that will be granted to this user. In the preceding code snippet, inside the <authentication-manager>
tag, we have provided the <authentication-provider>
tag, which specifies a text-based user ID and password.