I am having the same issue but I do not have a clustered environment. I have a single CAS server running in GF
[#|2011-04-07T15:06:32.483-0400|INFO|glassfish3.0.1|org.hibernate.validator.engine.resolver.DefaultTraversableResolver|_ThreadID=54;_ThreadName=Thread-1;|Instantiated an instance of org.hibernate.validator.engine.resolver.JPATraversableResolver.|#] [#|2011-04-07T15:06:32.491-0400|WARNING|glassfish3.0.1|javax.enterprise.system.container.web.com.sun.enterprise.web|_ThreadID=54;_ThreadName=Thread-1;|StandardWrapperValve[cas]: PWC1406: Servlet.service() for servlet cas threw exception java.lang.RuntimeException: javax.crypto.BadPaddingException: Given final block not properly padded at org.jasig.cas.web.flow.CasFlowExecutionKeyFactory.decrypt(CasFlowExecutionKeyFactory.java:92) at org.jasig.cas.web.flow.CasFlowExecutionKeyFactory.parseFlowExecutionKey(CasFlowExecutionKeyFactory.java:168) at org.springframework.webflow.executor.FlowExecutorImpl.resumeExecution(FlowExecutorImpl.java:164) at org.springframework.webflow.mvc.servlet.FlowHandlerAdapter.handle(FlowHandlerAdapter.java:183) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:790) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:719) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:644) at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:560) at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) at org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody2(SafeDispatcherServlet.java:115) at org.jasig.cas.web.init.SafeDispatcherServlet.service_aroundBody3$advice(SafeDispatcherServlet.java:44) at org.jasig.cas.web.init.SafeDispatcherServlet.service(SafeDispatcherServlet.java:1) at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:343) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at com.github.inspektr.common.web.ClientInfoThreadLocalFilter.doFilter(ClientInfoThreadLocalFilter.java:63) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:237) at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:167) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:256) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:215) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:277) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641) at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97) at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185) at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:325) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:226) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:229) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:334) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:814) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:936) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:682) at java.lang.Thread.run(Thread.java:662) Caused by: javax.crypto.BadPaddingException: Given final block not properly padded at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.SunJCE_f.b(DashoA13*..) at com.sun.crypto.provider.AESCipher.engineDoFinal(DashoA13*..) at javax.crypto.Cipher.doFinal(DashoA13*..) at org.jasig.cas.web.flow.CasFlowExecutionKeyFactory.decrypt(CasFlowExecutionKeyFactory.java:90) ... 39 more Have you guys figured out why this would be happening? I just upgraded from 3.3.5. thanks Ismail On Apr 7, 2011, at 3:03 PM, Scott Battaglia wrote: You are missing the point. Web flow parses the passed in value and looks up the flow. The default value follows an easily guessable format allowing for scripting login. Encrypting it with a random value makes the result unguessable but still reversible to web flow. This means you can't script the flow but web flow still functions correctly. Hashes won't work since we need the value back. Uuid on its own won't work since it doesn't have the value needed. Web flow doesn't store the uuid anywhere to my knowledge so doing it unencrypted doesn't provide protection. Hopefully that is a better explanation. If you don't want the added protection you can disable the behavior. On Apr 7, 2011 11:55 AM, "Jon Oler" <[email protected]<mailto:[email protected]>> wrote: > On Thu, Apr 7, 2011 at 12:14 PM, Scott Battaglia > <[email protected]<mailto:[email protected]>>wrote: > >> Yes the CAS protocol requirement is to be unguessable. >> > A random uuid is unguessable, so the concatenation of a random uuid plus > some spring webflow details is also unguessable--before encrypting it. > >> Web Flow requires a guessable parsable string with particular values. >> > Web Flow is getting its guessable string off the end of the unguessable > string that we're using. The whole unguessable string has to be passed > together as a single unit to the CAS server to be of any use (is this > correct?). In my mind, that is the key to this discussion. If there are > any exploits available to people by knowing the SWF execution id and/or > snapshot id in isolation (which makes them capable of doing more than they > could with the entire login ticket value itself), then that might be an > issue. For example, the CAS protocol document states that users can't be > allowed to attempt to login multiple times using the same Login Ticket. > Just because the SWF id values can be guessed, doesn't mean that a new > Login Ticket value can be guessed because the random uuid prefix is > unguessable. > >> We solve both by attaching a random string in front of the guessable part >> and encrypting it. The uuid part is useless. Web Flow only cares about the >> second part. But if you just encrypted the existing web flow key it would >> always be the same value. >> > If the SWF execution id and/or snapshot id can be exploited in isolation in > ways that the Login Ticket cannot, then there may be an issue. > Otherwise, I'm not seeing the problem. Adding a guessable value to an > unguessable one is still unguessable. > > Thanks, > > --Jon > > -- > You are currently subscribed to > [email protected]<mailto:[email protected]> as: > [email protected]<mailto:[email protected]> > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected]<mailto:[email protected]> as: [email protected]<mailto:[email protected]> To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
