On Thu, 12 Feb 2015, Milt Epstein wrote:
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
My mod_auth_cas config:
CASCookiePath /var/cache/apache2/mod_auth_cas/
CASDebug On
CASCertificatePath /etc/ssl/certs/cas_quretec_com_crt.pem
CASLoginURL https://cas.quretec.com:8443/cas/login
# CASValidateURL https://cas.quretec.com:8443/cas/serviceValidate
CASValidateURL https://cas.quretec.com:8443/cas/samlValidate
CASValidateSAML On
...
<Location /cas>
AuthName "cas test"
AuthType CAS
CASAuthNHeader username
Require valid-user
# Require cas-attribute
</Location>
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
