Joel, We need to first figure out why you have no attributes in the SAML response. Do you have any other URLs configured in service manager, perhaps one taking precedence and delivering no attributes? -Matt On Jan 18, 2012 10:08 PM, "Joel Goguen" <joel.gog...@unb.ca> wrote:
> Heh...I can see where that would cause a problem. Once I switch to > samlValidate CAS authentication works fine, but now I'm not getting the > attributes released like I expect. I've defined uid, eduPersonEntitlement > and eduPersonAffiliation as attributes (the resultAttributeMapping property > in the attributeRepository bean, which has > class org.jasig.services.persondir.support.ldap.LdapPersonAttributeDao) and > they show up in the service manager. When I defined the service definition > (service URL: https://webtest.its.unb.ca/**) I chose all three attributes > and selected "Enabled", "SSO Participant" and "Allowed to proxy", but not > "Anonymous Access" or "Ignore Attribute Management via this Tool". > > The SOAP response revealed in the debug logs is virtually identical to > the example response at https://wiki.jasig.org/display/CASUM/SAML+1.1except > the response I get has no AttributeStatement block. In addition to > the configuration I previously posted and changing CASValidateURL to > https://fortran.its.unb.ca/cas/samlValidate, I've also added the > following server-level directives: > > CASAttributePrefix UNB_ > CASAttributeDelimiter ; > > And also "CASAuthNHeader UNBAUTH" in the Location directive for the > protected service. The closest thing I see to headers from CAS is the > HTTP_UNBAUTH header (HTTP_CAS_USER if I remove CASAuthNHeader) set to my > username or the MOD_AUTH_CAS_S header. > > Should the attributes released be accessible as HTTP headers? What I've > found so far indicates they should if I set CASAttributePrefix (or both > CASAttributePrefix and CASAuthNHeader according to some search results), > but any concrete examples using mod_auth_cas seem to deal strictly with > using the attributes for Apache authorization and require a patch from > MAS-60. > > On 2012-01-18, at 21:09, Matt Smith wrote: > > Joel, > > If you are looking to use SAML, set CASValidateURL to the SAML endpoint > on your server, likely https://fortran.its.unb.ca/cas/samlValidate . > Right now, your configuration is attempting to speak SAML to your CASv2 > protocol endpoint (sorry I didn't catch that sooner). > > HTH, > -Matt > > On Wed, Jan 18, 2012 at 8:12 AM, Joel Goguen <joel.gog...@unb.ca> wrote: > >> Hi Matt, >> >> I am running behind Apache via AJP. Adding debug logging shows that >> mod_auth_cas seems to be posting to what I think is the right URL with the >> wrong parameters; the POST request is sent to >> https://fortran.its.unb.ca/cas/serviceValidate?TARGET=https%3a%2f%2fwebtest.its.unb.ca%2fcas-dev%2fwith >> Content-Type text/xml and Content-Length 382, but no indication of >> what the content may be. I would have expected the POST request to go to >> https://fortran.its.unb.ca/cas/serviceValidate?service=https%3a%2f%2fwebtest.its.unb.ca%2fcas-dev%2f&ticket=ST-1-mar9N3FJDp2LbT6U274g-cas >> or to https://fortran.its.unb.ca/cas/serviceValidate with the service >> and ticket as POST data. >> >> If I look for the ticket associated with the request in log files, all >> I see is this, which in context are the lines associated with my successful >> authentication and CAS redirecting me to the service with my shiny new >> ticket. >> >> /var/log/tomcat6/cas.log:2012-01-18 08:51:12,644 DEBUG >> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Added ticket >> [ST-1-mar9N3FJDp2LbT6U274g-cas] to registry. >> /var/log/tomcat6/cas.log:2012-01-18 08:51:12,645 INFO >> [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket >> [ST-1-mar9N3FJDp2LbT6U274g-cas] for service >> [https://webtest.its.unb.ca/cas-dev/] >> for user >> [jgoguen<https://webtest.its.unb.ca/cas-dev/%5D%20for%20user%20%5Bjgoguen> >> ] >> /var/log/httpd/ssl_error_log:[Wed Jan 18 08:51:12 2012] [debug] >> ajp_header.c(599): ajp_unmarshal_response: Header[6] [Location] = [ >> https://webtest.its.unb.ca/cas-dev/?ticket=ST-1-mar9N3FJDp2LbT6U274g-cas] >> >> Searching the Apache logs on the service's server, I only have this: >> >> /var/log/httpd/ssl_access_log:131.202.75.5 - - [18/Jan/2012:08:51:12 >> -0400] "GET /cas-dev/?ticket=ST-1-mar9N3FJDp2LbT6U274g-cas HTTP/1.1" 401 486 >> /var/log/httpd/ssl_error_log:[Wed Jan 18 08:51:12 2012] [debug] >> mod_auth_cas.c(607): [client 131.202.75.5] Modified r->args (old >> 'ticket=ST-1-mar9N3FJDp2LbT6U274g-cas', new ''), referer: >> https://fortran.its.unb.ca/cas/login?service=https%3a%2f%2fwebtest.its.unb.ca%2fcas-dev%2f >> >> I realized a crucial difference between our production environment and >> development: production does not have "CASValidateSAML On" in auth_cas.conf >> while the development environment does. If I remove CASValidateSAML from >> the development service, everything works perfectly and the serviceValidate >> POST request is done exactly as I would have expected. Is there perhaps an >> issue with newer versions of mod_auth_cas (I'm using 1.0.9.1) with CAS >> Server 3.3.5 when enabling SAML? >> >> On 2012-01-17, at 20:14, Matt Smith wrote: >> >> Joel, >> Is your CAS server running behind an Apache server (via AJP)? It appears >> that the ticket is somehow being dropped from the validation request. Could >> you increase either the CAS logging or the Apache logging (if CAS is behind >> Apache) to show the parameters of the validation request? >> -Matt >> On Jan 17, 2012 10:14 AM, "Joel Goguen" <joel.gog...@unb.ca> wrote: >> >>> I'm using CAS 3.3.5 (which we're unfortunately stuck on due to some >>> vendor compatibility issues) with Apache 2.2.3 and mod_auth_cas 1.0.9.1 to >>> try and protect a directory so I can do some testing with SAML attributes. >>> What I'm actually getting is the protected directory failing with HTTP401 >>> and the CAS ticket being left in the URL. There are no other authentication >>> mechanisms in any higher directory. I'm not sure what information would be >>> useful, so if I've missed something important please let me know. >>> >>> In auth_cas.conf I've set these server directives: >>> LoadModule auth_cas_module modules/mod_auth_cas.so >>> CASVersion 2 >>> CASLoginURL https://fortran.its.unb.ca/cas/login >>> CASValidateURL https://fortran.its.unb.ca/cas/serviceValidate >>> CASProxyValidateURL https://fortran.its.unb.ca/cas/proxyValidate >>> CASCookiePath /var/cache/apache/mod_auth_cas/ >>> CASCertificatePath /etc/pki/tls/certs/ca-bundle.crt >>> CASAllowWildcardCert On >>> CASValidateServer Off >>> CASValidateSAML On >>> CASDebug On >>> >>> In ssl.conf, at the VirtualHost level, I set "LogLevel debug" to get >>> debug logs printed out. I have the following Location directive for the >>> protected directory: >>> <Location /cas-dev> >>> Options +ExecCGI >>> AuthType CAS >>> CASScope / >>> Require valid-user >>> AddHandler cgi-script .cgi >>> </Location> >>> >>> When I try to access this directory, Apache's logs (filtered for >>> mod_auth_cas) give me: >>> === Initial request: === >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(1745): [client >>> 131.202.75.5] Entering cas_authenticate() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(519): [client >>> 131.202.75.5] entering getCASService() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(539): [client >>> 131.202.75.5] CAS Service 'https%3a%2f%2fwebtest.its.unb.ca >>> %2fcas-dev%2findex.cgi' >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(485): [client >>> 131.202.75.5] entering getCASLoginURL() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(462): [client >>> 131.202.75.5] entering getCASGateway() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(555): [client >>> 131.202.75.5] entering redirectRequest() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(567): [client >>> 131.202.75.5] Adding outgoing header: Location: >>> https://fortran.its.unb.ca/cas/login?service=https%3a%2f%2fwebtest.its.unb.ca%2fcas-dev%2findex.cgi >>> >>> === After successful authentication and redirection from CAS === >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(1745): [client >>> 131.202.75.5] Entering cas_authenticate() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(607): [client >>> 131.202.75.5] Modified r->args (old 'ticket=ST-3-eiSBy0oqb2BBL2df7gDc-cas', >>> new '') >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(1600): [client >>> 131.202.75.5] entering getResponseFromServer() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(519): [client >>> 131.202.75.5] entering getCASService() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(539): [client >>> 131.202.75.5] CAS Service 'https%3a%2f%2fwebtest.its.unb.ca >>> %2fcas-dev%2findex.cgi' >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(1674): [client >>> 131.202.75.5] Validation response: <cas:serviceResponse xmlns:cas=' >>> http://www.yale.edu/tp/cas'>\n\t<cas:authenticationFailure >>> code='INVALID_REQUEST'>\n\t\t'service' and 'ticket' >>> parameters are both >>> required\n\t</cas:authenticationFailure>\n</cas:serviceResponse> >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(1293): [client >>> 131.202.75.5] entering isValidCASTicket() >>> [Tue Jan 17 11:04:17 2012] [debug] mod_auth_cas.c(1299): [client >>> 131.202.75.5] MOD_AUTH_CAS: response = <cas:serviceResponse xmlns:cas=' >>> http://www.yale.edu/tp/cas'>\n\t<cas:authenticationFailure >>> code='INVALID_REQUEST'>\n\t\t'service' and 'ticket' >>> parameters are both >>> required\n\t</cas:authenticationFailure>\n</cas:serviceResponse> >>> >>> On the CAS server, I have these logging properties set: >>> log4j.rootLogger=INFO, logfile >>> log4j.appender.logfile=org.apache.log4j.RollingFileAppender >>> log4j.appender.logfile.File=/var/log/tomcat6/cas.log >>> log4j.appender.logfile.MaxFileSize=10120KB >>> log4j.appender.logfile.MaxBackupIndex=10 >>> log4j.appender.logfile.layout=org.apache.log4j.PatternLayout >>> log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n >>> log4j.logger.org.springframework=WARN >>> log4j.logger.org.jasig=INFO >>> log4j.logger.org.jasig.cas.web.flow=INFO >>> log4j.logger.org.jasig.cas=DEBUG >>> >>> All I get in cas.log when I authenticate is this: >>> 2012-01-17 11:04:17,166 DEBUG >>> [org.jasig.cas.web.support.CasArgumentExtractor] - Extractor generated >>> service for: https://webtest.its.unb.ca/cas-dev/index.cgi >>> 2012-01-17 >>> <https://webtest.its.unb.ca/cas-dev/index.cgi2012-01-17>11:04:17,168 DEBUG >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - >>> Attempting to retrieve ticket >>> [TGT-1-cyZZbf6fjsz6tWtEPZYJ00bmkVLSwSg5INB7Dr03uRGXxCvDNN-cas] >>> 2012-01-17 11:04:17,168 DEBUG >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Ticket >>> [TGT-1-cyZZbf6fjsz6tWtEPZYJ00bmkVLSwSg5INB7Dr03uRGXxCvDNN-cas] found in >>> registry. >>> 2012-01-17 11:04:17,168 DEBUG >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Added ticket >>> [ST-3-eiSBy0oqb2BBL2df7gDc-cas] to registry. >>> 2012-01-17 11:04:17,168 INFO >>> [org.jasig.cas.CentralAuthenticationServiceImpl] - Granted service ticket >>> [ST-3-eiSBy0oqb2BBL2df7gDc-cas] for service [ >>> https://webtest.its.unb.ca/cas-dev/index.cgi] for user [jgoguen] >>> 2012-01-17 11:04:17,168 DEBUG >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Attempting to >>> retrieve ticket >>> [TGT-1-cyZZbf6fjsz6tWtEPZYJ00bmkVLSwSg5INB7Dr03uRGXxCvDNN-cas] >>> 2012-01-17 11:04:17,168 DEBUG >>> [org.jasig.cas.ticket.registry.DefaultTicketRegistry] - Ticket >>> [TGT-1-cyZZbf6fjsz6tWtEPZYJ00bmkVLSwSg5INB7Dr03uRGXxCvDNN-cas] found in >>> registry. >>> 2012-01-17 11:04:17,238 DEBUG >>> [org.jasig.cas.web.support.CasArgumentExtractor] - Extractor did not >>> generate service. >>> >>> I have two services defined currently, >>> https://fortran.its.unb.ca/cas/services/** and >>> https://webtest.its.unb.ca/**, but I get the same result (except the >>> first cas.log line is the same as the last line) if I remove all service >>> definitions. Any assistance with getting authentication working would be >>> greatly appreciated. >>> >>> -- >>> Joel Goguen >>> Developer >>> Enterprise Solutions >>> Information Technology Services >>> University of New Brunswick >>> E-mail: jgog...@unb.ca >>> Phone: (506) 453-4872 >>> Fax: (506) 453-3590 >>> >>> >>> >>> -- >>> You are currently subscribed to cas-user@lists.jasig.org as: >>> m...@forsetti.com >>> 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: >> joel.gog...@unb.ca >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> >> -- >> Joel Goguen >> Developer >> Enterprise Solutions >> Information Technology Services >> University of New Brunswick >> E-mail: jgog...@unb.ca >> Phone: (506) 453-4872 >> Fax: (506) 453-3590 >> >> -- >> You are currently subscribed to cas-user@lists.jasig.org as: >> m...@forsetti.com >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> >> > > > -- > m...@forsetti.com > Key ID:7208B5B4 > > -- > You are currently subscribed to cas-user@lists.jasig.org as: > joel.gog...@unb.ca > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > Joel Goguen > Developer > Enterprise Solutions > Information Technology Services > University of New Brunswick > E-mail: jgog...@unb.ca > Phone: (506) 453-4872 > Fax: (506) 453-3590 > > -- > You are currently subscribed to cas-user@lists.jasig.org as: m...@forsetti.com > 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: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
