Re: [cas-user] Memcache Errors

[Benjamin . Audy]

Hi,

I also have the same problem in my production environment. I have CAS v4.0.4 
running in a single Tomcat instance on a Pacemaker cluster (CentOS 6), with a 
single Memcached instance running on a different node. At first I was seeing 
those error messages from time to time, then it started doing that 
systematically. I ended up disabling Memcached until I find the root cause. 
This issue did not occur on CAS v4.0.1. The Kryo library version jumped from 
v1.0.4 to v3.0.2 between those releases, so I am guessing it’s related to that 
library.

Benjamin Audy
IT Security Analyst
École de technologie supérieure

> Le 2015-10-01 à 18:38, Wickham, Jeremy  a écrit :
> 
> Yes, I shut down one node and everything works as it should. And vice versa.
>  
> I am not replicating. All of the CAS nodes write to all of the memcache 
> servers.
>  
> I will look at the timing of everything also in the logs. Also should have 
> noted, this is CAS 4.0.4.
>  
> Thanks, 
>  -Jeremy
>  
>  
> From: Ray Bon [mailto:r...@uvic.ca ] 
> Sent: Thursday, October 01, 2015 5:33 PM
> To: cas-user@lists.jasig.org 
> Subject: Re: [cas-user] Memcache Errors
>  
> Jeremy,
> 
> When you say that you 'login to one node where it does everything', have you 
> tested each node in isolation?
> Given that the 'Caused by' is unable to 'Find class', are all nodes 
> configured exactly the same?
> Assuming that the simple explanations are dealt with, I experienced similar 
> behaviour (CAS 3.5.2.1 with ehcache). 90 ms (assuming your servers are time 
> synced) between Granted service ticket and Failed fetching seems like a long 
> time but is it?
> If you can get some logging about the timing of memcached replication you 
> should have a clearer picture of the sequence of events.
> In our setup we had to move to a primary server and the others act as 
> failovers (though I am not certain our issue was with replication alone).
> 
> Ray
> 
> On 2015-10-01 14:50, Wickham, Jeremy wrote:
> Going through my motions before delivering this to my production environment 
> next week and something has crept up on me.
>  
> I am running multiple CAS nodes in my development environment to mimic what I 
> have in production. When I log in through CAS on one node and it does 
> everything (login & validate) I can get through just fine.  But if one node 
> were to log me in and the other node to validate the ticket I receive errors. 
> I have run the memcached-tool on both servers and I can read the stats of 
> each other’s stats from the opposite server. Are there any thoughts on this?
>  
> Here is the logs for the node creating the service ticket: 
> 2015-10-01 16:41:06,969 DEBUG 
> [org.jasig.cas.CentralAuthenticationServiceImpl] - Generated service ticket 
> id [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for ticket granting ticket 
> [TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02]
> 2015-10-01 16:41:06,969 DEBUG 
> [org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Updating ticket 
> TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02
> 2015-10-01 16:41:06,970 DEBUG 
> [org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Adding ticket 
> ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
> 2015-10-01 16:41:06,989 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] 
> - Granted service ticket [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for service 
> [https://luminis5-devel01.its.msstate.edu/c/portal/login 
> ] for user [jrw16]
>  
> Then here is the log for the node trying to validate the ticket.
>  
> 2015-10-01 16:41:07,079 ERROR 
> [org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Failed fetching 
> ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
> java.lang.RuntimeException: Exception waiting for value
> at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1237)
> at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1257)
> at 
> org.jasig.cas.ticket.registry.MemCacheTicketRegistry.getTicket(MemCacheTicketRegistry.java:150)
> at 
> org.jasig.cas.ticket.registry.AbstractTicketRegistry.getTicket(AbstractTicketRegistry.java:50)
> at 
> org.jasig.cas.CentralAuthenticationServiceImpl.validateServiceTicket(CentralAuthenticationServiceImpl.java:410)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
> at 
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at 
> org.springframework.aop.framework.ReflectiveMe

RE: [cas-user] Memcache Errors

[Wickham, Jeremy]

Yes, I shut down one node and everything works as it should. And vice versa.

I am not replicating. All of the CAS nodes write to all of the memcache servers.

I will look at the timing of everything also in the logs. Also should have 
noted, this is CAS 4.0.4.

Thanks,
 -Jeremy


From: Ray Bon [mailto:r...@uvic.ca]
Sent: Thursday, October 01, 2015 5:33 PM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Memcache Errors

Jeremy,

When you say that you 'login to one node where it does everything', have you 
tested each node in isolation?
Given that the 'Caused by' is unable to 'Find class', are all nodes configured 
exactly the same?
Assuming that the simple explanations are dealt with, I experienced similar 
behaviour (CAS 3.5.2.1 with ehcache). 90 ms (assuming your servers are time 
synced) between Granted service ticket and Failed fetching seems like a long 
time but is it?
If you can get some logging about the timing of memcached replication you 
should have a clearer picture of the sequence of events.
In our setup we had to move to a primary server and the others act as failovers 
(though I am not certain our issue was with replication alone).

Ray
On 2015-10-01 14:50, Wickham, Jeremy wrote:
Going through my motions before delivering this to my production environment 
next week and something has crept up on me.

I am running multiple CAS nodes in my development environment to mimic what I 
have in production. When I log in through CAS on one node and it does 
everything (login & validate) I can get through just fine.  But if one node 
were to log me in and the other node to validate the ticket I receive errors. I 
have run the memcached-tool on both servers and I can read the stats of each 
other's stats from the opposite server. Are there any thoughts on this?

Here is the logs for the node creating the service ticket:
2015-10-01 16:41:06,969 DEBUG [org.jasig.cas.CentralAuthenticationServiceImpl] 
- Generated service ticket id [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for 
ticket granting ticket 
[TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02]
2015-10-01 16:41:06,969 DEBUG 
[org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Updating ticket 
TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02
2015-10-01 16:41:06,970 DEBUG 
[org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Adding ticket 
ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
2015-10-01 16:41:06,989 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - 
Granted service ticket [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for service 
[https://luminis5-devel01.its.msstate.edu/c/portal/login] for user [jrw16]

Then here is the log for the node trying to validate the ticket.

2015-10-01 16:41:07,079 ERROR 
[org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Failed fetching 
ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
java.lang.RuntimeException: Exception waiting for value
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1237)
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1257)
at 
org.jasig.cas.ticket.registry.MemCacheTicketRegistry.getTicket(MemCacheTicketRegistry.java:150)
at 
org.jasig.cas.ticket.registry.AbstractTicketRegistry.getTicket(AbstractTicketRegistry.java:50)
at 
org.jasig.cas.CentralAuthenticationServiceImpl.validateServiceTicket(CentralAuthenticationServiceImpl.java:410)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
at 
org.perf4j.aop.AbstractTimingAspect$1.proceed(AbstractTimingAspect.java:47)
at 
org.perf4j.aop.AgnosticTimingAspect.runProfiledMethod(AgnosticTimingAspect.java:53)
at 
org.perf4j.aop.AbstractTimingAspect.doPerfLogging(AbstractTimingAspect.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
at 
org.springframework.aop.aspectj.AbstractAspectJAd

Re: [cas-user] Memcache Errors

[Ray Bon]

Jeremy,

When you say that you 'login to one node where it does everything', have
you tested each node in isolation?
Given that the 'Caused by' is unable to 'Find class', are all nodes
configured exactly the same?
Assuming that the simple explanations are dealt with, I experienced
similar behaviour (CAS 3.5.2.1 with ehcache). 90 ms (assuming your
servers are time synced) between Granted service ticket and Failed
fetching seems like a long time but is it?
If you can get some logging about the timing of memcached replication
you should have a clearer picture of the sequence of events.
In our setup we had to move to a primary server and the others act as
failovers (though I am not certain our issue was with replication alone).

Ray

On 2015-10-01 14:50, Wickham, Jeremy wrote:
>
> Going through my motions before delivering this to my production
> environment next week and something has crept up on me.
>
>  
>
> I am running multiple CAS nodes in my development environment to mimic
> what I have in production. When I log in through CAS on one node and
> it does everything (login & validate) I can get through just fine.
>  But if one node were to log me in and the other node to validate the
> ticket I receive errors. I have run the memcached-tool on both servers
> and I can read the stats of each other’s stats from the opposite
> server. Are there any thoughts on this?
>
>  
>
> Here is the logs for the node creating the service ticket:
>
> 2015-10-01 16:41:06,969 DEBUG
> [org.jasig.cas.CentralAuthenticationServiceImpl] - Generated service
> ticket id [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for ticket granting
> ticket
> [TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02]
>
> 2015-10-01 16:41:06,969 DEBUG
> [org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Updating
> ticket
> TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02
>
> 2015-10-01 16:41:06,970 DEBUG
> [org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Adding ticket
> ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
>
> 2015-10-01 16:41:06,989 INFO
> [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service
> ticket [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for service
> [https://luminis5-devel01.its.msstate.edu/c/portal/login] for user [jrw16]
>
>  
>
> Then here is the log for the node trying to validate the ticket.
>
>  
>
> 2015-10-01 16:41:07,079 ERROR
> [org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Failed
> fetching ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
>
> java.lang.RuntimeException: Exception waiting for value
>
> at
> net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1237)
>
> at
> net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1257)
>
> at
> org.jasig.cas.ticket.registry.MemCacheTicketRegistry.getTicket(MemCacheTicketRegistry.java:150)
>
> at
> org.jasig.cas.ticket.registry.AbstractTicketRegistry.getTicket(AbstractTicketRegistry.java:50)
>
> at
> org.jasig.cas.CentralAuthenticationServiceImpl.validateServiceTicket(CentralAuthenticationServiceImpl.java:410)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:606)
>
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
>
> at
> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
>
> at
> org.perf4j.aop.AbstractTimingAspect$1.proceed(AbstractTimingAspect.java:47)
>
> at
> org.perf4j.aop.AgnosticTimingAspect.runProfiledMethod(AgnosticTimingAspect.java:53)
>
> at
> org.perf4j.aop.AbstractTimingAspect.doPerfLogging(AbstractTimingAspect.java:45)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> at java.lang.reflect.Method.invoke(Method.java:606)
>
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
>
> at
> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
>
> at
> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.pro

[cas-user] Memcache Errors

[Wickham, Jeremy]

Going through my motions before delivering this to my production environment 
next week and something has crept up on me.

I am running multiple CAS nodes in my development environment to mimic what I 
have in production. When I log in through CAS on one node and it does 
everything (login & validate) I can get through just fine.  But if one node 
were to log me in and the other node to validate the ticket I receive errors. I 
have run the memcached-tool on both servers and I can read the stats of each 
other's stats from the opposite server. Are there any thoughts on this?

Here is the logs for the node creating the service ticket:
2015-10-01 16:41:06,969 DEBUG [org.jasig.cas.CentralAuthenticationServiceImpl] 
- Generated service ticket id [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for 
ticket granting ticket 
[TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02]
2015-10-01 16:41:06,969 DEBUG 
[org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Updating ticket 
TGT-7-rvkKc4EIKuOZiBjZvlTGOVOBrAFr0OSOewypHi0fdJlMCPrxeV-cas-devel02
2015-10-01 16:41:06,970 DEBUG 
[org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Adding ticket 
ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
2015-10-01 16:41:06,989 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - 
Granted service ticket [ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02] for service 
[https://luminis5-devel01.its.msstate.edu/c/portal/login] for user [jrw16]

Then here is the log for the node trying to validate the ticket.

2015-10-01 16:41:07,079 ERROR 
[org.jasig.cas.ticket.registry.MemCacheTicketRegistry] - Failed fetching 
ST-6-r2Fcb5hYgfZVrTdba6ay-cas-devel02
java.lang.RuntimeException: Exception waiting for value
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1237)
at net.spy.memcached.MemcachedClient.get(MemcachedClient.java:1257)
at 
org.jasig.cas.ticket.registry.MemCacheTicketRegistry.getTicket(MemCacheTicketRegistry.java:150)
at 
org.jasig.cas.ticket.registry.AbstractTicketRegistry.getTicket(AbstractTicketRegistry.java:50)
at 
org.jasig.cas.CentralAuthenticationServiceImpl.validateServiceTicket(CentralAuthenticationServiceImpl.java:410)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at 
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
at 
org.perf4j.aop.AbstractTimingAspect$1.proceed(AbstractTimingAspect.java:47)
at 
org.perf4j.aop.AgnosticTimingAspect.runProfiledMethod(AgnosticTimingAspect.java:53)
at 
org.perf4j.aop.AbstractTimingAspect.doPerfLogging(AbstractTimingAspect.java:45)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
at 
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
at 
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
at 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
at 
org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
at 
com.github.inspektr.audit.AuditTrailManagementAspect.handleAuditTrail(AuditTrailManagementAspect.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
at 
org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
at 
org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
at 
org.springframe

RE: [cas-user] logout redirect not use "service" but "TARGET" for .NET application?

[Zhou, Yan]

Never mind, I figured it out, we had someone wrote some code to customize that 
behavior.  Thanks, CAS does work as expected.

Yan

From: Misagh Moayyed [mailto:mmoay...@unicon.net]
Sent: Wednesday, September 30, 2015 1:53 AM
To: cas-user@lists.jasig.org
Subject: RE: [cas-user] logout redirect not use "service" but "TARGET" for .NET 
application?

I don't follow. Why or how is the .NET client sending your logout requests?

From: Zhou, Yan [mailto:yan.x.z...@questdiagnostics.com]
Sent: Tuesday, September 29, 2015 7:45 AM
To: cas-user@lists.jasig.org
Subject: [cas-user] logout redirect not use "service" but "TARGET" for .NET 
application?

Hi there,

I am using Jasig CAS 3.x.  As user logout, we want them to go back to the login 
page (not staying in the CAS logout page).  I understand that I need to append 
"service=x" at the end of /cas/logout as a query parameter.  That works 
well for all our Java based client, which by default uses "service" for such 
parameter.

We have an issue with .NET application. It automatically adds "TARGET=x" 
(not "service").  So, CAS server does not know it meant a redirect after 
logout.  Is there any way to configure CAS to accept both "service" and 
"TARGET" for serviceParameterName?

Thanks,

Yan Zhou | Quest Diagnostics Incorporated | Lead Engineer, Healthcare IT 
Solutions | 4690 Parkway Drive | Mason, OH 45040 USA | phone +1 513-204-2613 | 
fax +1 513-229-5505 |  
yan.x.z...@questdiagnostics.com | 
www.questdiagnostics.com


__
The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to which they are addressed and may contain 
confidential and/or privileged information. Further, any medical information 
herein is confidential and protected by law. It is unlawful for unauthorized 
persons to use, review, copy, disclose, or disseminate confidential medical 
information. If you are not the intended recipient, immediately advise the 
sender and delete this message and any attachments. Any distribution, or 
copying of this message, or any attachment, is prohibited.



--

You are currently subscribed to 
cas-user@lists.jasig.org as: 
mmoay...@unicon.net

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user



--

You are currently subscribed to 
cas-user@lists.jasig.org as: 
yan.x.z...@questdiagnostics.com

To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

__
The contents of this message, together with any attachments, are intended only 
for the use of the person(s) to which they are addressed and may contain 
confidential and/or privileged information. Further, any medical information 
herein is confidential and protected by law. It is unlawful for unauthorized 
persons to use, review, copy, disclose, or disseminate confidential medical 
information. If you are not the intended recipient, immediately advise the 
sender and delete this message and any attachments. Any distribution, or 
copying of this message, or any attachment, is prohibited.

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

[cas-user] handshake failure during authentication

[Adam Causey]

Hello,

We are currently running two CAS servers in a primary/failover setup behind
a Cisco ACE load balancer.  Our networking department is upgrading to an F5
load balancer.  During testing of CAS on the new F5 load balancer I am
receiving the exception below during authentication.  It has occurred on
multiple applications, so I know it is not related to the application.

Our Setup:

CAS 3.5.3
JDK 1.7
Tomcat 7 (behind an Apache HTTP Server)

Is it possible I need to change the hash algorithm and/or cipher suites
within my ssl.conf in Apache?  I believe they have configured F5 to only
allow TLS 1.2 connections.


java.lang.RuntimeException: javax.net.ssl.SSLHandshakeException: Received
fatal alert: handshake_failure

at
org.jasig.cas.client.validation.Saml11TicketValidator.retrieveResponseFromServer(
Saml11TicketValidator.java:275)

at org.jasig.cas.client.validation.AbstractUrlBasedTicketValidator.validate(
AbstractUrlBasedTicketValidator.java:200)

at org.jasig.cas.client.validation.AbstractTicketValidationFilter.doFilter(
AbstractTicketValidationFilter.java:206)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208)

at org.jasig.cas.client.authentication.AuthenticationFilter.doFilter(
AuthenticationFilter.java:161)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:208)

at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:220)

at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:122)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
AuthenticatorBase.java:505)

at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:170)

at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:103)

at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:957)

at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:116)

at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:423)

at org.apache.coyote.http11.AbstractHttp11Processor.process(
AbstractHttp11Processor.java:1079)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
AbstractProtocol.java:620)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(
JIoEndpoint.java:318)

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)

Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert:
handshake_failure

at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)

at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)

at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2023)

at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1125)

at sun.security.ssl.SSLSocketImpl.performInitialHandshake(
SSLSocketImpl.java:1375)

at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)

at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)

at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)

at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(
AbstractDelegateHttpsURLConnection.java:185)

at sun.net.www.protocol.http.HttpURLConnection.getOutputStream0(
HttpURLConnection.java:1282)

at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(
HttpURLConnection.java:1257)

at sun.net.www.protocol.https.HttpsURLConnectionImpl.getOutputStream(
HttpsURLConnectionImpl.java:250)

at
org.jasig.cas.client.validation.Saml11TicketValidator.retrieveResponseFromServer(
Saml11TicketValidator.java:259)

... 22 more

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user