[MAGNOLIA-8232] Intercept login redirects to reduce bypasses for the login-CSRF filter Created: 19/Nov/21  Updated: 27/Oct/22

Status: Accepted
Project: Magnolia
Component/s: core
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Michael Duerig Assignee: Michael Duerig
Resolution: Unresolved Votes: 0
Labels: artt, csrf, foundation_team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Issue split
split from MAGNOLIA-8210 Review CSRF filter implementations an... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Team: Foundation

 Description   

There is a number of configured bypasses for the CSRFTokenFilter. Within MAGNOLIA-8210 mgeljic brought up the idea to intercept login redirects for getting rid of some of these bypasses. Within this ticket we should:

  • Clarify the approach envisioned by mgeljic
  • Implement a POC
  • Productise the POC if it bring enough value

Implementation note: may we can use security callbacks?



 Comments   
Comment by Mikaël Geljić [ 07/Dec/21 ]

The more relevant quote might be this one:

For login-csrf, URI-based bypasses are most likely wrong in the first place, since all unauthorized URIs forward to the login screen. But programmatically, we can tinker with AggregationState for GET requests, maybe intercept the response on the "way back" from the filter chain, instead of on the way in.

—emphasized what it boils down to imo. originalURI is available in AggregationState, but we might not need it. If the response status is unauthorized (and we forwarded to the login screen instead), we might as well stop bypassing the login-csrf almost entirely, and token generation would only occur for protected resources.

Generated at Mon Feb 12 04:30:50 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.