Chapter 7: Configuring endpoint-level authorization: Restricting access
This introduction distinguishes authorization from authentication and explains where an authorization filter acts on a request.
After this chapter you will be able to
- Authentication and authorization distinction. Distinguish identifying a caller from deciding whether that identified caller may access a requested resource. Explain why recognizing a user does not by itself grant access to every resource.
- Authorization filter decision point. Describe what happens after authentication in the Spring Security flow: the request is delegated to an authorization filter, which allows or rejects it according to configured authorization rules.
- Authorities as permitted actions. Explain that a GrantedAuthority represents an action a user may perform on a resource, and that its name is used when defining an authorization rule.
- User authorities after authentication. Describe how UserDetails holds a user's GrantedAuthority instances and how the application can use them after authentication.
- All-request authorization scope. Explain how authorizeHttpRequests(), anyRequest(), and permitAll() establish the scope and baseline for the examples, and how replacing permitAll() changes who may call the endpoints.
- Single and alternative authorities. Distinguish hasAuthority() from hasAnyAuthority() and describe the access each grants in the John and Jane example.
- Flexible access rule trade-off. Explain when access() is useful, what it receives, and why the section recommends simpler methods for straightforward authority checks. Describe how the read-without-delete example uses the extra flexibility.
- Roles and authorities. Distinguish coarse-grained roles from fine-grained authorities and explain why an application might use roles to group actions.
- Role-based endpoint rules. Describe how hasRole(), hasAnyRole(), and access() express endpoint authorization based on roles, including which methods the section recommends first.
- Role prefix and user builders. Explain how Spring Security represents roles and when to include the ROLE_ prefix while defining or checking them.
- The denyAll access rule. Explain that denyAll() rejects requests, in contrast to permitAll(), which permits them, and that it can be used to deny requests covered by an access rule.
What it builds on
- Understanding the AuthenticationProvider (chapter 6) · Assumes the earlier discussion of authentication.
- Implementing filters in the Spring Security architecture (chapter 5) · Assumes familiarity with filters in Spring Security.
- Detailing on the GrantedAuthority contract (chapter 3) · The introduction to the GrantedAuthority contract.
- Describing users with the UserDetails contract (chapter 3) · The UserDetails contract describing a user.
- Applying authorization at the endpoint level (chapter 2) · The earlier introduction to endpoint-level authorization.
Section by section
Introduction
This introduction distinguishes authorization from authentication and explains where an authorization filter acts on a request.
- Authentication and authorization distinction: Distinguish identifying a caller from deciding whether that identified caller may access a requested resource. Explain why recognizing a user does not by itself grant access to every resource.
Why it matters: A request can come from a recognized user and still need to be denied. - Authorization filter decision point: Describe what happens after authentication in the Spring Security flow: the request is delegated to an authorization filter, which allows or rejects it according to configured authorization rules.
Why it matters: It locates the access decision in the request flow without confusing it with authentication.
Key terms: authentication, authorization, identified client, requested resource, authentication flow, authorization filter, authorization rules
7.1 Restricting access based on authorities and roles
This section explains how Spring Security represents a user's permitted actions as authorities and makes them available for authorization after authentication.
- Authorities as permitted actions: Explain that a GrantedAuthority represents an action a user may perform on a resource, and that its name is used when defining an authorization rule.
Why it matters: Authorities give authorization rules a way to refer to the actions users are allowed to perform. - User authorities after authentication: Describe how UserDetails holds a user's GrantedAuthority instances and how the application can use them after authentication.
Why it matters: This connects the privileges assigned to a user with the information the application uses to grant access.
Key terms: authority, GrantedAuthority, getAuthority(), authorization rule, UserDetails, getAuthorities(), authentication
7.1.1 Restricting access for all endpoints based on user authorities
This section shows how to restrict all endpoint requests according to users’ authorities, from simple authority checks to a more flexible authorization expression.
- All-request authorization scope: Explain how authorizeHttpRequests(), anyRequest(), and permitAll() establish the scope and baseline for the examples, and how replacing permitAll() changes who may call the endpoints.
Why it matters: The scope of anyRequest() determines which requests an authority rule will restrict. - Single and alternative authorities: Distinguish hasAuthority() from hasAnyAuthority() and describe the access each grants in the John and Jane example.
Why it matters: Choosing between these methods lets you express a simple authority requirement without making the rule harder to read. - Flexible access rule trade-off: Explain when access() is useful, what it receives, and why the section recommends simpler methods for straightforward authority checks. Describe how the read-without-delete example uses the extra flexibility.
Why it matters: The trade-off helps you keep ordinary rules readable while retaining a way to express more complex conditions.
Key terms: authorizeHttpRequests(), anyRequest(), permitAll(), hasAuthority(), hasAnyAuthority(), WRITE, READ, access(), AuthorizationManager, WebExpressionAuthorizationManager
7.1.2 Restricting access for all endpoints based on user roles
This section explains how roles group privileges and how to restrict endpoint access by role in Spring Security.
- Roles and authorities: Distinguish coarse-grained roles from fine-grained authorities and explain why an application might use roles to group actions.
Why it matters: Grouping actions into roles can make authorization rules easier to express. - Role-based endpoint rules: Describe how hasRole(), hasAnyRole(), and access() express endpoint authorization based on roles, including which methods the section recommends first.
Why it matters: These methods let you state which users may reach a protected endpoint. - Role prefix and user builders: Explain how Spring Security represents roles and when to include the ROLE_ prefix while defining or checking them.
Why it matters: Using the prefix in the wrong place can make a role definition invalid or a role check incorrect. - General access method flexibility: Explain why access() is not limited to authority or role checks and why simpler configurations are preferred when possible.
Why it matters: You can express other access rules without making ordinary role rules more complex than necessary.
Key terms: role, authority, fine-grained, coarse grained, hasRole(), hasAnyRole(), access(), AuthorizationManager, GrantedAuthority, ROLE_ prefix
7.1.3 Restricting access to all endpoints
This section explains denyAll() as a way to reject requests and illustrates why an application might need to deny particular groups of requests.
- The denyAll access rule: Explain that denyAll() rejects requests, in contrast to permitAll(), which permits them, and that it can be used to deny requests covered by an access rule.
Why it matters: It gives you an explicit way to reject requests when an access requirement calls for it. - Reasons to deny selected requests: Describe the section’s examples of why denying requests can be useful: rejecting email-address formats the application does not accept and having each gateway reject paths it does not serve.
Why it matters: These examples show why an explicit denial rule can be useful even when the application serves other requests.
Key terms: denyAll(), permitAll(), access rules, gateway, paths
7.2 Summary
Where this is used later
- (chapter intro) (chapter 8) · The earlier authorization configurations applied rules to all endpoints.
- Using the requestMatchers() method to select endpoints (chapter 8) · Assumes the distinction between authentication and authorization in access restrictions.
- Applying preauthorization rules (chapter 11) · Restricting access based on user authorities.
- Selecting requests to apply authorization restrictions (chapter 8) · Authority requirements can be applied when selecting which requests receive authorization restrictions.
Concepts explained in this chapter
- accessaccess() is an authorization configuration method that delegates request authorization to a supplied authorization decision function or manager.
- authorizationAuthorization is the process of determining whether an authenticated entity has permission to perform an action or access a resource.
- roleA role is a named grouping of permissions or authorities used to represent an actor's access level.
- hasauthorityhasAnyAuthority() is an authorization configuration method that permits a request when the user has at least one authority from a specified set.
- AuthorizationManagerAuthorizationManager is a Spring Security contract for evaluating whether an authenticated principal is authorized for an object or request.
- WebExpressionAuthorizationManagerWebExpressionAuthorizationManager is a Spring Security AuthorizationManager implementation that evaluates web authorization decisions from Spring Expression Language expressions.
- authorizeHttpRequestsauthorizeHttpRequests is an HttpSecurity configuration method for defining authorization rules for HTTP requests.
- endpointAn endpoint is a network-accessible entry point representing an operation or resource in an application.
- ROLE_ prefixThe ROLE_ prefix is the naming convention Spring Security uses to distinguish role authorities from other authorities.
- hasAnyRole()hasAnyRole() is an authorization configuration method that permits access when the user has at least one role from a specified set.
- hasRole()hasRole() is an authorization configuration method that permits access when the user has a specified role.
- roles()roles() is a Spring Security User builder method that creates role authorities and adds the ROLE_ prefix to supplied role names.
- denyAlldenyAll is a Spring Security authorization configuration method that denies access to every request matched by a rule.
- regular expressionA regular expression is a pattern notation for matching character sequences and strings according to specified textual rules.
- GrantedAuthorityGrantedAuthority is a Spring Security interface representing an authority granted to an authenticated principal.
- UserDetailsUserDetails is a Spring Security representation of a user's identity, password, and granted authorities.
- getAuthorities()getAuthorities() is a UserDetails method that returns the authorities granted to the user.
- permitAllpermitAll is an authorization configuration method that grants access without requiring authentication.
- InMemoryUserDetailsManagerInMemoryUserDetailsManager is a Spring Security UserDetailsService and UserDetailsManager implementation that stores user details in application memory.
- anyRequestanyRequest is an authorization configuration method that matches every HTTP request not matched by an earlier rule.
← Chapter 6: Implementing authentications
Chapter 8: Configuring endpoint-level authorization: Applying restrictions →
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.