Chapter 8: Configuring endpoint-level authorization: Applying restrictions
This introduction explains why applications need authorization rules for different requests and identifies the basic purpose of two matcher methods.
After this chapter you will be able to
- Different Rules for Different Requests. Explain why an application may need authorization constraints for specific groups of requests rather than one rule for every endpoint.
- Basic Request Matcher Scope. Distinguish the scope of anyRequest() from the purpose of requestMatchers() when choosing requests for authorization configuration.
- Endpoint-specific role restrictions. Explain how requestMatchers() selects /hello and /ciao for different authorization rules, and describe which of the two example users can access each endpoint.
- General request fallback rules. Describe what happens to an added endpoint that has no specific rule, and how anyRequest() can explicitly set a rule for other requests. Explain why the general rule follows the specific matchers.
- Public access versus failed authentication. Distinguish a request to a permitAll() endpoint with no credentials from one with invalid credentials, and explain the different outcomes.
- Method and path selection. Distinguish the two requestMatchers() forms and explain when to use each to apply authorization restrictions.
- Wildcard path matching. Explain how path expressions group requests under authorization rules and distinguish what ** and * match.
- Path variable value restrictions. Describe how a matcher can use a regex on a path variable to permit only requests whose variable value consists of digits.
- Regex versus path expressions. Explain why path expressions are usually preferred for selecting requests and when a regex is warranted instead.
- Complex regex request matching. Describe how the section applies a regex request matcher to a more complex endpoint rule and what the video tests demonstrate.
What it builds on
- Restricting access based on authorities and roles (chapter 7) · The earlier authorization configurations applied rules to all endpoints.
- Restricting access for all endpoints based on user roles (chapter 7) · Uses the earlier concept of restricting access by user role.
- Restricting access to all endpoints (chapter 7) · Assumes familiarity with authorization rules that apply broadly to endpoints.
Section by section
Introduction
This introduction explains why applications need authorization rules for different requests and identifies the basic purpose of two matcher methods.
- Different Rules for Different Requests: Explain why an application may need authorization constraints for specific groups of requests rather than one rule for every endpoint.
Why it matters: This is why authorization configurations need a way to distinguish among requests. - Basic Request Matcher Scope: Distinguish the scope of anyRequest() from the purpose of requestMatchers() when choosing requests for authorization configuration.
Why it matters: The distinction explains how to move from an all-requests rule toward rules for selected requests.
Key terms: authorization constraints, endpoints, requests, anyRequest(), requestMatchers(), path, HTTP method
8.1 Using the requestMatchers() method to select endpoints
Shows how request matchers assign different role requirements to endpoints, how a general rule handles other requests, and why permitAll does not bypass failed authentication.
- Endpoint-specific role restrictions: Explain how requestMatchers() selects /hello and /ciao for different authorization rules, and describe which of the two example users can access each endpoint.
Why it matters: This is how you give different endpoints different access requirements. - General request fallback rules: Describe what happens to an added endpoint that has no specific rule, and how anyRequest() can explicitly set a rule for other requests. Explain why the general rule follows the specific matchers.
Why it matters: An explicit fallback makes the treatment of endpoints without their own rules clear. - Public access versus failed authentication: Distinguish a request to a permitAll() endpoint with no credentials from one with invalid credentials, and explain the different outcomes.
Why it matters: It explains why a public endpoint can still reject a request that supplies bad credentials.
Key terms: requestMatchers(), ADMIN role, MANAGER role, HTTP 403 Forbidden, anyRequest(), permitAll(), authenticated(), denyAll(), authentication, authorization
8.2 Selecting requests to apply authorization restrictions
This section shows how to select requests by HTTP method, path pattern, or path-variable value when applying endpoint authorization rules.
- Method and path selection: Distinguish the two requestMatchers() forms and explain when to use each to apply authorization restrictions.
Why it matters: Selecting by method as well as path lets you give GET and POST requests to the same endpoint different rules. - Wildcard path matching: Explain how path expressions group requests under authorization rules and distinguish what ** and * match.
Why it matters: A path expression can keep the same rule in place as new paths are added to a group. - Path variable value restrictions: Describe how a matcher can use a regex on a path variable to permit only requests whose variable value consists of digits.
Why it matters: Authorization can distinguish requests at the same endpoint by a value embedded in their paths. - Temporary CSRF disabling: Justify why the examples disable CSRF protection and state the limitation of that choice.
Why it matters: It keeps the example setup from being mistaken for a general security recommendation.
Key terms: requestMatchers(), HttpMethod, paths, ANT syntax, path expressions, **, *, path variable, regex, parameter expressions
8.3 Using regular expressions with request matchers
This section explains when to use regular expressions for endpoint request matching and illustrates the choice with path-variable and video-authorization examples.
- Regex versus path expressions: Explain why path expressions are usually preferred for selecting requests and when a regex is warranted instead.
Why it matters: Choosing the simpler matcher keeps authorization rules easier to read. - Single variable path matching: Describe how a regex in a path expression can target requests based on one path-variable value, using the email example.
Why it matters: A simple path-variable condition need not become a separate regex matcher. - Complex regex request matching: Describe how the section applies a regex request matcher to a more complex endpoint rule and what the video tests demonstrate.
Why it matters: The example shows why matching the request path and applying authorization to the user are both relevant to the outcome.
Key terms: path expressions, regexes, request matchers, path variable, path expression, /email/{email}, requestMatchers(), RegexRequestMatcher, /video/{country}/{language}, premium authority
8.4 Summary
Where this is used later
- Applying authorization at the endpoint layer in reactive apps (chapter 17) · Introduces non-reactive request matching, which the section compares with pathMatchers().
- (chapter intro) (chapter 11) · Assumes familiarity with authorization restrictions applied to endpoint requests.
- Enabling method security (chapter 11) · Endpoint-level authorization provides the contrast for rules that cannot be configured just at that level.
- Configuring token validation through introspection (chapter 15) · Applying authorization restrictions to requests.
- How CSRF protection works in Spring Security (chapter 9) · Returns to the CSRF protection intentionally set aside in these examples.
Concepts explained in this chapter
- request matcherRequestMatcher is an API contract for determining whether an HTTP request matches specified request attributes.
- path expressionA path expression is a request-path pattern syntax for selecting endpoint requests based on their URL structure.
- ANT syntaxANT syntax is a path-pattern notation that uses wildcard expressions to match hierarchies of path segments.
- anyRequestanyRequest is an authorization configuration method that matches every HTTP request not matched by an earlier rule.
- authentication errorAn authentication failure is a failure to verify the identity represented by credentials submitted with a request.
- permitAllpermitAll is an authorization configuration method that grants access without requiring authentication.
- regular expressionA regular expression is a pattern notation for matching character sequences and strings according to specified textual rules.
- RegexRequestMatcherRegexRequestMatcher is a Spring Security request-matching implementation that selects requests whose paths satisfy a regular expression.
- authorizationAuthorization is the process of determining whether an authenticated entity has permission to perform an action or access a resource.
- MVC matcherMvcRequestMatcher is a Spring Security request matcher that evaluates paths using Spring MVC request-mapping conventions.
- denyAlldenyAll is a Spring Security authorization configuration method that denies access to every request matched by a rule.
- authorization constraintAn authorization configuration is a set of rules that determines which authenticated or unauthenticated requests may access application functionality.
← Chapter 7: Configuring endpoint-level authorization: Restricting access
Chapter 9: Configuring CSRF protection →
These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.