Multiple Authentication Entry Points

[darragh]

Hi,

I'm replacing my own Security mechanisms with Acegi in an App where currently I have seperate login forms for admin and users.

Can someone suggest the best approach to doing this in Acegi? I understand I could make things work with a single entrypoint for all domains but I'd like to be able to stick with my current setup.

Cheers
Darragh

[Ben Alex]

Are you planning on using net.sf.acegisecurity.webapp.AuthenticationProcessi ngFilter (most people do)?

If so, probably the simplest is to configure two instances of that filter in web.xml, with different AuthenticationProcessingFilter.filterProcessesUrl and AuthenticationProcessingFilter.authenticationFailu reUrl.

Of course, it would be cleaner to have one login form (but I'm sure you've got your reasons)...

[simontang_tang]

I have encountered the same problem: the homepage needed a login form, and when the user wants to access thoese authorized pages, another login form is needed.

After I configure two filters in web.xml and two securityEnforcementFilters and two authenticationProcessingFilterEntryPoints in applicationContext.xml,
it seems that only one filter take effect.

Can someone sugguest a approach to do this in Acegi?

[Ben Alex]

When you say there are two login forms, I assume the user can login to either one of them and avoid needing to login again or separately through the second login form?

I'm not sure why this isn't working. Although if you just want a convenience login box on your home page, why not get it to post to /j_acegi_security_check, being the same post target as your normal login form? You shouldn't need separate login processing filters.

If this doesn't help, please post a debug-level log from AuthenticationProcessingFilter,

[simontang_tang]

Let me explain why I must do in such a way.

Our webapp has a home page, and authorized users have their personal home page. The login form exists in two pages: one for home page, another one for a separated login page.

The original page flow is user can login from both the above pages, and will be redirected to their personal home page. But now the page flow will be changed in such a way: if user login from home page, then he will stay in the home page, but if he login from the seperated login page, then he will be redirected to his personal main page. So, as you can see, one entry point is not enough.

The configuration for applicationContext.xml is like such:

<bean id="authenticationProcessingFilter" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilter">
<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="securityEnforcementFilter" class="net.sf.acegisecurity.intercept.web.SecurityEnforce mentFilter">
<property name="filterSecurityInterceptor"><ref bean="filterInvocationInterceptor"/></property>
<property name="authenticationEntryPoint"><ref bean="authenticationProcessingFilterEntryPoint"/></property>
</bean>

<bean id="authenticationProcessingFilterEntryPoint" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilterEntryPoint">
<property name="loginFormUrl"><value>/login.jsp</value></property>
<property name="forceHttps"><value>false</value></property>
</bean>

<bean id="authenticationProcessingFilter2" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilter">
<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</value></property>
</bean>
<bean id="authenticationProcessingFilterEntryPoint2" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilterEntryPoint">
<property name="loginFormUrl"><value>/loginMain.jsp</value></property>
<property name="forceHttps"><value>false</value></property>
</bean>
<bean id="securityEnforcementFilter2" class="net.sf.acegisecurity.intercept.web.SecurityEnforce mentFilter">
<property name="filterSecurityInterceptor"><ref bean="filterInvocationInterceptor"/></property>
<property name="authenticationEntryPoint"><ref bean="authenticationProcessingFilterEntryPoint2"/></property>
</bean>

But when I login from either login form, I will be redirected to the same page: /userWelcome.jsp.

[Ben Alex]

Both filters are defined to process /j_acegi_security_check. You need one to process say /j_acegi_security_check_home_page and one /j_acegi_security_check_personal_page to achieve your goal.

[simontang_tang]

Both filters are defined to process /j_acegi_security_check. You need one to process say /j_acegi_security_check_home_page and one /j_acegi_security_check_personal_page to achieve your goal.

/j_acegi_security_check_home_page and /j_acegi_security_check_personal_page ? Can I define the authorize url in any name?

Thank you for your reply. I will test this.

[simontang_tang]

I have tested this configuration as you recommended. I changed the /j_acegi_security_check on the home page to /j_acegi_security_check_home, and the other one is /j_acegi_seurity_check. But when I login from the separated login form(not the form in the home page), I got a error that /j_acegi_seurity_check cann't find. And when I enter an authorized page without login, the login form will be the form in the home page.

I was wondering whether the configuration is correct or not. Can you give me some more suggestions?

[Ben Alex]

You said /j_acegi_seurity_check, which might be a typo or might be the problem. Please post the application context, as well as a debug-level log, and I'll be happy to take a look.

[simontang_tang]

Sorry for my typing error. It is "/j_acegi_security_check".

applicationContext.xml :

<bean id="authenticationProcessingFilter" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilter">
<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="securityEnforcementFilter" class="net.sf.acegisecurity.intercept.web.SecurityEnforce mentFilter">
<property name="filterSecurityInterceptor"><ref bean="filterInvocationInterceptor"/></property>
<property name="authenticationEntryPoint"><ref bean="authenticationProcessingFilterEntryPoint"/></property>
</bean>

<bean id="authenticationProcessingFilterEntryPoint" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilterEntryPoint">
<property name="loginFormUrl"><value>/login.jsp</value></property>
<property name="forceHttps"><value>false</value></property>
</bean>

