No conversation state found in session

[unicon]

No conversation state found in session

[mmoayyed]

Why do you start with?
http://shibboleth_idp_server:8080/idp/profile/cas/login?service=http://whatever_url.com

Aren't you delegating authentication to an external CAS server? If so, why are using IdP's CAS endpoint for a start?

[mmoayyed]

Also, running the idp under 8080 may impose issues in the future.

You should start from your SP.

[C4n4rd0]

I start with http://shibboleth_idp_server:8080/idp/profile/cas/login?service=http://whatever_url.com beacause I didn't know what URL to use. So I looked at the web.xml, I found this address and it starts the flow. So, I assumed it's the good URL. But it seems it's not. Right?

I don't really need Shibboleth. The only thing I want, is the SAML 2.0 support for my CAS server. So, the less software I have to install, the better I am. That's why I did'nt installed the Shibboleth SP. What kind of issues, running the idp under 8080 may appears? Isn't it a classic war? Should I run it behind a http server?

A conversation is a spring flow object. When I looked at the stack trace, an exception is thrown in the method ShibcasAuthServlet.doGet() when it calls ExternalAuthentication.startExternalAuthentication(request).
After reading the code of the method ExternalAuthentication.startExternalAuthentication(), it seems that the conversation id is not setted in the session

final Object obj = request.getSession().getAttribute(CONVERSATION_KEY + conv);
if (obj == null || !(obj instanceof ExternalAuthentication)) {
throw new ExternalAuthenticationException("No conversation state found in session");
}

[C4n4rd0]

But I can't see where the plugin do some kind of getSession().setAttribute(CONVERSATION_KEY + conv,obj);

[iigorr]

Hi,

have you been able this issue? We are having exactly the same problem after switching from shibboleth 3.2.0.

After a successful redirect to our CAS and login, on the way back, we are getting the exception:

24-Nov-2015 07:12:29.225 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log SessionListener: contextInitialized()
24-Nov-2015 07:13:33.216 SEVERE [http-nio-8443-exec-7] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [ShibCas Auth Servlet] in context with path [/idp] threw exception [Error processing ShibCas authentication request] with root cause
 net.shibboleth.idp.authn.ExternalAuthenticationException: No conversation state found in session for key (e1s1)
    at net.shibboleth.idp.authn.ExternalAuthentication.startExternalAuthentication(ExternalAuthentication.java:132)
    at net.unicon.idp.externalauth.ShibcasAuthServlet.doGet(ShibcasAuthServlet.java:113)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:618)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at net.shibboleth.idp.log.SLF4JMDCServletFilter.doFilter(SLF4JMDCServletFilter.java:72)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at net.shibboleth.utilities.java.support.net.RequestResponseContextFilter.doFilter(RequestResponseContextFilter.java:60)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)
    at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:203)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
    at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1085)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
    at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1556)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1513)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:745)

What's wrong here?

[C4n4rd0]

Yes I did. It was a cookie issue.

The domain of my cookies was .test.mycompany.com but I was redirected to http://shibboleth_idp_server:8080. It can't work.

To solve this, I had to redirect to http://shibboleth_idp_server.test.mycompany.com:8080

[siwilkins]

We are getting a lot of occurrences of this error, particularly integrating Google Apps with our Shibboleth/CAS instance. Our Google Apps session lifetime is set to 12h, and so we think the typical pattern occurs when users leave their machine on and their Google session times-out in the evening, resulting in a redirection to the IDP and in turn CAS; they then come in the next morning, sign-in to CAS and get the error. We've mitigated it slightly by setting the tomcat session.lifetime to 24h, but a) are still getting a lot of occurrences (1000s/day; we're a university so have a lot of users); b) are struggling to control the heap size.

a) is there any better way of mitigating this scenario?
b) one possibility we have thought of, is that if the original service could be passed as an extra GET parameter in the service name to CAS, then on the return journey from CAS our load balancer could pick this up on the IDP when there's a 500 error on the IDP, and redirect back to the service, forcing a second round-trip to the IDP and CAS, thereby successfully logging the user in and avoiding the user ever seeing the error. Is this possible?

[jtgasper3]

Hi Si,

The issue is that the authnRequest is stored in the Shibboleth IdP's web/tomcat session. When that ends, because the person sat on the CAS Server's login page too long, when the user does come back the IdP doesn't know what to do with them. It's forgotten. Bumping up the session length is the common fix that a few of our clients have done.

As for scenario b, the entityId is sent to CAS Server either as a part of the service url or as a standalone querystring parameter. Either way, sending that back to the IdP doesn't really help. The IdP does not know the invocation url of the SP, it only can determine the ACS url to send the response. If we sent the user to that ACS url with no authnResponse, they are most likely to get error messages on that side.

[siwilkins]

Hi John. Thanks very much for your response. That's a shame. We've upp'ed the tomcat timeout to 24h, but still get lots of occurrences, and are now ending up with the heap usage spiralling out of control. We've upped it a few times after the heaps been exhausted, so maybe we just need to increase the tomcat session some more and the heap lots more :-)