Authentication Handler vs Filter

[dylanmccurry]

Using AEM Sites 6.5, I have incorporated a custom authentication solution into my website. It revolves around MSAL (Microsoft Authentication Library) and asking users to login with their Microsoft accounts.

When intercepting requests, detecting that the user is not logged in, and asking them to login before a page is rendered- what is the real benefit / difference in handling this logic in an AuthenticationHandler as opposed to a Filter?

For instance, I am noticing that in a custom authentication handler, I can detect that the page requires login and the user isn't logged in- so I can send them to go login by manipulating the response and exiting. I can do similarly in a filter- if the request is for an authenticated area and the user isn't logged in, then I send them through the login flow.

What's the real benefit in doing this via one method or another?  It seems the AuthenticationHandler should be responsible for extracting the user out of the request (e.g., via session cookie) and returning that to AEM... is it sketchy to have the AuthenticationHandler also issue 302 redirects to instruct the user to login?

[daniel-strmecki · Accepted solution]

Hi @dylanmccurry,

you can indeed achieve the same logic with both Authentication Handlers and Filters, but the more appropriate interface to use in your case is the Authentication Handler. Also, I don't see a problem with 302 responses.

The difference between the two can be summarized in two points:

1) Lifecycle Management

• Authentication Handlers are executed early in the request processing cycle before the request is passed to Sling or any other processing layers
• Filters are invoked after the Authentication Handler but before the request is handled by Sling or other components

2) Purpose/Responsibility

• Authentication Handlers determine if a request contains valid credentials and redirect unauthenticated requests to an authentication endpoint
• Filters provide a mechanism to process or modify requests and responses at various stages of the request lifecycle. They can be used for different tasks like logging, modifying headers, applying security policies, caching, etc.

Hope this helps,

Daniel

[dylanmccurry]

Thanks, I suppose coming from a .NET and Node background- the filters feel a lot like middleware from those platforms, and middleware is indeed where this sort of logic would belong.

Are there any downsides to holding all of this logic in the filter layer?

[daniel-strmecki]

Hi @dylanmccurry,

IMO not really, besides not aligning with Adobe/Sling's vision on how to implement it. However, keep in mind that AEM is also constantly evolving, and aligning with the creator's visions and avoiding too much customization usually proves to be the correct strategy.

Good luck,

Daniel