But that just describes the error, it doesn't necessarily indicate how to fix the error, right?
I recall getting an error like that, and I think the fix was some mod_auth_cas configuration problem. For instance, do you have this set in your mod_auth_cas config?: CASValidateSaml On Besides that, you might not need to use Saml, you might be able to get by with the p3 service validation available in CAS 4.0. I was able to do that -- although, again, I needed to modify mod_auth_cas -- modifications which were discussed on the mod_auth_cas dev list, although I don't know whether they've been incorporated into any available version of the code yet (but they should be available on the list archives). It's also possible that your requirements -- you mention needing group based auth -- are different and the p3 validation won't be sufficient. Milt Epstein Applications Developer Graduate School of Library and Information Science (GSLIS) University of Illinois at Urbana-Champaign (UIUC) [email protected] On Thu, 12 Feb 2015, Misagh Moayyed wrote: > The message is misleading and incorrect, yes, and we should correctly > describe the error, which is: your samlValidate endpoint requires not a > service and a ticket, but a TARGET and artifactId. > > I???ll open up an issue to fix this. > > - Misagh > > > On Feb 12, 2015, at 1:44 PM, Tiit Kaeeli <[email protected]> wrote: > > > > Thanks. > > > > CAS is https://github.com/UniconLabs/simple-cas4-overlay-template master > > from 28 nov. 2014 > > > > mod_auth_cas is https://github.com/Jasig/mod_auth_cas master from 19.01.2015 > > > > > > When I use serviceValidate in curl script, the result is: > > > > <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> > > <cas:authenticationSuccess> > > <cas:user>kaeeli</cas:user> > > > > > > </cas:authenticationSuccess> > > * Connection #0 to host cas.quretec.com left intact > > </cas:serviceResponse> > > > > > > When turning to samlValidate, the output is > > > >> GET > > /cas/samlValidate?service=https://nagios.quretec.com/cas&ticket=ST-27-u7pHxJeireBDF1BOef0c-cas.quretec.com > > HTTP/1.1 > >> User-Agent: curl/7.26.0 > >> Host: cas.quretec.com:8443 > >> Accept: */* > >> > > * additional stuff not fine transfer.c:1037: 0 0 > > * HTTP 1.1 or later with persistent connection, pipelining supported > > < HTTP/1.1 200 OK > > < Server: Apache-Coyote/1.1 > > < Cache-control: no-cache, no-store > > < Pragma: no-cache > > < SOAPAction: http://www.oasis-open.org/committees/security > > < Content-Type: text/xml;charset=UTF-8 > > < Content-Language: en > > < Transfer-Encoding: chunked > > < Date: Thu, 12 Feb 2015 12:28:05 GMT > > < > > * Connection #0 to host cas.quretec.com left intact > > <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope > > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";><SOAP-ENV:Body><saml1p:Response > > xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" > > IssueInstant="2015-02-12T12:28:05.897Z" MajorVersion="1" MinorVersion="1" > > Recipient="UNKNOWN" > > ResponseID="_109405fffabb202dbcc8915292aaf3a9"><saml1p:Status><saml1p:StatusCode > > Value="saml1p:RequestDenied"/><saml1p:StatusMessage>'service' and 'ticket' > > parameters are both > > required</saml1p:StatusMessage></saml1p:Status></saml1p:Response></SOAP-ENV:Body></SOAP-ENV:Envelope>* > > Closing connection #0 > > * SSLv3, TLS alert, Client hello (1): > > > > Seems like something is wrong with the curl command. I tried \'\' and \"\" > > around $SERVICE and $ST, but results are always the same. > > > > curl -k -v --get --data service="$SERVICE" --data ticket="$ST" > > $SERVICE_VALIDATE > > > > > > > > > > On Wed, 11 Feb 2015, Waldbieser, Carl wrote: > > > >> > >> Can you use a command line HTTP client like cURL[1] or httpie[2] to > >> request an ST and validate it? Here is a unix shell script I use with > >> httpie to inspect CAS validation responses: > >> > >> #! /bin/sh > >> > >> CAS_LOGIN=https://cas.example.net/cas/login; > >> SERVICE_VALIDATE=https://cas.example.net/cas/serviceValidate; > >> SERVICE='https://service.example.com/login'; > >> TGT='Enter TGT here'; > >> ST=$(http -v "$CAS_LOGIN" "Cookie:CASTGC=${TGT}" service=="$SERVICE" | \ > >> grep -e ticket= | sed -e 's/^.*ticket=//' -e 's/\r//') && \ > >> http "$SERVICE_VALIDATE" service=="$SERVICE" ticket=="$ST" > >> > >> Here is a similar `curl` version: > >> > >> #! /bin/sh > >> > >> CAS_LOGIN=https://cas.example.net/cas/login; > >> SERVICE_VALIDATE=https://cas.example.net/cas/serviceValidate; > >> SERVICE='https://service.example.com/login'; > >> TGT='Enter TGT here'; > >> ST=$(curl -v --get --data service="$SERVICE" --cookie CASTGC="$TGT" > >> "$CAS_LOGIN" 2>&1 | \ > >> grep -e '^< Location:' | grep -e ticket= | sed -e 's/^.*ticket=//' > >> -e 's/\r//') && \ > >> curl -v --get --data service="$SERVICE" --data ticket="$ST" > >> "$SERVICE_VALIDATE" > >> > >> You set the variables like CAS_LOGIN, SERVICE, TGT, etc. You can get a > >> valid TGT from your CAS logs or dig it out of your browser cookies after > >> you authenticate successfully. The lines starting with `ST=` request an > >> ST and validate it. The response is spit out to the console so you can > >> see what the response looks like. Hopefully, that will help you figure > >> out why mod_auth_cas doesn't like the XML it is getting back. > >> > >> Thanks, > >> Carl > >> > >> [1] http://curl.haxx.se/ > >> [2] https://github.com/jakubroztocil/httpie > >> > >> ----- Original Message ----- > >> From: "Tiit Kaeeli" <[email protected]> > >> To: [email protected] > >> Sent: Wednesday, February 11, 2015 11:50:32 AM > >> Subject: Re: [cas-user] <ServiceTicket [...] does not exist.> after > >> <Removing ticket [...] from registry> > >> > >> mod_auth_cas log of the first try. Fails with > >> > >> MOD_AUTH_CAS: Error parsing XML content (Internal error) > >> > >> > >> > >> > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(2026): [client > >> 192.168.8.218] Entering cas_authenticate() > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(645): [client > >> 192.168.8.218] Modified r->args (now '') > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1729): [client > >> 192.168.8.218] entering getResponseFromServer() > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(575): [client > >> 192.168.8.218] CAS Service 'https%3a%2f%2fnagios.quretec.com%2fcas' > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1806): [client > >> 192.168.8.218] Validation response: <?xml version="1.0" > >> encoding="UTF-8"?><SOAP-ENV:Envelope > >> > >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";><SOAP-ENV:Body><saml1p:Response > >> xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" IssueInstant= > >> "2015-02-11T16:40:02.454Z" MajorVersion="1" MinorVersion="1" > >> Recipient="https://nagios.quretec.com/cas"; > >> ResponseID="_e4cafa37cb4c77fe55aae7c0d482e40e"><saml1 > >> p:Status><saml1p:StatusCode > >> Value="saml1p:Success"/></saml1p:Status><saml1:Assertion > >> xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_2121b0 > >> 19c9fedf9b287bb811280e227c" IssueInstant="2015-02-11T16:40:02.454Z" > >> Issuer="localhost" MajorVersion="1" MinorVersion="1"><saml1:Conditions > >> NotBefore="2015-02 > >> -11T16:40:02.454Z" > >> NotOnOrAfter="2015-02-11T16:40:32.454Z"><saml1:AudienceRestrictionCondition><saml1:Audience>https://nagios.quretec.com/cas</saml1:Audience > >>> </saml1:AudienceRestrictionCondition></saml1:Conditions><saml1:AuthenticationStatement > >> AuthenticationInstant="2015-02-11T15:07:56.192Z" AuthenticationMethod > >> ="urn:oasis:names:tc:SAML:1.0:am:unspecified"><saml1:Subject><saml1:NameIdentifier>kaeeli</saml1:NameIdentifier><saml1:SubjectConfirmation><saml1:Confirmatio > >> nMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact</saml1:ConfirmationMethod></saml1:SubjectConfirmation></saml1:Subject></saml1:AuthenticationStatement></saml1 > >> :Assertion></saml1p:Response></SOAP-ENV:Body></SOAP-ENV:Envelope> > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1434): [client > >> 192.168.8.218] entering isValidCASTicket() > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1440): [client > >> 192.168.8.218] MOD_AUTH_CAS: response = <?xml version="1.0" > >> encoding="UTF-8"?><SOAP-ENV:Enve > >> lope > >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";><SOAP-ENV:Body><saml1p:Response > >> xmlns:saml1p="urn:oasis:names:tc:SAML:1.0:protocol" IssueInst > >> ant="2015-02-11T16:40:02.454Z" MajorVersion="1" MinorVersion="1" > >> Recipient="https://nagios.quretec.com/cas"; > >> ResponseID="_e4cafa37cb4c77fe55aae7c0d482e40e"><s > >> aml1p:Status><saml1p:StatusCode > >> Value="saml1p:Success"/></saml1p:Status><saml1:Assertion > >> xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_21 > >> 21b019c9fedf9b287bb811280e227c" IssueInstant="2015-02-11T16:40:02.454Z" > >> Issuer="localhost" MajorVersion="1" MinorVersion="1"><saml1:Conditions > >> NotBefore="201 > >> 5-02-11T16:40:02.454Z" > >> NotOnOrAfter="2015-02-11T16:40:32.454Z"><saml1:AudienceRestrictionCondition><saml1:Audience>https://nagios.quretec.com/cas</saml1:Audi > >> ence></saml1:AudienceRestrictionCondition></saml1:Conditions><saml1:AuthenticationStatement > >> AuthenticationInstant="2015-02-11T15:07:56.192Z" AuthenticationMe > >> thod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><saml1:Subject><saml1:NameIdentifier>kaeeli</saml1:NameIdentifier><saml1:SubjectConfirmation><saml1:Confirm > >> ationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact</saml1:ConfirmationMethod></saml1:SubjectConfirmation></saml1:Subject></saml1:AuthenticationStatement></s > >> aml1:Assertion></saml1p:Response></SOAP-ENV:Body></SOAP-ENV:Envelope> > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1266): [client > >> 192.168.8.218] entering createCASCookie() > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1061): [client > >> 192.168.8.218] entering CASCleanCache() > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1117): [client > >> 192.168.8.218] Beginning cache clean > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1140): [client > >> 192.168.8.218] Processing cache file 'd76eaa64b28d6adf641e9d8fe59e39bb' > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(890): [client > >> 192.168.8.218] entering readCASCacheFile() > >> [Wed Feb 11 18:40:02 2015] [error] [client 192.168.8.218] MOD_AUTH_CAS: > >> Error parsing XML content (Internal error) > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1156): [client > >> 192.168.8.218] Removing corrupt cache entry > >> 'd76eaa64b28d6adf641e9d8fe59e39bb' > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1406): [client > >> 192.168.8.218] entering deleteCASCacheFile() > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(890): [client > >> 192.168.8.218] entering readCASCacheFile() > >> [Wed Feb 11 18:40:02 2015] [error] [client 192.168.8.218] MOD_AUTH_CAS: > >> Error parsing XML content (Internal error) > >> [Wed Feb 11 18:40:02 2015] [debug] mod_auth_cas.c(1178): [client > >> 192.168.8.218] entering writeCASCacheEntry() > >> > >> > >> > >> > >>> > >>> Yes. > >>> The service ticket can only be used once. > >>> Once a service validates the service ticket, it ought to establish some > >>> kind of local application specific session. > >>> The fact that the ticket is being validated twice suggests that maybe the > >>> client is configured incorrectly. > >>> > >>> Thanks, > >>> Carl Waldbieser > >>> ITS System Programmer > >>> Lafayette College > >>> > >>> ----- Original Message ----- > >>> From: "Tiit Kaeeli" <[email protected]> > >>> To: [email protected] > >>> Sent: Wednesday, February 11, 2015 8:10:56 AM > >>> Subject: [cas-user] <ServiceTicket [...] does not exist.> after <Removing > >>> ticket [...] from registry> > >>> > >>> Hi, > >>> > >>> I got mod_auth_cas working without SAML. Now I am trying to enable SAML > >>> for LDAP group based auth. But unfortunately apache returns 401. So I am > >>> in need for help again. > >>> > >>> In tomcat logs, there are no errors, but final result is > >>> > >>> WHAT: ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com > >>> ACTION: SERVICE_TICKET_VALIDATE_FAILED > >>> > >>> > >>> > >>> Before this I see: > >>> > >>> 2015-02-11 14:38:16,202 DEBUG > >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Attempting to > >>> retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> > >>> 2015-02-11 14:38:16,202 DEBUG > >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Ticket > >>> [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com] found in registry.> > >>> 2015-02-11 14:38:16,202 DEBUG > >>> [org.jasig.cas.CentralAuthenticationServiceImpl] - <Principal id to return > >>> for service [HTTP and IMAP] is [kaeeli]. The default principal id is > >>> [kaeeli].> > >>> 2015-02-11 14:38:16,202 DEBUG > >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Removing ticket > >>> [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com] from registry> > >>> 2015-02-11 14:38:16,202 DEBUG > >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Attempting to > >>> retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> > >>> 2015-02-11 14:38:16,202 INFO > >>> [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit > >>> trail record BEGIN > >>> ============================================================= > >>> WHO: audit:unknown > >>> WHAT: ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com > >>> ACTION: SERVICE_TICKET_VALIDATED > >>> APPLICATION: CAS > >>> WHEN: Wed Feb 11 14:38:16 EET 2015 > >>> CLIENT IP ADDRESS: 192.168.7.108 > >>> SERVER IP ADDRESS: 192.168.7.183 > >>> ============================================================= > >>> > >>> > >>> ... > >>> > >>> 2015-02-11 14:38:16,562 DEBUG > >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Attempting to > >>> retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> > >>> 2015-02-11 14:38:16,562 INFO > >>> [org.jasig.cas.CentralAuthenticationServiceImpl] - <ServiceTicket > >>> [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com] does not exist.> > >>> 2015-02-11 14:38:16,566 DEBUG > >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - <Attempting to > >>> retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> > >>> 2015-02-11 14:38:16,566 INFO > >>> [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit > >>> trail record BEGIN > >>> ============================================================= > >>> WHO: audit:unknown > >>> WHAT: ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com > >>> ACTION: SERVICE_TICKET_VALIDATE_FAILED > >>> APPLICATION: CAS > >>> WHEN: Wed Feb 11 14:38:16 EET 2015 > >>> CLIENT IP ADDRESS: 192.168.7.108 > >>> SERVER IP ADDRESS: 192.168.7.183 > >>> ============================================================= > >>> > >>> > >>> > >>> > >>> It seems, that service ticket is looked for twice, first time it succeeds. > >>> Then the ticket is removed from the registry. The other attemp after that > >>> fails. > >>> > >>> Is this normal and expected behaviour? > >>> > >>> > >>> > >>> > >> > >> > >> > > > > > > -- > > 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
