No conversation state found

Tue Dec 15 23:06:18 EST 2015

Bryan,

I think the general ideas definitely have their place in the world. I 
don't know that I would limit my thinking here to 500 errors and load 
balancers only, though; instead I think of this more as the general 
problem space of [reverse] proxies and gateways and other intermediaries 
that do various things to make life easier on the applications behind 
them.  Catching 500 errors is a great example; occasionally serving as a 
SAML SP for a cluster of applications that all want to "look like one" 
would be another, both so the applications don't have to think about it, 
and so the identity provider[s] don't have to think about it.

There's definitely potential value here in the ability to offer greater 
uptime and less effort to application developers.  But, I have one real 
complaint about the architectural style.  It has little to do with the 
architecture itself or using it only to pretty up 500 pages; it's 
entirely to do with the loss of visibility into what's happening 
end-to-end with a sufficient level of resolution.

Sometimes you can mostly make up for this with monitoring systems and 
excellent documentation of exactly what was built, especially if it's 
all within your own domain.  Sometimes you're dealing with an external 
entity, and looking like an opaque blob is exactly what they would like 
-- and it's all you're going to get.

This is why I focused on getting the _identity data_ that powers these 
transactions to be as distributed and visible as possible in my dogma.  
If you have that diaphanous overlay of vision into what should be 
happening, you're likely to discover distinctions that you can make 
optionally visible to counterparties(you can just release to "My Library 
Services SP" or we can go into gory detail; your call, Mr. IdP).  Many 
of them will smell like the one you've identified.

At that point, a lot of my qualms about centralizing the _processing_ of 
these transactions go away because it's no longer a forcible 
requirement, but instead an option that is available.  It's a 
consideration that's obviously much less important in the 500 squelching 
use case, but I think this is a broad enough solution to think about 
what other problems it might solve or introduce.

If that identity data layer gets built, then important information is no 
longer forcibly destroyed.  It's just that the details of the 
implementation become more ignorable if you so choose, and you get to 
focus on where data goes and why rather than the mechanical how. We're a 
long way from such a world, but it's where I would love to get.

Hope this helps you further your thoughts,
Nate.

On 12/15/2015 05:59 PM, Bryan Wooten wrote:
> Ok, this is my rant on this.
>
> Http 500 is an internal error, if the app (CAS and/or Shib) can¹t return a
> ³friendly² page to the user this is bad. Users should NEVER see Java stack
> traces.
>
> So, CAS and Shib aren¹t perfect, there are edge cases and 500 errors will
> or may be thrown.
>
> This is just one reason why both CAS and Shib should be behind load
> balancers like F5 or Citrix Netscaler.
>
> They can catch out bound 500 errors and present users with a friendly page
> and a helpful information like a safe link to start over.
>
> We have some apps that try and re-use CAS service tickets and then the CAS
> client errors (as it should) resulting in a 500 error. The app is
> unprepared for this. User gets a 500 error with stack dump.
>
> The load balancer should catch this and give the user a friendly page. See
> imgur.com or reddit.com when things go bad for examples of graceful 500
> errors.
>
> We have 400+ CAS/Shib apps, I can¹t control them all, but at the load
> balancer it is possible to catch the 500 and do something useful for the
> user.
>
> Just my 2 cents.
>
> On 12/15/15, 5:18 PM, "Andrew Morgan" <morgan at orst.edu> wrote:
>
>> We are testing our upgrade to IDP v3.2.0, trying to make sure all of our
>> local mods are in place.  I tried something our users frequently do -
>> bookmark our login page.
>>
>> We are using the RemoteUser auth handler to delegate IDP authentication
>> to
>> Jasig CAS.  The bookmarked login page URL is:
>>
>>    
>> https://login.oregonstate.edu/cas-dev/login?service=https%3A%2F%2Flogin.or
>> egonstate.edu%2Fidp-dev%2FAuthn%2FRemoteUser%3Fconversation%3De1s1
>>
>> When I delete all my browser cookies, go to this URL, and authenticate, I
>> am redirected to:
>>
>>    
>> https://login.oregonstate.edu/idp-dev/Authn/RemoteUser;jsessionid=67404FFE
>> 18ACB6DE59DF45B86516DFFE?conversation=e1s1
>>
>> Instead of getting a pretty error page, I get a stack trace in the
>> browser:
>>
>> HTTP Status 500 - Error processing external authentication request
>>
>> type Exception report
>>
>> message Error processing external authentication request
>>
>> description The server encountered an internal error that prevented it
> >from fulfilling this request.
>> exception
>>
>> javax.servlet.ServletException: Error processing external authentication
>> request
>>
>> 	net.shibboleth.idp.authn.impl.RemoteUserAuthServlet.service(RemoteUserAut
>> hServlet.java:303)
>> 	javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>> 	org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>>
>> 	net.shibboleth.idp.log.SLF4JMDCServletFilter.doFilter(SLF4JMDCServletFilt
>> er.java:72)
>>
>> 	net.shibboleth.utilities.java.support.net.RequestResponseContextFilter.do
>> Filter(RequestResponseContextFilter.java:60)
>>
>> 	org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(C
>> haracterEncodingFilter.java:121)
>>
>> 	org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerReque
>> stFilter.java:107)
>>
>> 	org.jasig.cas.client.util.HttpServletRequestWrapperFilter.doFilter(HttpSe
>> rvletRequestWrapperFilter.java:70)
>>
>> 	org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(A
>> bstractTicketValidationFilter.java:238)
>>
>> 	org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(Authent
>> icationFilter.java:152)
>>
>> root cause
>>
>> net.shibboleth.idp.authn.ExternalAuthenticationException: No conversation
>> state found in session for key (e1s1)
>>
>> 	net.shibboleth.idp.authn.ExternalAuthentication.startExternalAuthenticati
>> on(ExternalAuthentication.java:132)
>>
>> 	net.shibboleth.idp.authn.impl.RemoteUserAuthServlet.service(RemoteUserAut
>> hServlet.java:211)
>> 	javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>> 	org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>>
>> 	net.shibboleth.idp.log.SLF4JMDCServletFilter.doFilter(SLF4JMDCServletFilt
>> er.java:72)
>>
>> 	net.shibboleth.utilities.java.support.net.RequestResponseContextFilter.do
>> Filter(RequestResponseContextFilter.java:60)
>>
>> 	org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(C
>> haracterEncodingFilter.java:121)
>>
>> 	org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerReque
>> stFilter.java:107)
>>
>> 	org.jasig.cas.client.util.HttpServletRequestWrapperFilter.doFilter(HttpSe
>> rvletRequestWrapperFilter.java:70)
>>
>> 	org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(A
>> bstractTicketValidationFilter.java:238)
>>
>> 	org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(Authent
>> icationFilter.java:152)
>>
>> note The full stack trace of the root cause is available in the Apache
>> Tomcat/8.0.26 logs.
>>
>>
>>
>> Here is the stack trace from catalina.out:
>>
>> Dec 15, 2015 3:41:58 PM org.apache.catalina.core.StandardWrapperValve
>> invoke
>> SEVERE: Servlet.service() for servlet [RemoteUserAuthHandler] in context
>> with path [/idp-dev] threw exception [Error processing external
>> 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.startExternalAuthenticatio
>> n(ExternalAuthentication.java:132)
>>          at
>> net.shibboleth.idp.authn.impl.RemoteUserAuthServlet.service(RemoteUserAuth
>> Servlet.java:211)
>>          at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:291)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206)
>>          at
>> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:239)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206)
>>          at
>> net.shibboleth.idp.log.SLF4JMDCServletFilter.doFilter(SLF4JMDCServletFilte
>> r.java:72)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:239)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206)
>>          at
>> net.shibboleth.utilities.java.support.net.RequestResponseContextFilter.doF
>> ilter(RequestResponseContextFilter.java:60)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:239)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206)
>>          at
>> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(Ch
>> aracterEncodingFilter.java:121)
>>          at
>> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerReques
>> tFilter.java:107)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:239)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206)
>>          at
>> org.jasig.cas.client.util.HttpServletRequestWrapperFilter.doFilter(HttpSer
>> vletRequestWrapperFilter.java:70)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:239)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206)
>>          at
>> org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(Ab
>> stractTicketValidationFilter.java:238)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:239)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206)
>>          at
>> org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(Authenti
>> cationFilter.java:152)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:239)
>>          at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.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(AuthenticatorBa
>> se.java:502)
>>          at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
>> 42)
>>          at
>> com.googlecode.psiprobe.Tomcat80AgentValve.invoke(Tomcat80AgentValve.java:
>> 41)
>>          at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:7
>> 9)
>>          at
>> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLog
>> Valve.java:616)
>>          at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
>> va:88)
>>          at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:518
>> )
>>          at
>> org.apache.coyote.ajp.AbstractAjpProcessor.process(AbstractAjpProcessor.ja
>> va:844)
>>          at
>> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(Abstr
>> actProtocol.java:673)
>>          at
>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.j
>> ava:2503)
>>          at
>> org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.jav
>> a:2492)
>>          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)
>>
>>
>> Why isn't this error trapped and managed by a pretty error page?  Is
>> there
>> a way to do that?
>>
>> I think this is a common error condition our users will see, but please
>> correct me if I'm wrong!
>>
>> Thanks,
>> 	Andy
>> -- 
>> To unsubscribe from this list send an email to
>> users-unsubscribe at shibboleth.net