Subject: Clustering CAS tutorial in CAS User Manual - msg#00131

Previous Message by Date: click to view message preview

Re: Invalid Service Response

Scott Battaglia wrote: > Bob, > > It looks like it tried to make a proxy granting ticket for > https://drupal.uoregon.edu/ but was unable to (adding logging for the > HttpBasedAuthenticationHandler might narrow down the reason. > > -Scott > > On 10/4/07, Bob Rotsted <rrotsted-C0Jp+pLGbMOVc3sceRu5cw@xxxxxxxxxxxxxxxx> > wrote: >> Hi all, >> I am using Tomcat behind Apache with Apache2::AuthCAS for my services. >> As I understand it, in order to get CAS to authenticate correctly I must >> first import my CAS server's SSL certificate into the java keystore. As >> of now, I have imported my public ssl key into the java keystore with >> alias 'tomcat' yet I am still getting a "Invalid Service Response" >> error. This is what shows up in my cas.log when I try to authenticate: >> >> 2007-10-04 11:45:03,676 INFO >> [org.jasig.cas.authentication.AuthenticationManagerImpl] - >> AuthenticationHandler: >> >> org.jasig.cas.adaptors.radius.authentication.handler.support.RadiusAuthenticationHandler >> successfully authenticated the user which provided the following >> credentials: rrotsted >> 2007-10-04 11:45:03,677 INFO >> [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service >> ticket [ST-5-GItdoxQZzuUR0PTfhhO3wy6FZzGXuesRA61-20] for service >> [https://drupal.uoregon.edu] for user [rrotsted] >> 2007-10-04 11:45:03,731 INFO >> [org.jasig.cas.authentication.AuthenticationManagerImpl] - >> AuthenticationHandler: >> >> org.jasig.cas.authentication.handler.support.HttpBasedServiceCredentialsAuthenticationHandler >> failed to authenticate the user which provided the following >> credentials: https://drupal.uoregon.edu/ >> 2007-10-04 11:45:03,732 ERROR >> [org.jasig.cas.web.ServiceValidateController] - TicketException >> generating ticket for: https://drupal.uoregon.edu/ >> org.jasig.cas.ticket.TicketCreationException: >> error.authentication.credentials.bad >> at >> >> org.jasig.cas.CentralAuthenticationServiceImpl.delegateTicketGrantingTicket >> (CentralAuthenticationServiceImpl.java:271) >> at >> org.jasig.cas.web.ServiceValidateController.handleRequestInternal( >> ServiceValidateController.java:124) >> at >> org.springframework.web.servlet.mvc.AbstractController.handleRequest( >> AbstractController.java:153) >> at >> org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle( >> SimpleControllerHandlerAdapter.java:48) >> at >> org.springframework.web.servlet.DispatcherServlet.doDispatch( >> DispatcherServlet.java:857) >> at >> org.springframework.web.servlet.DispatcherServlet.doService( >> DispatcherServlet.java:792) >> at >> org.springframework.web.servlet.FrameworkServlet.processRequest( >> FrameworkServlet.java:475) >> at >> org.springframework.web.servlet.FrameworkServlet.doGet( >> FrameworkServlet.java:430) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) >> at >> org.jasig.cas.web.init.SafeDispatcherServlet.service( >> SafeDispatcherServlet.java:115) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter( >> ApplicationFilterChain.java:269) >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter( >> ApplicationFilterChain.java:188) >> at >> org.apache.catalina.core.StandardWrapperValve.invoke( >> StandardWrapperValve.java:213) >> at >> org.apache.catalina.core.StandardContextValve.invoke( >> StandardContextValve.java:174) >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java >> :127) >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java >> :117) >> at >> org.apache.catalina.core.StandardEngineValve.invoke( >> StandardEngineValve.java:108) >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java >> :151) >> at >> org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) >> at >> org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283) >> at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java >> :773) >> at >> org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java >> :703) >> at >> org.apache.jk.common.ChannelSocket$SocketConnection.runIt( >> ChannelSocket.java:895) >> at >> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run( >> ThreadPool.java:689) >> at java.lang.Thread.run(Thread.java:619) >> Caused by: error.authentication.credentials.bad >> at >> org.jasig.cas.authentication.handler.BadCredentialsAuthenticationException >> .<clinit>(BadCredentialsAuthenticationException.java:25) >> at >> org.jasig.cas.authentication.AuthenticationManagerImpl.authenticate( >> AuthenticationManagerImpl.java:108) >> at >> org.jasig.cas.CentralAuthenticationServiceImpl.createTicketGrantingTicket( >> CentralAuthenticationServiceImpl.java:383) >> at >> org.jasig.cas.web.flow.AuthenticationViaFormAction.submit( >> AuthenticationViaFormAction.java:107) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java >> :39) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke( >> DelegatingMethodAccessorImpl.java:25) >> at java.lang.reflect.Method.invoke(Method.java:597) >> at >> org.springframework.webflow.util.DispatchMethodInvoker.invoke( >> DispatchMethodInvoker.java:103) >> at >> org.springframework.webflow.action.MultiAction.doExecute(MultiAction.java >> :136) >> at >> org.springframework.webflow.action.AbstractAction.execute( >> AbstractAction.java:203) >> at >> org.springframework.webflow.engine.AnnotatedAction.execute( >> AnnotatedAction.java:142) >> at >> org.springframework.webflow.engine.ActionExecutor.execute( >> ActionExecutor.java:61) >> at >> org.springframework.webflow.engine.ActionState.doEnter(ActionState.java >> :180) >> at org.springframework.webflow.engine.State.enter(State.java:200) >> at >> org.springframework.webflow.engine.Transition.execute(Transition.java:229) >> at >> org.springframework.webflow.engine.TransitionableState.onEvent( >> TransitionableState.java:112) >> at org.springframework.webflow.engine.Flow.onEvent(Flow.java:572) >> at >> >> org.springframework.webflow.engine.impl.RequestControlContextImpl.signalEvent >> (RequestControlContextImpl.java:208) >> at >> org.springframework.webflow.engine.ActionState.doEnter(ActionState.java >> :185) >> at org.springframework.webflow.engine.State.enter(State.java:200) >> at >> org.springframework.webflow.engine.Transition.execute(Transition.java:229) >> at >> org.springframework.webflow.engine.TransitionableState.onEvent( >> TransitionableState.java:112) >> at org.springframework.webflow.engine.Flow.onEvent(Flow.java:572) >> at >> >> org.springframework.webflow.engine.impl.RequestControlContextImpl.signalEvent >> (RequestControlContextImpl.java:208) >> at >> org.springframework.webflow.engine.impl.FlowExecutionImpl.signalEvent( >> FlowExecutionImpl.java:214) >> at >> org.springframework.webflow.executor.FlowExecutorImpl.resume( >> FlowExecutorImpl.java:245) >> at >> >> org.springframework.webflow.executor.support.FlowRequestHandler.handleFlowRequest >> (FlowRequestHandler.java:115) >> at >> >> org.springframework.webflow.executor.mvc.FlowController.handleRequestInternal >> (FlowController.java:172) >> at >> org.springframework.web.servlet.mvc.AbstractController.handleRequest( >> AbstractController.java:153) >> at >> org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle( >> SimpleControllerHandlerAdapter.java:48) >> at >> org.springframework.web.servlet.DispatcherServlet.doDispatch( >> DispatcherServlet.java:857) >> at >> org.springframework.web.servlet.DispatcherServlet.doService( >> DispatcherServlet.java:792) >> at >> org.springframework.web.servlet.FrameworkServlet.processRequest( >> FrameworkServlet.java:475) >> at >> org.springframework.web.servlet.FrameworkServlet.doPost( >> FrameworkServlet.java:440) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) >> ... 17 more >> >> Any suggestions would be greatly appreciated! >> >> Thanks, >> Bob Rotsted >> _______________________________________________ >> Yale CAS mailing list >> cas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxx >> http://tp.its.yale.edu/mailman/listinfo/cas >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Yale CAS mailing list > cas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxx > http://tp.its.yale.edu/mailman/listinfo/cas Scott- After turning up logging for the HttpBasedServiceCredentialsAuthenticationHandler on my CAS server, I was unable to further diagnose the problem. I did however notice an error from my AuthCAS service's log file. It appears that the service is unable to validate service tickets. Any suggestions? [Mon Oct 08 09:57:57 2007] [alert] [client 128.223.61.74] CAS(7104): setHeader: Setting header: Location = https://slam.uoregon.edu/cas/error/?login_url=https://slam.uoregon.edu: 443/cas/login?service=https%3A%2F%2Fdrupal.uoregon.edu%2Fuser&errcode=Invalid Service Response, referer: https://slam.uoregon.edu/cas/login?service=https%3A%2F%2Fdrupal.uoregon.e du%2Fuser [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: Apache Config: [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: DbDataSource => sid=cas;host=localhost;port=3306 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: DbDriver => mysql [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: DbPass => ****** [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: DbSessionTable => cas_sessions [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: DbUser => cas [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: ErrorUrl => https://slam.uoregon.edu/cas/error/ [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: Host => slam.uoregon.edu [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: LogLevel => 4 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: LoginUri => /cas/login [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: LogoutUri => /cas/logout [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: NumProxyTickets => 1 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: Port => 443 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: PretendBasicAuth => undef [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: ProxyService => false [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: ProxyUri => /cas/proxy [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: ProxyValidateUri => /cas/proxyValidate [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: RemoveTicket => 546548 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: Service => https://drupal.uoregon.edu/user [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: ServiceValidateUri => /cas/serviceValidate [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: SessionCookieDomain => undef [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: SessionCookieName => APACHECAS [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): getApacheConfig: SessionTimeout => 1800 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): cleanup: counter=1 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): delete_expired_sessions: deleting sessions older than '1191835704' [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): delete_expired_sessions: error deleting expired sessions [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): authenticate: authenticated='' [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): parse_query_parameters: PARAM: 'ticket' => 'ST-3-spLH0qDZlrwr2FTgO9nbY5FHJVwrB12i7IR-20' [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): authenticate: cookie found: '__utma=32862522.1333826686.1189012244.1189012244.1189012244.1; __utmz=32862522.1 189012244.1.1.utmccn=(organic)|utmcsr=google|utmctr=microcomputer+services|utmcmd=organic; PHPSESSID=625f1c99702ad93d9488a5c5a14c6b8b' [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): authenticate: no session id found [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): validate_service_ticket: Validating service ticket 'ST-3-spLH0qDZlrwr2FTgO9nbY5FHJVwrB12i7IR-20' for service 'https%3A%2F%2Fdrupal.uoregon.edu%2Fuser' [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): validate_service_ticket: request URL: '/cas/proxyValidate?pgtUrl=https://drupal.uoregon.edu/user&service=http s%3A%2F%2Fdrupal.uoregon.edu%2Fuser&ticket=ST-3-spLH0qDZlrwr2FTgO9nbY5FHJVwrB12i7IR-20' [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): validate_service_ticket: response page: [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): validate_service_ticket: invalid service response [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): redirect: redirecting to url: 'https://slam.uoregon.edu/cas/error/' service: 'https%3A%2F%2Fdrupal.uoregon.ed u%2Fuser' [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): setHeader: Setting header: CAS_FILTER_CAS_HOST = slam.uoregon.edu [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): setHeader: Setting header: CAS_FILTER_CAS_PORT = 443 [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): setHeader: Setting header: CAS_FILTER_CAS_LOGIN_URI = /cas/login [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): setHeader: Setting header: CAS_FILTER_SERVICE = https%3A%2F%2Fdrupal.uoregon.edu%2Fuser [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): redirect: redirecting to error page [Mon Oct 08 09:58:24 2007] [alert] [client 128.223.61.74] CAS(7106): setHeader: Setting header: Location = https://slam.uoregon.edu/cas/error/?login_url=https://slam.uoregon.edu: 443/cas/login?service=https%3A%2F%2Fdrupal.uoregon.edu%2Fuser&errcode=Invalid Service Response

