Dedicated authentication-handler #WiP #1212
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi spring-authorization-server gurus,
I'm probably holding it wrong, but here goes :)
My use-case is pretty straight-forward; add "security logging" as recommended by OWASP.
I've looked into the authorization-server, but didn't find logging-support that matches the recommendation - my apologies if I've missed the support.
So I've created this non-exhaustive draft to demonstrate one possible approach supporting my use-case.
Expected Behavior
Augmenting framework error-/success-handling is a 1st class citizen.
Ex. based on the drafted approach I would be able to provide my own authentication-handler ala.
As demonstrated above, this approach would support augmenting without duplicating code from the framework.
I suggest this change, from private method to dedicated class, is applied to all filter authentication-handlers - as that would support any append/augment use-case I can think of 🤓
If this approach is acceptable I would be happy to take a stab at refactoring.
Current Behavior
Currently each authentication-handler implemented by the framework is encapsulated in the class in a private method unfit for reuse.
Context
In-order to augment the endpoint filters, I've accumulated an undesired responsibility for maintaining a mirror of the default authentication-handlers implementation.
Augment framework behavior, optimally by appending a bit of custom configuration/code - without changing the core-behavior.
Undoing the private encapsulation at runtime via reflection, but rejected the approach as it's brittle & time-consuming.
Unfortunately no :/