Felix filter execution order issue in AEM 6.2

We have a felix filter handling the custom authentication in 6.1 similar to this acs aem sample filter. As per specification, Felix filter should get executed before Sling Engine. Thats happening in AEM 6.1 but NOT in AEM 6.2.

Steps to reproduce

1. Deploy OSGi bundle with Sample Filter to AEM 6.1, 6.2
2. Hit URL in new browser session
3. Observe execution order in 6.1 (Filter -> Sling Authentication)

04.01.2018 11:31:44.131 *INFO* [qtp1030969174-68] com.sample.project.core.filters.SampleServletFilter Calling Sample Servlet Filter
04.01.2018 11:31:44.132 *INFO* [qtp1030969174-68] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials

1. Observe execution order in 6.2 (Sling Authentication -> Filter)

04.01.2018 11:26:33.364 *INFO* [qtp774039123-271] org.apache.sling.auth.core.impl.SlingAuthenticator getAnonymousResolver: Anonymous access not allowed by configuration - requesting credentials
04.01.2018 11:26:33.378 *INFO* [0:0:0:0:0:0:0:1 [1515083193376] GET /libs/granite/core/content/login.html HTTP/1.1] com.sample.project.core.filters.SampleServletFilter Calling Sample Servlet Filter

Tried with service.ranking property also, but it doesn’t seems to be making a difference in AEM 6.2.

Additional Information - We are not yet on AEM 6.3, but tried the filter with modifications . Seems like the behavior is same as AEM 6.2.

Any pointers for this would help.

[davidjgonzalez]

Yeah - this sounds very much like the role of an authentication handler (or login module, but login modules are a bit of a pain so I tend to just use auth handlers)… sounds like you already have all the code so it seems like you’d just need to move it from the filter to the auth handler.

The saml use case might Warant looking at that hook example. That hook is derived from a use case where OOTB saml auth was used but upon successful auth, profile attributes has to be synced from sales force to aem, and the user had to also have their group membership shyster based on the sales force data.

[sandeepkumar03]

Thanks @davidjgonzalez for sample authentication handler. We have a authentication provider outside AEM, so flow is like

User request (not authenticated, redirects user to Login page of authentication provider) -> Login screen of authentication provider (set required cookies after authentication) -> Back to AEM, Filter validates and creates user on AEM, establishes session.

Probably we can look at custom Sling Authentication Handler also. We had SAML based authentication in one other project, where authentication provider was posting SAML response and was handled on AEM side to create user, establish session.