Next Message by Date: click to view message preview

Re: Service Registry in LDAP...

Hi Scott,As I am diving into this more, I had another thought:We use a load-balanced CAS server (two instances at the moment), and if we put the Service Registry in a db or LDAP, how do we tell the other instance(s) of CAS to reload new or changed data?Thanks.-lucasOn Sep 28, 2007, at 9:57 AM, Scott Battaglia wrote:On 9/28/07, Lucas Rockwell <lucasrockwell-TVLZxgkOlNX2fBVCVOL8/A@xxxxxxxxxxxxxxxx> wrote: Scott,As always, thanks for the information. So questions below.On Sep 28, 2007, at 5:02 AM, Scott Battaglia wrote: Lucas,Here's a quick description of the services package:ServiceRegistryManager is the interface for the service layer.  It has a default implementation of DefaultServiceManagerImpl. Does "manager" in this case mean it manages the services for both the CAS server (logins and validation) and for the registry management console? I assume both things interact with this service layer. The manager is the service layer that interacts with both the Authentication/Validation component (i.e. the CentralAuthenticationService) and the Services Management Interface. Let me know if you have other questions or comments.Hope that helps.-Scott DefaultServiceManagerImpl also implements ReloadableServiceManager.  The implementation caches values returned from the Repository for improved performance and can be reloaded occasionally via the exposed ReloadableServiceManager method.  RegisteredServiceImpl is the default implementation of the RegisteredService.  Even if you are using another backend data store, you should be able to use this implementation.ServiceRegistryDao controls the interaction between the data store and the service layer.  This is the layer that would communicate with LDAP. The RegisteredService interface should contain the list of attributes that would need to be stored in the LDAP.If you get this working, please consider creating a JIRA issue and donating the code to the CAS project!  Let me know if you need more information.  I certainly will. Perhaps Mike Kennedy and I can come up with something, as I think we're thinking along the same lines with this. -lucasThanks-ScottOn 9/27/07, Lucas Rockwell < lucasrockwell-TVLZxgkOlNX2fBVCVOL8/A@xxxxxxxxxxxxxxxx> wrote: Hi all,I would like to put the Service Registry information in our LDAP server, but I am feeling a little lost.I see this page http://www.ja-sig.org/wiki/display/CASUM/Configuring for configuring the backend as a database, but I don't think it is asstraight-forward for ldap, especially since we don't let applicationsjust create new schema objects on the fly (as it looks like that is what the Hibernate code is doing for a database).It looks like InMemoryServiceRegistryDaoImpl just implementsServiceRegistryDao, but even looking at those two things and all theother classes in that package do not give me a clear picture about how to do this with ldap.Also, there is CAS itself that has to interact with the Registry, aswell as the management "console", but perhaps all of that is done viathe one "serviceRegistryDao" bean in applicationContext.xml...Any pointers to get me started would be great.Of course, I'll gladly put the solution on the wiki.Thanks!-lucas_______________________________________________ Yale CAS mailing listcas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxx http://tp.its.yale.edu/mailman/listinfo/cas -- -Scott BattagliaLinkedIn: http://www.linkedin.com/in/scottbattaglia_______________________________________________Yale CAS mailing list cas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxx http://tp.its.yale.edu/mailman/listinfo/cas _______________________________________________Yale CAS mailing list cas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxxhttp://tp.its.yale.edu/mailman/listinfo/cas -- -Scott BattagliaLinkedIn: http://www.linkedin.com/in/scottbattaglia_______________________________________________Yale CAS mailing listcas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxxhttp://tp.its.yale.edu/mailman/listinfo/cas

