# Authorize HttpServletRequest with FilterSecurityInterceptor
| |`FilterSecurityInterceptor` is in the process of being replaced by [`AuthorizationFilter`](authorize-http-requests.html).
Consider using that instead.|
|---|----------------------------------------------------------------------------------------------------------------------------------------------------------|
This section builds on [Servlet Architecture and Implementation](../architecture.html#servlet-architecture) by digging deeper into how [authorization](index.html#servlet-authorization) works within Servlet based applications.
The [`FilterSecurityInterceptor`](https://docs.spring.io/spring-security/site/docs/5.6.2/api/org/springframework/security/web/access/intercept/FilterSecurityInterceptor.html) provides [authorization](index.html#servlet-authorization) for `HttpServletRequest`s.
It is inserted into the [FilterChainProxy](../architecture.html#servlet-filterchainproxy) as one of the [Security Filters](../architecture.html#servlet-security-filters).
![filtersecurityinterceptor](../../_images/servlet/authorization/filtersecurityinterceptor.png)
Figure 1. Authorize HttpServletRequest
* ![number 1](../../_images/icons/number_1.png) First, the `FilterSecurityInterceptor` obtains an [Authentication](../authentication/architecture.html#servlet-authentication-authentication) from the [SecurityContextHolder](../authentication/architecture.html#servlet-authentication-securitycontextholder).
* ![number 2](../../_images/icons/number_2.png) Second, `FilterSecurityInterceptor` creates a [`FilterInvocation`](https://docs.spring.io/spring-security/site/docs/5.6.2/api/org/springframework/security/web/FilterInvocation.html) from the `HttpServletRequest`, `HttpServletResponse`, and `FilterChain` that are passed into the `FilterSecurityInterceptor`.
* ![number 3](../../_images/icons/number_3.png) Next, it passes the `FilterInvocation` to `SecurityMetadataSource` to get the `ConfigAttribute`s.
* ![number 4](../../_images/icons/number_4.png) Finally, it passes the `Authentication`, `FilterInvocation`, and `ConfigAttribute`s to the xref:servlet/authorization.adoc#authz-access-decision-manager`AccessDecisionManager`.
* ![number 5](../../_images/icons/number_5.png) If authorization is denied, an `AccessDeniedException` is thrown.
In this case the [`ExceptionTranslationFilter`](../architecture.html#servlet-exceptiontranslationfilter) handles the `AccessDeniedException`.
* ![number 6](../../_images/icons/number_6.png) If access is granted, `FilterSecurityInterceptor` continues with the [FilterChain](../architecture.html#servlet-filters-review) which allows the application to process normally.
By default, Spring Security’s authorization will require all requests to be authenticated.
The explicit configuration looks like:
Example 1. Every Request Must be Authenticated
Java
```
protected void configure(HttpSecurity http) throws Exception {
http
// ...
.authorizeRequests(authorize -> authorize
.anyRequest().authenticated()
);
}
```
XML
```
```
Kotlin
```
fun configure(http: HttpSecurity) {
http {
// ...
authorizeRequests {
authorize(anyRequest, authenticated)
}
}
}
```
We can configure Spring Security to have different rules by adding more rules in order of precedence.
Example 2. Authorize Requests
Java
```
protected void configure(HttpSecurity http) throws Exception {
http
// ...
.authorizeRequests(authorize -> authorize (1)
.mvcMatchers("/resources/**", "/signup", "/about").permitAll() (2)
.mvcMatchers("/admin/**").hasRole("ADMIN") (3)
.mvcMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')") (4)
.anyRequest().denyAll() (5)
);
}
```
XML
```
(1)
(2)
(3)
(4)
(5)
```
Kotlin
```
fun configure(http: HttpSecurity) {
http {
authorizeRequests { (1)
authorize("/resources/**", permitAll) (2)
authorize("/signup", permitAll)
authorize("/about", permitAll)
authorize("/admin/**", hasRole("ADMIN")) (3)
authorize("/db/**", "hasRole('ADMIN') and hasRole('DBA')") (4)
authorize(anyRequest, denyAll) (5)
}
}
}
```
|**1**| There are multiple authorization rules specified.
Each rule is considered in the order they were declared. |
|-----|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|**2**| We specified multiple URL patterns that any user can access.
Specifically, any user can access a request if the URL starts with "/resources/", equals "/signup", or equals "/about". |
|**3**|Any URL that starts with "/admin/" will be restricted to users who have the role "ROLE\_ADMIN".
You will notice that since we are invoking the `hasRole` method we do not need to specify the "ROLE\_" prefix.|
|**4**|Any URL that starts with "/db/" requires the user to have both "ROLE\_ADMIN" and "ROLE\_DBA".
You will notice that since we are using the `hasRole` expression we do not need to specify the "ROLE\_" prefix. |
|**5**| Any URL that has not already been matched on is denied access.
This is a good strategy if you do not want to accidentally forget to update your authorization rules. |
[Authorize HTTP Requests](authorize-http-requests.html)[Expression-Based Access Control](expression-based.html)