Multiple Authentication Entry Points

[Ben Alex]

You don't need two SecurityEnforcementFilters and you don't need two AuthenticationFilterEntryPoints.

The AuthenticationFilterEntryPoint is used by SecurityEnforcementFilter whenever an AuthenticationException is detected. In other words, when SecurityEnforcementFilter decides the user needs to logon, it launches AuthenticationFilterEntryPoint. You can only have one such filter per webapp. If you really need more customised handling, such as the intended login form is based on the request that was made which failed, you'll need to write your own AuthenticationEntryPoint.

It should also be noted the AuthenticationProcessingFilter.defaultTargetUrl is only called when the login was not as a result of the AuthenticationFilterEntryPoint. If it was the result of the AuthenticationFilterEntryPoint, the SecurityEnforcementFilter will have told the AuthenticationProcessingFilter (via the HttpSession) the URL that should be displayed post-authentication. That URL should be the secured page the user requested but was denied. The defaultTargetUrl only applies if the user logged in of their own accord - not as a result of the application prompting them to. If you want to always ignore the AuthenticationFilterEntryPoint target URL, your best course of action is to write a custom AuthenticationEntryPoint which changes the HttpSession parameter.

Hope this explains a bit more clearly what is going on.

[simontang_tang]

Thank you for your explain about the filters.

I have realized that the filters in web.xml are redundant after I posted the last post. Then I removed them. But the result still was not what I want.

I have ever thought to write a MutliAuthenticationEntryPoint class to accomplish this task, but I didn't understant fully the internal relationships.

Now I used a trick to fulfill this task: write a jsp file for home page login form and a servlet, and in the servlet, get the authenticationManager to authenticate and put the authentication object into session, and this does works well.

Maybe I will rethink to implement my AuthenticationEntryPoint later.

Anyway, many thanks for your help.

[Ben Alex]

Now I used a trick to fulfill this task: write a jsp file for home page login form and a servlet, and in the servlet, get the authenticationManager to authenticate and put the authentication object into session, and this does works well.

Just double-check it really does work as you intend. A lot of people write directly to the HttpSession and then get surprised when strange things happen. Your AbstractIntegrationFilter does this:

1. Retrieve from the well-known location (typically HttpSession) the Authentication
2. Populate ContextHolder with Authentication
3. Proceed with request (ie your web controller/servlet etc runs now)
4. Retrieve from the ContextHolder the Authentication
5. Write the retrieved Authentication back to the well-known location

So your HttpSession may get overwritten with null if you just set it via your servlet.

I'd encourage instead to customise an AuthenticationEntryPoint. It's really easy to do. This is the entire interface:

    public void commence(ServletRequest request, ServletResponse response)
        throws IOException, ServletException;

So your implementation just looks at the request URL, and decides the correct URL to put into HttpSession parameter defined by AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL _KEY (which would have earlier been set by the SecurityEnforcementFilter).

If a login form is presented because of a user wish to login - as opposed to your SecurityEnforcementFilter detecting a problem and delegating to AuthenticationEntryPoint - the defaultTargetUrl defined against the responding AuthenticationProcessingFilter will be used.

[simontang_tang]

Yesterday my trick has encountered a problem: the login process on the home page is correct; but when I entered into user's personal home page, it's correct in the first time, and after I logged out from personal home page, then redirect to home page, the process was also correct. But when I logged in again and entered into personal home page, the login form page showed while personal information showed on the page is correct. Could you give me some hints about this problem?

Today I implemented a AuthenticationEntryPoint as you stated, the code like such:

public class EdusuppAuthenticationEntryPoint extends
        AuthenticationProcessingFilterEntryPoint {
    private static final Log logger = LogFactory.getLog(EdusuppAuthenticationEntryPoint.class);
    
    private PortResolver portResolver = new PortResolverImpl();
    
    public void setPortResolver(PortResolver portResolver) {
        this.portResolver = portResolver;
    }

    public PortResolver getPortResolver() {
        return portResolver;
    }
    
    /* (non-Javadoc)
     * @see net.sf.acegisecurity.intercept.web.AuthenticationEntryPoint#commence(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
     */
    public void commence(ServletRequest request, ServletResponse response)
            throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        String scheme = request.getScheme();
        String serverName = request.getServerName();
        int serverPort = portResolver.getServerPort(request);
        String contextPath = req.getContextPath();

        boolean includePort = true;

        if ("http".equals(scheme.toLowerCase()) && (serverPort == 80)) {
            includePort = false;
        }

        String redirectUrl = scheme + "://" + serverName
            + ((includePort) ? (":" + serverPort) : "") + contextPath;

        if(req.getRequestURL().indexOf("userWelcome") != -1) {
            redirectUrl += "/loginMain.jsp";
            
            req.getSession().setAttribute(AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL_KEY, redirectUrl);
            
            if (logger.isDebugEnabled()) {
                logger.debug("Redirecting to: " + redirectUrl);
            }

            ((HttpServletResponse) response).sendRedirect(((HttpServletResponse) response)
                .encodeRedirectURL(redirectUrl));
        } else {
             super.commence(request, response);
        }
    }
}