Previous Message by Thread: click to view message preview

CAS JBoss log4j hell

This is a multi-part message in MIME format. Hello, Perhaps someone can steer me in the right direction. I’m trying to get cas to use JBoss log4j rather than its own. I’ve removed the log4j listener from web.xml and removed log4j.properties from the cas webapp. I also added an appender/category filter to $JBOSS_HOME/server/default/conf/log4j.xml for CAS. It seems now that the problems I’m having are due to the fact that when maven builds cas.war it includes a log4j.jar in the build creating a conflict. I want CAS to use the log4j.jar that comes with JBoss.   I’ve tried adding exclusions for this throughout the pom.xml in the cas-server-webapp module to no avail. Can anyone tell me what dependency is causing log4j to be added? Am I even going about this in the right way?   Mike

Next Message by Thread: click to view message preview

Re: Clustering CAS tutorial in CAS User Manual

Adam,While the existing Clustering CAS document is an excellent resource for those wishing to deploy multiple CAS instances, in certain instances it doesn't provide an appropriate level of detail on security risks. I encourage you to add warnings where you believe appropriate, attempting to generalize them.  For instance when configuring a TicketRegistry it may be appropriate to warn merely about the risks in deploying multiple CAS instances across a public network without encrypting (or using a secure channel to transmit) the data stored in the ticket registry. You also asked about the Tomcat Session replication.  CAS by default stores nothing in session except the name of the service and any state information required by Spring Web Flow.  However, it may be good to make a note that while CAS does not store any sensitive information in the Tomcat Session, one should take care in supplementing the CAS state with additional information of a sensitive nature if deploying Tomcat clustering across an untrusted network. Thanks!-ScottOn 10/9/07, Adam Rybicki <arybicki-CMmZ9rwbF3asTnJN9+BGXg@xxxxxxxxxxxxxxxx> wrote: All, I just read the security warning that Andrew added to this excellent tutorial.  I was thinking of adding one more warning like that, but in the section that describes how to replicate the ticket registry using JBossCache.  That's because the instructions are about using multicast to synchronize the ticket registries across the network.  This is not likely to be a problem for CAS clusters of servers sitting next to each other in the same data center.  However, if one of the goals of clustering is to achieve high availability, which it often is, then implementers will consider locating CAS cluster servers in different physical locations.  In these situations, additional care must me taken to assure that secure data does not "leak" into the public network. This potential issue is not unique to using multicast.  Using database-based ticket registry could be subject to similar risks.  Those risks may be smaller, IMHO, but they exist.  Using encryption when talking to a database might be an option. Based on some other postings in this list, I think that CAS does not use the HttpSession to store any secure information.  This would mean that the section of the tutorial titled "Tomcat Session Replication" may be fine even though it also uses multicast. So, my question is: should I add that warning to the Clustering CAS tutorial? Thanks, Adam _______________________________________________Yale CAS mailing listcas-c5E7yoNEsvRIM2btvs0Z1A@xxxxxxxxxxxxxxxx http://tp.its.yale.edu/mailman/listinfo/cas-- -Scott BattagliaLinkedIn: http://www.linkedin.com/in/scottbattaglia