<bean id="authenticationProcessingFilter2" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilter">
<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>
<bean id="authenticationProcessingFilterEntryPoint2" class="net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilterEntryPoint">
<property name="loginFormUrl"><value>/loginMain.jsp</value></property>
<property name="forceHttps"><value>false</value></property>
</bean>
<bean id="securityEnforcementFilter2" class="net.sf.acegisecurity.intercept.web.SecurityEnforce mentFilter">
<property name="filterSecurityInterceptor"><ref bean="filterInvocationInterceptor"/></property>
<property name="authenticationEntryPoint"><ref bean="authenticationProcessingFilterEntryPoint2"/></property>
</bean>


web.xml:

<filter>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilter</param-value>
</init-param>
</filter>
<filter>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<filter-class>net.sf.acegisecurity.ui.AutoIntegrationFilter</filter-class>
</filter>
<filter>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.intercept.web.SecurityEnforce mentFilter</param-value>
</init-param>
</filter>

<filter>
<filter-name>Acegi Authentication Processing Filter2</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.ui.webapp.AuthenticationProce ssingFilter</param-value>
</init-param>
</filter>

<filter>
<filter-name>Acegi HTTP Request Security Filter2</filter-name>
<filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
<init-param>
<param-name>targetClass</param-name>
<param-value>net.sf.acegisecurity.intercept.web.SecurityEnforce mentFilter</param-value>
</init-param>
</filter>

<!-- filter mappings -->
<filter-mapping>
<filter-name>Acegi Authentication Processing Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>Acegi Authentication Processing Filter2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>Acegi Security System for Spring Auto Integration Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>Acegi HTTP Request Security Filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

<filter-mapping>
<filter-name>Acegi HTTP Request Security Filter2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
[/code]

[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.AuthenticationE ntryPoint#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(AbstractProcessingFi lter.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.AuthenticationProce ssingFilter">
<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.AuthenticationProce ssingFilter">
<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.DaoAuthenticati onProvider
[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.AuthenticationCredentialsNotF oundException: Authentication
credentials were not found in the SecureContext
at net.sf.acegisecurity.intercept.AbstractSecurityInt erceptor.intercepto
r(AbstractSecurityInterceptor.java:289)
at net.sf.acegisecurity.intercept.web.FilterSecurityI nterceptor.invoke(F
ilterSecurityInterceptor.java:78)
at net.sf.acegisecurity.intercept.web.SecurityEnforce mentFilter.doFilter
(SecurityEnforcementFilter.java:165)
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilt er(FilterToBeanProx
y.java:88)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationF
ilterChain.java:193)
at net.sf.acegisecurity.ui.AbstractIntegrationFilter. doFilter(AbstractIn
tegrationFilter.java:170)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationF
ilterChain.java:193)
at net.sf.acegisecurity.ui.AbstractProcessingFilter.d oFilter(AbstractPro
cessingFilter.java:368)
at net.sf.acegisecurity.util.FilterToBeanProxy.doFilt er(FilterToBeanProx
y.java:88)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationF
ilterChain.java:193)
at org.displaytag.filter.ResponseOverrideFilter.doFil ter(ResponseOverrid
eFilter.java:88)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationF
ilterChain.java:193)
at org.appfuse.webapp.filter.GZIPFilter.doFilter(GZIP Filter.java:51)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(Appl
icationFilterChain.java:213)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationF
ilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperV
alve.java:256)
at org.apache.catalina.core.StandardPipeline$Standard PipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(S tandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(Cont ainerBase.java:995)

at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextV
alve.java:191)
at org.apache.catalina.core.StandardPipeline$Standard PipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(S tandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(Cont ainerBase.java:995)

at org.apache.catalina.core.StandardContext.invoke(St andardContext.java:
2415)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.j
ava:180)
at org.apache.catalina.core.StandardPipeline$Standard PipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.valves.ErrorDispatcherValve.in voke(ErrorDispatche
rValve.java:171)
at org.apache.catalina.core.StandardPipeline$Standard PipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.j
ava:172)
at org.apache.catalina.core.StandardPipeline$Standard PipelineValveContex
t.invokeNext(StandardPipeline.java:641)
at org.apache.catalina.core.StandardPipeline.invoke(S tandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(Cont ainerBase.java:995)

at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineVal
ve.java:174)
at org.apache.catalina.core.StandardPipeline$Standard PipelineValveContex
t.invokeNext(StandardPipeline.java:643)
at org.apache.catalina.core.StandardPipeline.invoke(S tandardPipeline.jav
a:480)
at org.apache.catalina.core.ContainerBase.invoke(Cont ainerBase.java:995)

at org.apache.coyote.tomcat4.CoyoteAdapter.service(Co yoteAdapter.java:22
3)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java
:594)
at org.apache.coyote.http11.Http11Protocol$Http11Conn ectionHandler.proce
ssConnection(Http11Protocol.java:392)
at org.apache.tomcat.util.net.TcpWorkerThread.runIt(P oolTcpEndpoint.java
:565)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.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.