loginMain.jsp is the login form page will be show in the home page using IFrame, and the iframe will linked userWelcome.jsp, this page required the user to be authorized. The problem is when I access the home page, the login form showed but after authorized, the login form still shows. When I access the personal home page, it shows the user's personal information.

Would you like to check the problem? Many thanks.

[Ben Alex]

Let's try and simplify things a bit.

I presume you're still using this config:

<bean id="authenticationProcessingFilter" class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
      <property name="authenticationManager"><ref bean="authenticationManager"/></property>
      <property name="authenticationFailureUrl"><value>/loginError.jsp</value></property>
      <property name="defaultTargetUrl"><value>/mainMenu.html</value></property>
      <property name="filterProcessesUrl"><value>/j_acegi_security_check</value></property>
</bean> 

<bean id="authenticationProcessingFilter2" class="net.sf.acegisecurity.ui.webapp.AuthenticationProcessingFilter">
      <property name="authenticationManager"><ref bean="authenticationManager"/></property>
      <property name="authenticationFailureUrl"><value>/loginMainError.jsp</value></property>
      <property name="defaultTargetUrl"><value>/userWelcome.jsp</value></property>
      <property name="filterProcessesUrl"><value>/j_acegi_security_check_home</value></property>
</bean>

I also presume your /loginMain.jsp login form redirects to /j_acegi_security_check. I presume your home page login form POSTs to /j_acegi_security_check_home.

Next up disable any IFRAMEs and start your web container from scratch. If you visit /loginMain.jsp, login as a user, does it post to /j_acegi_security_check and then redirect to /mainMenu.html?

Next shutdown your web container and start it again without any IFRAMEs. If you visit your home page login form, does it POST to /j_acegi_security_check_home and then redirect to /userWelcome.jsp?

This basic initial behaviour does not in any way involve an AuthenticationEntryPoint. It's solely as a result of user login requests.

Ensure your "logout" operation is actually a HttpSession invalidation, rather than any overwriting an HttpSession attribute or ContextHolder value.

Once you've proven your basic configuration works, next try accessing a secure page when you're not logged in. Look at the debug logs and ensure the entry point redirects to the correct login page. Then check that login page, subsequent to successful login, redirects to the AbstractProcessingFilter.ACEGI_SECURITY_TARGET_URL _KEY (which your entry point will have overwritten if required).

[simontang_tang]

The page flow likes such:
1. loginMain.jsp ----> loginMainServlet ----> j_acegi_security_check_home ----> userWelcome.jsp

2. login.jsp ----> loginServlet ----> j_acegi_security_check ----> mainMenu.html

