"Gustavo Fernandes":https://jira.spring.io/secure/ViewProfile.jspa?name=phlox said:
I am using CAS provider with a httpinvoker based swing client, that sends _cas_stateless as username and a ST as password (obtained directly from CAS). In the server side I use two filters: httpsessionintegrationFilter and basicProcessingFilter.
In the first time the basicProcessingFilter validates the ticket against CAS, and the sessionIntegration filter puts the autentication in the session, as desired.
The next time, the client sends the same jsessionId, the httpsessionintegrationfilter corretly extracts the context from the previously created session but basic processing filter tries to autenticate again (validade CAS ST AGAIN).
The line 138 of the class BasicProcessingFilter, it checks if it need to reauthenticate by checking (among other things) if the existingAuth´s username (obtained from session) is equals to the username that came from the HTTP Header. If they are not equal, the filter tries to reauthenticate. Since http header´s username is always equals to "cas_stateless" and existingAuth´s username is equals to the auhtenticated user, they are never the same, and the basicprocessingfilter will try to validade the ticket again. The correct behaviour would be to just revalidate the ticket when the session does not carry a valid authentication anymore.
Comment From: spring-projects-issues
["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] said:
I suspect there is a misconfiguration or misunderstanding here. With remoting protocols in general, you don't get access to the HttpSession. This is because most remoting protocols cannot present the assigned jsessionid. We therefore recommend setting HttpSessionContextIntegrationFilter.allowSessionCreation = false (defaults to true).
The CasAuthenticationProvider should not go back to the CAS server and re-present the same service ticket. It seems you have a misconfiguration, such as a missing StatelessTicketCache.
More information can be found at http://www.acegisecurity.org/docbook/acegi.html#cas-advanced.
I will reassign this issue to 1.0.3, as I do not believe there is a bug here.
Comment From: spring-projects-issues
["Gustavo Fernandes":https://jira.spring.io/secure/ViewProfile.jspa?name=phlox] said:
Spring Framework's HttpInvoker using Commons HttpClient as its request executor is perfectly capable of handlink cookies and therefore can present the same jsessionid or whatever.
Relying on StatelessTicketCache is problematic when using a cluster: every JVM has its own cache. Even if using a distributed cache suchs as JBossCache, there are another problems suchs as replication and classloader issues.
Comment From: spring-projects-issues
["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] said:
SEC-53 was the original avoidance of reauthentication approach.
Comment From: spring-projects-issues
["Ben Alex":https://jira.spring.io/secure/ViewProfile.jspa?name=balex] said:
Modified BasicProcessingFilter so its logic that governs whether an authentication is reattempted will only consider username equality in the event the UsernamePasswordAuthenticationToken is provided. This will mean tokens such as CasAuthenticationToken (which CasAuthenticationProvider returns) will skip the reauthentication check if they are in the SecurityContextHolder and are marked as authenticated (which they will be). Code:
if ((existingAuth == null)
|| (existingAuth instanceof UsernamePasswordAuthenticationToken && !existingAuth.getName().equals(username))
|| !existingAuth.isAuthenticated()) { /* reauthenticate * }
This should provide compatibility with using BasicProcessingFilter with the CAS identifier in a cluster that relies on HttpSession replication.
Checked into SVN.
Would you please confirm this works in your deployment environment as expected by adding a comment to this issue. Thanks.
Comment From: spring-projects-issues
This issue depends on #301