[cas-user] AcceptUsersAuthenticationHandler is used instead of LDAP
Hi, I am unable to find out, why AcceptUsersAuthenticationHandler is still used to authenticate users. Even after commenting out all but ldap in deployerConfigContext.xml (attached) Log part of the failed login attempt: 2015-01-09 13:54:06,047 DEBUG [org.jasig.cas.authentication.AcceptUsersAuthenticationHandler] - kaeeli was not found in the map. 2015-01-09 13:54:06,047 INFO [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - AcceptUsersAuthenticationHandler failed authenticating +password 2015-01-09 13:54:06,055 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN = WHO: audit:unknown WHAT: supplied credentials: [kaeeli+password] ACTION: AUTHENTICATION_FAILED APPLICATION: CAS WHEN: Fri Jan 09 13:54:06 EET 2015 CLIENT IP ADDRESS: 192.168.8.5 SERVER IP ADDRESS: 192.168.7.183 = -- Tiit Kaeeli OU Quretec tiit.kae...@quretec.com Tel:+372 5 070 359 -- 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 deployerConfigContext.xml Description: XML document
Re: [cas-user] AcceptUsersAuthenticationHandler is used instead of LDAP
On Fri, 9 Jan 2015, Dmitriy Kopylenko wrote: You'd want to make sure that your change is in effect. After you made that change, did you re-build and re-deployed the cas.war? Yes, after every chage I do: mvn clean package ./bin/shutdown.sh rm -r webapps/cas/ work/ logs/* cp target/cas.war ./bin/startup.sh Cheers, Dmitriy. Sent from my iPhone On Jan 9, 2015, at 07:16, Tiit Kaeeli wrote: Hi, I am unable to find out, why AcceptUsersAuthenticationHandler is still used to authenticate users. Even after commenting out all but ldap in deployerConfigContext.xml (attached) Log part of the failed login attempt: 2015-01-09 13:54:06,047 DEBUG [org.jasig.cas.authentication.AcceptUsersAuthenticationHandler] - kaeeli was not found in the map. 2015-01-09 13:54:06,047 INFO [org.jasig.cas.authentication.PolicyBasedAuthenticationManager] - AcceptUsersAuthenticationHandler failed authenticating +password 2015-01-09 13:54:06,055 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit trail record BEGIN = WHO: audit:unknown WHAT: supplied credentials: [kaeeli+password] ACTION: AUTHENTICATION_FAILED APPLICATION: CAS WHEN: Fri Jan 09 13:54:06 EET 2015 CLIENT IP ADDRESS: 192.168.8.5 SERVER IP ADDRESS: 192.168.7.183 = -- Tiit Kaeeli OU Quretec tiit.kae...@quretec.com Tel:+372 5 070 359 -- You are currently subscribed to cas-user@lists.jasig.org as: dkopyle...@unicon.net To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- Tiit Kaeeli OU Quretec tiit.kae...@quretec.com Tel:+372 5 070 359 -- 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
Re: [cas-user] AcceptUsersAuthenticationHandler is used instead of LDAP
On Fri, 9 Jan 2015, Marvin Addison wrote: Yes, after every chage I do: mvn clean package ./bin/shutdown.sh rm -r webapps/cas/ work/ logs/* cp target/cas.war ./bin/startup.sh That should work, but you might also try clearing out the unpacked war files under (IIRC) $CATALINA_HOME/temp. I have a habit of clearing out those files as part of the redeploy process since I had some evidence of changes not taking in the past. Can't hurt in any case. temp (and data) do not exist. Usually I remove them too, if existing. -- 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
Re: [cas-user] AcceptUsersAuthenticationHandler is used instead of LDAP
On Fri, 9 Jan 2015, Tiit Kaeeli wrote: On Fri, 9 Jan 2015, Marvin Addison wrote: Yes, after every chage I do: mvn clean package ./bin/shutdown.sh rm -r webapps/cas/ work/ logs/* cp target/cas.war ./bin/startup.sh That should work, but you might also try clearing out the unpacked war files under (IIRC) $CATALINA_HOME/temp. I have a habit of clearing out those files as part of the redeploy process since I had some evidence of changes not taking in the past. Can't hurt in any case. temp (and data) do not exist. Usually I remove them too, if existing. What else can I try? Any more ideas? Tiit -- 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
Re: [cas-user] AcceptUsersAuthenticationHandler is used instead of LDAP
On Wed, 14 Jan 2015, Tiit Kaeeli wrote: On Fri, 9 Jan 2015, Tiit Kaeeli wrote: On Fri, 9 Jan 2015, Marvin Addison wrote: Yes, after every chage I do: mvn clean package ./bin/shutdown.sh rm -r webapps/cas/ work/ logs/* cp target/cas.war ./bin/startup.sh That should work, but you might also try clearing out the unpacked war files under (IIRC) $CATALINA_HOME/temp. I have a habit of clearing out those files as part of the redeploy process since I had some evidence of changes not taking in the past. Can't hurt in any case. temp (and data) do not exist. Usually I remove them too, if existing. What else can I try? Any more ideas? Tiit I found that after running mvn clean package the follwing deployerConfigContext.xml files appear ./target/cas/WEB-INF/deployerConfigContext.xml Has incorrect content ./target/cas/WEB-INF/spring-configuration/deployerConfigContext.xml Has correct content ./target/war/work/org.jasig.cas/cas-server-webapp/WEB-INF/deployerConfigContext.xml Has incorrect content ./src/main/webapp/WEB-INF/spring-configuration/deployerConfigContext.xml Has correct content. This is the only one that exist before running "mvn clean package" Can anyone explain from where ./target/cas/WEB-INF/deployerConfigContext.xml and ./target/war/work/org.jasig.cas/cas-server-webapp/WEB-INF/deployerConfigContext.xml come from? -- Tiit -- 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] mod_auth_cas samlValidate on apache 2.2.22
Hi, For LDAP based group authorization on Apache, I tried to enable SAML support. http://permalink.gmane.org/gmane.comp.java.jasig.cas.user/26597 notes, that mod_auth_cas 1.0.9.1 cannot parse the part of this response. To get around this, either use git master or use the patch from https://github.com/Jasig/mod_auth_cas/pull/46/files. Readme on git master (cloned 19.01.2015) states The following development libraries and utilities must be installed: ... * Apache Web Server - 2.2.3 ... After compiling and loading to Apache, the following error is returned: apache2: Syntax error on line 244 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/auth_cas.load: Cannot load /opt/mod_auth_cas/mod_auth_cas.so into server: /opt/mod_auth_cas/mod_auth_cas.so: undefined symbol: ap_hook_check_access_ex Action 'configtest' failed. http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html New functions ap_hook_check_access_ex, ap_hook_check_access, ap_hook_check_authn, ap_hook_check_authz which accept AP_AUTH_INTERNAL_PER_* flags Suggestions? -- 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
Re: [cas-user] mod_auth_cas samlValidate on apache 2.2.22
On Thu, 22 Jan 2015, David Hawes wrote: On Thu, Jan 22, 2015 at 8:07 AM, Tiit Kaeeli wrote: Hi, For LDAP based group authorization on Apache, I tried to enable SAML support. http://permalink.gmane.org/gmane.comp.java.jasig.cas.user/26597 notes, that mod_auth_cas 1.0.9.1 cannot parse the part of this response. To get around this, either use git master or use the patch from https://github.com/Jasig/mod_auth_cas/pull/46/files. Readme on git master (cloned 19.01.2015) states The following development libraries and utilities must be installed: ... * Apache Web Server - 2.2.3 ... After compiling and loading to Apache, the following error is returned: apache2: Syntax error on line 244 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/auth_cas.load: Cannot load /opt/mod_auth_cas/mod_auth_cas.so into server: /opt/mod_auth_cas/mod_auth_cas.so: undefined symbol: ap_hook_check_access_ex Action 'configtest' failed. http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html New functions ap_hook_check_access_ex, ap_hook_check_access, ap_hook_check_authn, ap_hook_check_authz which accept AP_AUTH_INTERNAL_PER_* flags Are you using git master, or did you patch? Can you post a diff of your mod_auth_cas.c with git master's? I used git master from 19.01.2015 -- 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
Re: [cas-user] mod_auth_cas samlValidate on apache 2.2.22
On Fri, 23 Jan 2015, David Hawes wrote: On Fri, Jan 23, 2015 at 5:38 AM, Tiit Kaeeli wrote: On Thu, 22 Jan 2015, David Hawes wrote: On Thu, Jan 22, 2015 at 8:07 AM, Tiit Kaeeli wrote: Hi, For LDAP based group authorization on Apache, I tried to enable SAML support. http://permalink.gmane.org/gmane.comp.java.jasig.cas.user/26597 notes, that mod_auth_cas 1.0.9.1 cannot parse the part of this response. To get around this, either use git master or use the patch from https://github.com/Jasig/mod_auth_cas/pull/46/files. Readme on git master (cloned 19.01.2015) states The following development libraries and utilities must be installed: ... * Apache Web Server - 2.2.3 ... After compiling and loading to Apache, the following error is returned: apache2: Syntax error on line 244 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/auth_cas.load: Cannot load /opt/mod_auth_cas/mod_auth_cas.so into server: /opt/mod_auth_cas/mod_auth_cas.so: undefined symbol: ap_hook_check_access_ex Action 'configtest' failed. http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html New functions ap_hook_check_access_ex, ap_hook_check_access, ap_hook_check_authn, ap_hook_check_authz which accept AP_AUTH_INTERNAL_PER_* flags Are you using git master, or did you patch? Can you post a diff of your mod_auth_cas.c with git master's? I used git master from 19.01.2015 What's the output of 'httpd -v'? apache2 -V Server version: Apache/2.2.22 (Debian) Server built: Dec 23 2014 22:48:29 Server's Module Magic Number: 20051115:30 Server loaded: APR 1.4.6, APR-Util 1.4.1 Compiled using: APR 1.4.6, APR-Util 1.4.1 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/etc/apache2" -D SUEXEC_BIN="/usr/lib/apache2/suexec" -D DEFAULT_PIDLOG="/var/run/apache2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="mime.types" -D SERVER_CONFIG_FILE="apache2.conf" If you want to test something, change mod_auth_cas.c:2648 to "#if 0" to force using ap_hook_check_user_id. Recompile and see if that works. After the change, this is the output: apache2: Syntax error on line 244 of /etc/apache2/apache2.conf: Syntax error on line 2 of /etc/apache2/mods-enabled/auth_cas.load: Cannot load /opt/mod_auth_cas/mod_auth_cas.so into server: /opt/mod_auth_cas/mod_auth_cas.so: undefined symbol: ap_log_error_ Action 'configtest' failed. The Apache error log may have more information. failed! -- 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] after
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] - retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> 2015-02-11 14:38:16,202 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com] found in registry.> 2015-02-11 14:38:16,202 DEBUG [org.jasig.cas.CentralAuthenticationServiceImpl] - 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] - [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com] from registry> 2015-02-11 14:38:16,202 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> 2015-02-11 14:38:16,202 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - 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] - retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> 2015-02-11 14:38:16,562 INFO [org.jasig.cas.CentralAuthenticationServiceImpl] - [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com] does not exist.> 2015-02-11 14:38:16,566 DEBUG [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - retrieve ticket [ST-1-V6yYyU7eDUu1zqqh4gGm-cas.quretec.com]> 2015-02-11 14:38:16,566 INFO [com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - 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 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
Re: [cas-user] after
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: encoding="UTF-8"?> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>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">p:Status>Value="saml1p:Success"/>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">NotBefore="2015-02 -11T16:40:02.454Z" NotOnOrAfter="2015-02-11T16:40:32.454Z">https://nagios.quretec.com/cas AuthenticationInstant="2015-02-11T15:07:56.192Z" AuthenticationMethod ="urn:oasis:names:tc:SAML:1.0:am:unspecified">kaeeliurn:oasis:names:tc:SAML:1.0:cm:artifact [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 = encoding="UTF-8"?>lope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>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">aml1p:Status>Value="saml1p:Success"/>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">NotBefore="201 5-02-11T16:40:02.454Z" NotOnOrAfter="2015-02-11T16:40:32.454Z">https://nagios.quretec.com/casence>AuthenticationInstant="2015-02-11T15:07:56.192Z" AuthenticationMe thod="urn:oasis:names:tc:SAML:1.0:am:unspecified">kaeeliurn:oasis:names:tc:SAML:1.0:cm:artifact [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" To: cas-user@lists.jasig.org Sent: Wednesday, February 11, 2015 8:10:56 AM Subject: [cas-user] after 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
Re: [cas-user] after
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:
kaeeli
* Connection #0 to host cas.quretec.com left intact
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
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>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">Value="saml1p:RequestDenied"/>'service' and 'ticket'
parameters are both
required*
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"
To: cas-user@lists.jasig.org
Sent: Wednesday, February 11, 2015 11:50:32 AM
Subject: Re: [cas-user] after
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: http://schemas.xmlsoap.org/soap/envelope/";>https://nagios.quretec.com/cas";
ResponseID="_e4cafa37cb4c77fe55aae7c0d482e40e">https://nagios.quretec.com/cas
AuthenticationInstant="2015-02-11T15:07:56.192Z" AuthenticationMethod
="urn:oasis:names:tc:SAML:1.0:am:unspecified">kaeeliurn:oasis:names:tc:SAML:1.0:cm:artifact
[Wed Feb 11 18:40:02 2
Re: [cas-user] after
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/
CASDebugOn
CASCertificatePath /etc/ssl/certs/cas_quretec_com_crt.pem
CASLoginURL https://cas.quretec.com:8443/cas/login
# CASValidateURLhttps://cas.quretec.com:8443/cas/serviceValidate
CASValidateURL https://cas.quretec.com:8443/cas/samlValidate
CASValidateSAML On
...
AuthName "cas test"
AuthType CAS
CASAuthNHeader username
Require valid-user
# Require cas-attribute
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)
mepst...@illinois.edu
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 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:
kaeeli
* Connection #0 to host cas.quretec.com left intact
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
http://schemas.xmlsoap.org/soap/envelope/";>'service' and 'ticket' parameters are both
required* 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
Re: [cas-user] after
On Fri, 13 Feb 2015, David Hawes wrote: On Thu, Feb 12, 2015 at 7:44 AM, Tiit Kaeeli 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 Apache version? (Sorry, meant to ask this before) Server version: Apache/2.2.22 (Debian) Server built: Dec 23 2014 22:48:29 Server's Module Magic Number: 20051115:30 Server loaded: APR 1.4.6, APR-Util 1.4.1 Compiled using: APR 1.4.6, APR-Util 1.4.1 Architecture: 64-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/etc/apache2" -D SUEXEC_BIN="/usr/lib/apache2/suexec" -D DEFAULT_PIDLOG="/var/run/apache2.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="mime.types" -D SERVER_CONFIG_FILE="apache2.conf" If I'm not mistaken, some work was done for CAS 4 support in this branch: https://github.com/smaresca/mod_auth_cas/tree/saml_segv https://github.com/Jasig/mod_auth_cas/pull/82 It couldn't hurt to give it a try. I don't currently have a CAS 4 server that I can test against, but hopefully we can figure out what's going on here. -- 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
Re: [cas-user] after
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
I tried to send xml as described in
http://jasig.github.io/cas/4.0.x/protocol/SAML-Protocol.html
to /cas/samlValidate
CAS_LOGIN=https://cas.quretec.com:8443/cas/login;
# SERVICE_VALIDATE=https://cas.quretec.com:8443/cas/serviceValidate;
SERVICE_VALIDATE=https://cas.quretec.com:8443/cas/samlValidate;
SERVICE='https://nagios.quretec.com/cas';
TGT='TGT-7-pbHVDuT1AjDf3w7mCPON2Aqkm1Pu562wxGPYBacueNswJJ3t7G-cas.quretec.com';
TZ=238
date=`date`
timesec=`date -d "${date}" +%s`
equestID=_192.168.7.108.${timesec}${TZ}
IDtime=`date -d "${date}" +%Y-%m-%dT%H:%M:%S`
IssueInstant="${IDtime}.${TZ}Z"
echo "RequestID=${RequestID}"
echo "IssueInstant=${IssueInstant}"
# ST=$(http "$CAS_LOGIN" "Cookie:CASTGC=${TGT}" service=="$SERVICE"
| \
# grep -e ticket= | sed -e 's/^.*ticket=//' -e 's/\r//') &&
\
# http "$SERVICE_VALIDATE" service=="$SERVICE" ticket=="$ST"
ST=$(curl -k -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//')
xml="http://schemas.xmlsoap.org/soap/envelope/\";>${ST}"
echo "xml=${xml}"
curl -k -v --get --data-urlencode service="$SERVICE" --data-urlencode
ticket="${xml}" $SERVICE_VALIDATE
But result is still:
> GET
/cas/samlValidate?service=https%3A%2F%2Fnagios.quretec.com%2Fcas&ticket=%3C%3Fxml%20version%3D1.0%20encoding%3Dutf-8%3F%3E%3CSOAP-ENV%3AEnvelope%20xmlns%3ASOAP-ENV%3D%22http%3A%2F%2Fschemas.xmlsoap.org%2Fsoap%2Fenvelope%2F%22%3E%3CSOAP-ENV%3AHeader%2F%3E%3CSOAP-ENV%3ABody%3E%3Csamlp%3ARequest%20xmlns%3Asamlp%3D%22urn%3Aoasis%3Anames%3Atc%3ASAML%3A1.0%3Aprotocol%22%20%20MajorVersion%3D%221%22%20MinorVersion%3D%221%22%20RequestID%3D%22_192.168.7.108.1424086899238%22%20IssueInstant%3D%222015-02-16T13%3A41%3A39.238Z%22%3E%3Csamlp%3AAssertionArtifact%3EST-64-Y4TqyaR9ngCoYnGVfaEv-cas.quretec.com%3C%2Fsamlp%3AAssertionArtifact%3E%3C%2Fsamlp%3ARequest%3E%3C%2FSOAP-ENV%3ABody%3E%3C%2FSOAP-ENV%3AEnvelope%3E
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: Mon, 16 Feb 2015 11:41:39 GMT
<
* Connection #0 to host cas.quretec.com left intact
http://schemas.xmlsoap.org/soap/envelope/";>'service' and 'ticket'
parameters are both
required*
Closing connection #0
* SSLv3, TLS alert, Client hello (1):
>
>> On Feb 12, 2015, at 1:44 PM, Tiit Kaeeli 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:
>>
>>
>>
>>kaeeli
>>
>>
>>
>> * Connection #0 to host cas.quretec.com left intact
>>
>>
>>
>> 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
>> > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>> xmlns:saml1p="urn:
