Hmm. This thread is really about the fact that CAS 3.4.7 introduced a new symmetric key that is created each time the CAS server is started that is used to encrypt/decrypt the CAS login ticket. This causes a problem in a clustered environment because the servers end up having different keys and if the same server doesn't end up doing both the encrypt and decrypt of the login ticket, things don't work because the servers are using different symmetric keys. When there is a single server this shouldn't happen because obviously that server's key is the same for all CAS requests. The only thing I can think of is that if you bring up the CAS login page, restart the CAS server, then attempt to login to CAS, you may end up with this exception because the CAS page will have a login ticket encrypted by the server's original key, but that key will be regenerated on CAS server restart, and the decrypt will fail when you try to login. If that's not your problem, you may want to consider starting a new thread, as you may be having a different issue than this.
Thanks, --Jon On Thu, Apr 7, 2011 at 1:54 PM, Seyfi, Ismail < [email protected]> wrote: > 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]> wrote: > > On Thu, Apr 7, 2011 at 12:14 PM, Scott Battaglia > > <[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] as: > [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 > > > -- > 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 > > -- 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
