Lesson 14 · Security · all of Section 5

Spring Security

Authentication vs authorization, the filter chain, configuring access, and method-level security.

What you'll be tested on The authentication/authorization distinction (and their order); that Security is built on a filter chain; the core types (UserDetailsService, UserDetails, GrantedAuthority); URL authorization with matchers; and enabling method security (@PreAuthorize).

Two words that anchor everything

	Authentication (authn)	Authorization (authz)
Question	Who are you?	What are you allowed to do?
Does	Verifies identity (username/password, token…)	Grants/denies access to a resource
Order	First	After authentication

Order matters on the exam Authorization comes after authentication — you establish who the user is, then decide what they may access.

The filter chain

Spring Security plugs into a web app as a chain of servlet filters that intercept every request before it reaches your controllers. A single FilterChainProxy (registered as springSecurityFilterChain via a DelegatingFilterProxy) runs the individual security filters — authentication, authorization, CSRF, and so on.

The core types

Type	Role
`SecurityContextHolder`	Holds the `SecurityContext` (→ the current `Authentication`) for the thread
`Authentication`	The token for the current request: the principal + credentials + authorities
`UserDetailsService`	Loads a user by username (`loadUserByUsername`) → returns `UserDetails`
`UserDetails`	The user's stored info: username, password, authorities
`GrantedAuthority`	A single permission / role held by the user
`PasswordEncoder`	Hashes & verifies passwords (e.g. `BCryptPasswordEncoder`)

Configuring authentication & authorization

In the Boot 2.5 / Security 5.5 era you extend WebSecurityConfigurerAdapter and configure HttpSecurity. Restrict URLs with matchers and access rules:

http
  .authorizeRequests()
    .antMatchers("/admin/**").hasRole("ADMIN")   // URL-pattern authorization
    .antMatchers("/public/**").permitAll()
    .anyRequest().authenticated()
  .and().formLogin();

URL matchers: antMatchers(...), mvcMatchers(...), regexMatchers(...) — then rules like hasRole, hasAuthority, permitAll, authenticated.
Authentication mechanisms Spring Security supports out of the box: in-memory, JDBC, LDAP, and a DAO approach (a UserDetailsService + PasswordEncoder).

Method-level security

Beyond URLs, you can secure individual methods (typically service-layer). Turn it on with @EnableGlobalMethodSecurity, choosing which annotation styles to enable:

Annotation	Style	Enabled by
`@PreAuthorize` / `@PostAuthorize`	SpEL expressions (e.g. `hasRole('ADMIN')`)	`prePostEnabled = true`
`@Secured`	Role names only, no SpEL	`securedEnabled = true`
`@RolesAllowed`	JSR-250	`jsr250Enabled = true`

@EnableGlobalMethodSecurity(prePostEnabled = true)   // enables @PreAuthorize/@PostAuthorize
public class MethodSecurityConfig { }

@PreAuthorize("hasRole('ADMIN')")
public void deleteAccount(Long id) { ... }

Primary source — read this

Spring Security 5.5 — Servlet Security: The Big Picture (filter chain) & Method Security

Read "Architecture" (filter chain), "Authentication" (UserDetailsService), "Authorization", and "Method Security".

Check yourself

The authn/authz distinction, the core types, and enabling method security are the money questions. Options shuffle on every load.

🎉 Section 5 (Security) complete That's the whole Security section. Second pass: your book's Security section (12 questions). Only Spring Boot (Lessons 15–16) remains.

I'm your teacher — ask me anything. Want a full security config with in-memory users + a @PreAuthorize example, or the difference between hasRole and hasAuthority? Ask. Say "continue" to start Section 6 — Spring Boot with Lesson 15.

← Lesson 13 · Testing Lesson 15 · Spring Boot →