3. userWelcome.jsp -----> logoutMain.jsp ----> loginFilter (invalidate the session and ContextHolder.setContext(null)

4. mainMenu.html ----> logout.jsp ---> loginFilter(invalidate the session and ContextHolder.setContext(null)

[Ben Alex]

What's the problem with that? AFAICS it's behaving as configured.

[simontang_tang]

The page flow I posted is the result I want. But actually not.

I have tried two filters in applicationContext.xml file, page flow 1 is correct, but page flow 2 is not, the error info is : j_acegi_security_check can't be found.

Then I returned to the previous trick: using servlet and jsp to authenticate user and populate session. The first time I logged in on the home page(loginMain.jsp), and showed userWelcome.jsp, this is correct. After logged out through logout.jsp, I returned to the loginMain.jsp. But when I logged in through loginMain.jsp again, I got the login.jsp. This is the problem: for it should display mainMenu.html.

[simontang_tang]

The following information is copied from tomcat console. From the second login to showing login.jsp:

[edusupp] DEBUG [Thread-13] LoginMainServlet.execute(93) | Encrypting password f
or user 'student_1'
[edusupp] DEBUG [Thread-13] ProviderManager.doAuthentication(125) | Authenticati
on attempt using net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider
[edusupp] DEBUG [Thread-13] EhCacheBasedUserCache.getUserFromCache(86) | Cache h
it: false; username: student_1
[edusupp] DEBUG [Thread-13] EhCacheBasedUserCache.putUserInCache(119) | Cache pu
t: student_1
[edusupp] INFO [Thread-13] UserCounterListenerSpring.onApplicationEvent(55) | Au
thentication success for user: student_1; details: 127.0.0.1
[edusupp] DEBUG [Thread-13] SecurityEnforcementFilter.doFilter(168) | Chain proc
essed normally
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(176) | Updating c
ontainer with new Authentication object, and then removing Authentication from C
ontextHolder
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(164) | Authentica
tion not added to ContextHolder (could not extract an authentication object from
 the container which is an instance of Authentication)
[edusupp] DEBUG [Thread-13] AbstractSecurityInterceptor.interceptor(346) | Publi
c object - authentication not attempted
[edusupp] DEBUG [Thread-13] SecurityEnforcementFilter.doFilter(168) | Chain proc
essed normally
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(176) | Updating c
ontainer with new Authentication object, and then removing Authentication from C
ontextHolder
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(164) | Authentica
tion not added to ContextHolder (could not extract an authentication object from
 the container which is an instance of Authentication)
[edusupp] DEBUG [Thread-13] AbstractSecurityInterceptor.interceptor(346) | Publi
c object - authentication not attempted
[edusupp] DEBUG [Thread-13] SecurityEnforcementFilter.doFilter(168) | Chain proc
essed normally
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(176) | Updating c
ontainer with new Authentication object, and then removing Authentication from C
ontextHolder
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(164) | Authentica
tion not added to ContextHolder (could not extract an authentication object from
 the container which is an instance of Authentication)
[edusupp] DEBUG [Thread-13] AbstractSecurityInterceptor.interceptor(273) | Secur
e object: FilterInvocation: URL: /mainMenu.html; ConfigAttributes: [ROLE_SUPERVI
SOR, ROLE_STUDENT, ROLE_TEACHER, ROLE_PARENT, ROLE_EXPERT, ROLE_CA]
[edusupp] DEBUG [Thread-13] SecurityEnforcementFilter.doFilter(191) | Authentica
tion failed - adding target URL to Session: http://localhost:8080/edusupp/mainMe
nu.html
net.sf.acegisecurity.AuthenticationCredentialsNotFoundException: Authentication
credentials were not found in the SecureContext
        at net.sf.acegisecurity.intercept.AbstractSecurityInterceptor.intercepto
r(AbstractSecurityInterceptor.java:289)
        at net.sf.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(F
ilterSecurityInterceptor.java:78)
        at net.sf.acegisecurity.intercept.web.SecurityEnforcementFilter.doFilter
(SecurityEnforcementFilter.java:165)
        at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProx
y.java:88)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
        at net.sf.acegisecurity.ui.AbstractIntegrationFilter.doFilter(AbstractIn
tegrationFilter.java:170)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
        at net.sf.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractPro
cessingFilter.java:368)
        at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProx
y.java:88)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
        at org.displaytag.filter.ResponseOverrideFilter.doFilter(ResponseOverrid
eFilter.java:88)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
        at org.appfuse.webapp.filter.GZIPFilter.doFilter(GZIPFilter.java:51)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
icationFilterChain.java:213)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
ilterChain.java:193)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
alve.java:256)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
alve.java:191)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

        at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
2415)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
ava:180)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatche
rValve.java:171)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j
ava:172)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:641)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
ve.java:174)
        at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContex
t.invokeNext(StandardPipeline.java:643)
        at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
a:480)
        at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)

        at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:22
3)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
:594)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proce
ssConnection(Http11Protocol.java:392)
        at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java
:565)
        at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
ool.java:619)
        at java.lang.Thread.run(Thread.java:534)
[edusupp] DEBUG [Thread-13] AuthenticationProcessingFilterEntryPoint.commence(17
6) | Redirecting to: http://localhost:8080/edusupp/login.jsp
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(176) | Updating c
ontainer with new Authentication object, and then removing Authentication from C
ontextHolder
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(164) | Authentica
tion not added to ContextHolder (could not extract an authentication object from
 the container which is an instance of Authentication)
[edusupp] DEBUG [Thread-13] AbstractSecurityInterceptor.interceptor(346) | Publi
c object - authentication not attempted
[edusupp] DEBUG [Thread-13] SecurityEnforcementFilter.doFilter(168) | Chain proc
essed normally
[edusupp] DEBUG [Thread-13] AbstractIntegrationFilter.doFilter(176) | Updating c
ontainer with new Authentication object, and then removing Authentication from C
ontextHolder

login user name : student_1, and his password is encrypted using sha. His role is ROLE_STUDENT.