I am using mod_auth_cas release 1.0.9.1, and am trying to work with the CAS REST API (as outlined here: https://wiki.jasig.org/display/casum/restful+api), but am having difficulties.

In my Apache configuration, I am allowing all access to the "/cas" endpoint, and then using "AuthType CAS" and "Require valid-user" for the "/doug" endpoint (my test application). For normal operation, everything is working great. But now I have enabled the CAS REST service to allow a headless application to access the CAS-protected resources.

To test this, I have followed the behavior outlined in the above link and written a Java client that requests a TGT resource from /cas/v1/tickets and then with that in hand, requests a service ticket. That part works wonderfully. Once it has a service ticket in hand, it tries to access the "/doug" endpoint, appending "?ticket=" to the end of the URL, but the result is that it is presented with the CAS login page instead of the desired resource.

I took a look at the Apache logs (I can post them if that would help), and it looks as if mod_auth_cas is, in fact reading the service ticket and even validating it against CAS (I see the "serviceResponse" XML with an "authenticationSuccess" element and my username).

But right after that, it shows that a cookie is placed as a header (MOD_AUTH_CAS_S), and then the connection is closed. Then I see a new connection, in which the "Require valid-user" directive fails, and then mod_auth_cas redirects to the CAS login URL, and that's where it ends.

I feel like my client is working properly because it works when trying to access a web application that is configured to directly use CAS (with the Java cas-client-core libraries) instead of using mod_auth_cas. But I definitely may be overlooking something (such as that cookie header?).

If the url does not contain any parameters then authorization does not work. Probably the problem is in function removeCASParams or getCASTicket. As you see in below LOG1, after cleaning ticket parameter there is garbage in r->args. (second log line was added by me into mod_auth_cas.c). If I call apache with any parameter (?x=1) r->args is cleaned properly (compare LOG2).
To resolve this problem I've substituted code of getCASTicket and removeCASParams with jasig code from thei repo:
https://source.jasig.org/cas-clients/mod_auth_cas/trunk

LOG1:
[Wed May 30 11:22:50 2012] [debug] mod_auth_cas.c(1929): [client xxx] Entering cas_authenticate()
[Wed May 30 11:22:50 2012] [debug] mod_auth_cas.c(604): [client xxx] removeCASParams: r->args 'ticket=ST-883649-fhqUUM1dEIpv6Sbk5oRk-cas'
[Wed May 30 11:22:50 2012] [debug] mod_auth_cas.c(635): [client xxx] Modified r->args (now '\x99\x0c\xd9\x7f')

LOG2:
[Wed May 30 11:20:46 2012] [debug] mod_auth_cas.c(604): [client xxx] removeCASParams: r->args 'x=1&ticket=ST-883616-d2isIFGY9wLedDIoipzD-cas', [...]
[Wed May 30 11:20:46 2012] [debug] mod_auth_cas.c(635): [client xxx] Modified r->args (now 'x=1'), referer: [...]

Reported by @dhawes

"configure" includes "am__api_version='1.15'", causing a problem building on systems with automake<1.15

autoreconf fixes configure to use local version

am__api_version should be effectively ignored (vi 'missing' script) unless a rebuild of configure is triggered.

Conversation on commit 38adbae

Implement a logout handler which deletes the local CAS session and redirects to the global CAS logout page.

Hello,

I have noticed in the readme that single sign out is not supported. Is there a chance that this can be added as a feature? It is very important from a security point-of-view for my application.

I had some possible ideas that might allow it to work:

1. Have all requests go through the cas server, similar to when you first must do cas login (i.e. https://cas.example.com/cas/login?service=https%3a%2f%2fmyapp.example.com%3a8082%2f
2. When the user logs out from CAS server, modify the cookies or delete the cookies in mod_auth_cas (mentioned here: https://groups.google.com/forum/#!topic/jasig-cas-user/f3z_sJ4stXc)

Thank you

./configure && make touches versioned files and it really gets my goat: it clutters the output of git status and makes me accidentally commit files that shouldn't be.

To wit:

$ git status -s
 M aclocal.m4
 M configure
 M libtool

I want to replace the generated files with a buildconf script. People who checkout the repo are smart enough to know to run it and for releases we do the buildconf step ourselves so the tarball has a ready to run configure script.

Sounds like a plan?

EDIT: Another benefit is that it will stop GitHub from reporting mod_auth_cas as a shell script project.

The recent CAS Client Security Vulnerability CVE-2014-4172 lists 3 clients that are affected (Java, .NET, php) and states that "There may be other CAS clients that are vulnerable."

I've searched the page listed above as well as the related comments page and there is no mention of mod_auth_cas one way or the other.

So I wanted to reach out to you here to see if you could confirm whether or not mod_auth_cas is vulnerable to CVE-2014-4172.

FWIW I'm currently running version 1.0.8 - provided by Ubuntu package management (noticed the current version here is 1.0.10).

Could you please add a header to the 302 request so that AJAX code can differentiate between this and, say, a regular 302 that happens in the application. My I suggest X-Authenticate: Redirect, but really, anything will work so long as it's unique enough to key an AJAX application. Having it configurable would be lovely as well.

Adding apr_table_add(r->headers_out, "X-Authenticate", "Redirect"); to redirectRequest.

Example:

$ mkdir build
$ cd build
$ ../mod_auth_cas/configure
$ make

This ought to work, but it doesn't. Instead, I have to ./configure && make directly in the repository I pulled.

Thanks,
Carl

$ ./configure --with-apxs=$PWD/tmp/apxs2
<snip>
checking for Apache apxs... /Users/bnoordhuis/src/mod_auth_cas/tmp/apxs2
checking for apxs... /usr/sbin/apxs
configure: apxs found at /usr/sbin/apxs
<snip>

And indeed, the Makefile uses the wrong one:

$ grep -n apxs src/Makefile
123:APXS = /usr/sbin/apxs
254:with_apxs = /Users/bnoordhuis/src/mod_auth_cas/tmp/apxs2
561:    /usr/sbin/apxs -c ${LIBS} -Wc,"${CPPFLAGS} ${AM_CPPFLAGS} ${CFLAGS} ${AM_CFLAGS}" -Wl,"${AM_LDFLAGS} ${LDFLAGS} ${AM_LIBS} ${LIBS}" mod_auth_cas.c cas_saml_attr.c
565:    /usr/sbin/apxs -i -S LIBEXECDIR=${DESTDIR}${APXS_LIBEXECDIR} mod_auth_cas.la

We want to have "CASScope /" by default, how to?

Hello,
With colleagues in my company, we are currently trying to fix issues with an application relying on mod_auth_cas for authentication. Some problems are related to certificates. Some others are related to the format of URI in a complex connection chain.

Let's have a look to an architecture schema:

internal user <-> browser <-----------+-----------------+
                                      |                 |
                              internal frontend <-> internal cas
                                      ^         *       ^
                                      |                 |
                                      v                 v
                              internal database   internal directory
                                      ^                 ^
                                      |                 |
~~~~~~~~~~~ LAN / DMZ BOUNDARY ~~~~~~~|~~~~~~~~~~~~~~~~~|~~~~~~~~~~~
                                      v                 v
                              external frontend <-> external CAS
                                      ^               ^  ^    /\$$
====== DMZ / INTERNET BOUNDARY =======|===============|==|====||===
                                      v               |  |    ||
external user <-> browser <-----------+---------------+  |    ||
                                      |                  |    ||
partner user <-> browser <------------+------------------+    ||
                                                              ||
====== DMZ / INTERNET BOUNDARY ===============================||===
                                                              \/
                                                     partner CAS
                                                          ^
                                                          |
                                                          v
                                                     whatever ???

Our certificate issues occur on the connection side indicated by the *, and are not the subject here.

Our other problem with URI occurs on the connection side indicated by the $$. Here are some explanations:

Some users from a partner are supposed to use our application. When such an user requests a first page on external frontend, external CAS login page displays, and offer her/him an alternate authentication scheme. If she/he selects this scheme, her/his browser is redirected to the partner's CAS login page. Once she/he authenticates there, tickets are sent back, our external CAS validates with partner's CAS, then generates its own tickets, then allows access to partner user.

Our problem is: When validating partner's tickets, our CAS fails because the original service's URI has been encoded in lowercase by mod_auth_cas!

The partner user requests the following URI:

http://frontend.myorg.tld/MYAPP/index.do

The mod_auth_cas module in the Apache frontend instantly redirects the browser to:

https://cas.myorg.tld/cas/login?service=http%3a%2f%2ffrontend.myorg.tld%2fMYAPP%2findex.do

Note that the URI has been encoded by mod_auth_cas in lowercase: %3a, %2f

In the external CAS login page, the partner user clicks a button to redirect to partner's CAS. In the browser, the URI appears to be:

https://cas.partner.tld/cas/login?service=https://cas.myorg.tld/cas/login?service=http%3a%2f%2ffrontend.myorg.tld%2fMYAPP%2findex.do

After the user has succesfully authentified, the browser is redirected back to the external CAS login page, wich displays a failure message, though the URI is:

https://cas.myorg.tld/cas/login?service=http%3a%2%2ffrontend.myorg.tld%2fMYAPP%2findex.do&ticket=ST-xxxx

Unfortunately, the partner's technical team was in a "our platform is perfect. problem comes from your platform. we won't spend neither lab platform nor time to help" state of mind. However, looking at some logs, they eventually told us that if the URI were encoded in uppercase they would work (how they found out, we don't know). With some hand-editing in a browser, we could verify that it was true!

There were some more argument about "your platform doesn't conform to internet RFCs", but we checked that lowercase is valid, though not adviced:

https://tools.ietf.org/html/rfc3986#section-2.1
The uppercase hexadecimal digits 'A' through 'F' are equivalent to the lowercase digits 'a' through 'f', respectively. If two URIs differ only in the case of hexadecimal digits used in percent-encoded octets, they are equivalent. For consistency, URI producers and normalizers **should use uppercase hexadecimal digits** for all percent-encodings.

As the mod_auth_cas module is embedded in a global software solution provided by an ISV, we couldn't modify it from a custom fork of mod_auth_cas source code (both for contracting and technical issues).

However we had to do something, so eventually we solved that by hex-editing the mod_auth_cas.so Windows DLL (yes, for some reason, frontend Apache runs on a Windows platform).
This dirty fix works like a charm, and is today in production.
But this is not satisfactory, as everything could go kaboom the next time the ISV provides a patch or an update.

In order to get a more professional and stable solution, here are some questions and proposals:

1. Did anyone ever encounter such a situation? Any idea of root cause (we spent some time looking at settings and logs from firewalls, proxies ...)? Any idea of some seemingly harmless default setting to change on either mod_auth_cas, Apache, cas server, whatever ... to fix this?
2. We could ask ISV to build the mod_auth_cas.so from a custom fork of public source code. But it would be easier to have them agree if a solution is provided in the public, official trunk here in github. Moreover, this would benefit to everyone in the community. We understand that RFC3986 is clear that lowercase percent encoding is valid, so the mod_auth_cas community has no reason to take care, but this is true life in the true world of interconnected, distributed information systems: Offering a possible solution for that problem when it occurs is a nice-to-have (if there is no other simpler solution through setting, of course).

Here is some results of our investigations: Responsible code is getCASService() function from line 540 to line 583 in mod_auth_cas.c:

/*
 * Responsible for creating the 'service=' parameter.  Constructs this
 * based on the contents of the request_rec because r->parsed_uri lacks
 * information like hostname, scheme, and port.
 */
char *getCASService(const request_rec *r, const cas_cfg *c)
{
    const apr_port_t port = r->connection->local_addr->port;
    const apr_byte_t ssl = isSSL(r);
    const apr_uri_t *root_proxy = &c->CASRootProxiedAs;
    char *scheme, *port_str = "", *service;
    apr_byte_t print_port = TRUE;

#ifdef APACHE2_0
    scheme = (char *) ap_http_method(r);
#else
    scheme = (char *) ap_http_scheme(r);
#endif

    if (root_proxy->is_initialized) {
        service = apr_psprintf(r->pool, "%s%s%s%s",
            escapeString(r, apr_uri_unparse(r->pool, root_proxy, 0)),
            escapeString(r, r->uri),
            (r->args != NULL ? "%3f" : ""),
            escapeString(r, r->args));
    } else {
        if (ssl && port == 443)
            print_port = FALSE;
        else if (!ssl && port == 80)
            print_port = FALSE;

        if (print_port)
            port_str = apr_psprintf(r->pool, "%%3a%u", port);

        service = apr_pstrcat(r->pool, scheme, "%3a%2f%2f",
            r->server->server_hostname,
            port_str, escapeString(r, r->uri),
            (r->args != NULL && *r->args != '\0' ? "%3f" : ""),
            escapeString(r, r->args), NULL);
    }
    if (c->CASDebug)
        ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "CAS Service '%s'", service);
    return service;
}

Instead of using in-line hard-coded string constants (the "culprits" here: "%%3a%u", "%3a%2f%2f", "%3f" twice), there could be some #DEFINEs:

#DEFINE CAS_FORMAT_PORT_LOWER "%%3a%u"
#DEFINE CAS_FORMAT_PORT_UPPER "%%3A%U"
#DEFINE CAS_FORMAT_SEP_LOWER "%3a%2f%2f"
#DEFINE CAS_FORMAT_SEP_UPPER "%3A%2F%2F"
#DEFINE CAS_FORMAT_QUESTION_LOWER "%3f"
#DEFINE CAS_FORMAT_QUESTION_UPPER "%3F"

The same is true for urlEncode() from line 836 to line 882:

char *urlEncode(const request_rec *r, const char *str,
                                const char *charsToEncode)
{
    char *rv, *p;
    const char *q;
    size_t i, j, size, limit, newsz;
    char escaped = FALSE;

    if(str == NULL)
        return "";

    size = newsz = strlen(str);
    limit = strlen(charsToEncode);

    for(i = 0; i < size; i++) {
        for(j = 0; j < limit; j++) {
            if(str[i] == charsToEncode[j]) {
                /* allocate 2 extra bytes for the escape sequence (' ' -> '%20') */
                newsz += 2;
                break;
            }
        }
    }
    /* allocate new memory to return the encoded URL */
    p = rv = apr_pcalloc(r->pool, newsz + 1); /* +1 for terminating NULL */
    q = str;

    do {
        escaped = FALSE;
        for(i = 0; i < limit; i++) {
            if(*q == charsToEncode[i]) {
                sprintf(p, "%%%x", charsToEncode[i]);
                p+= 3;
                escaped = TRUE;
                break;
            }
        }
        if(escaped == FALSE) {
            *p++ = *q;
        }

        q++;
    } while (*q != '\0');
    *p = '\0';

    return(rv);
}

Here the string constant to convert to a #DEFINE is "%%%x". There could be:

#DEFINE CAS_FORMAT_URLENCODE_LOWER "%%%x"
#DEFINE CAS_FORMAT_URLENCODE_UPPER "%%%X"

AND this could be switched back and forth in adding a new configuration directive that could be:

Directive:       CASUriEncoding
Default:         lower
Possible values: lower|upper

If you arrived here, thanks for reading ;-).
Any answer, advice, clue, comments ... are welcome!

This issue (from 2011) is still present in the latest tagged release:
https://issues.jasig.org/browse/MAS-66

I figured using the tagged releases was the way to go. Which one should I be using?

Hi

As Debian repositories have mod_auth_cas version 1.0.9 and seems there are some issues with the Require cas-attribute directive that were fixed on 1.1 (#57) resulting in: Unknown Authz provider: cas-attribute, we decided to build and copy the library to our apache 2.4 server.

Just built mod_auth_cas.so on another system and copied to /usr/lib/apache2/modules/mod_auth_cas.so
ldd show's everything is ok.

Although Require cas-attribute now doesn't throw anything, setting CASAuthoritative On on apache configuration complains with:

Invalid command 'CASAuthoritative', perhaps misspelled or defined by a module not included in the server configuration

Thers's something we can do to help fixing it?

Would it be possible you become the mantainers for Debian/Ubuntu repos?

Regards

when i access different urls in the same application.

I am using the 1.0.9.1 release version of mod_auth_cas (dated 13 DEC 2010).

I have been able to successfully configure mod_auth_cas to trust the CAS server's SSL certificate using the CASCertificatePath directive. However, in the case where the CAS server requires a client certificate, mod_auth_cas is failing to validate the service ticket. I cannot find any configuration options to specify a certificate for the outbound connection.

After enabling "debug" logging on the Apache server and enabling the CASDebug option, I was able to find the following in Apache's "ssl_error_log":

[:debug] [pid 973] mod_auth_cas.c(539): [client 127.0.0.1:44847] CAS Service '[TargetURL]', referer: [CASLoginURL]?service=[TargetURL]
[ssl:info] [pid 974] [client 127.0.0.1:44853] AH01964: Connection to child 4 established (server [MyServer]:443)
[ssl:debug] [pid 974] ssl_engine_kernel.c(1913): [client 127.0.0.1:44853] AH02043: SSL virtual host for servername [MyServer] found
[ssl:info] [pid 974] [client 127.0.0.1:44853] AH02008: SSL library error 1 in handshake (server [MyServer]:443)
[ssl:info] [pid 974] SSL Library Error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate -- No CAs known to server for verification?
[ssl:info] [pid 974] [client 127.0.0.1:44853] AH01998: Connection closed to child 4 with abortive shutdown (server [MyServer]:443)
[ssl:info] [pid 971] [client 127.0.0.1:44854] AH01964: Connection to child 1 established (server [MyServer]:443)
[ssl:info] [pid 971] [client 127.0.0.1:44854] AH02008: SSL library error 1 in handshake (server [MyServer]:443)
[ssl:info] [pid 971] SSL Library Error: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate -- No CAs known to server for verification?
[ssl:info] [pid 971] [client 127.0.0.1:44854] AH01998: Connection closed to child 1 with abortive shutdown (server [MyServer]:443)
[:debug] [pid 973] mod_auth_cas.c(1666): [client 127.0.0.1:44847] MOD_AUTH_CAS: curl_easy_perform() failed (NSS: client certificate not found (nickname not specified)), referer: [CASLoginURL]?service=[TargetURL]

I attempted to install the appropriate certificate into my NSS certificate db (CentOS 7: /etc/pki/nssdb), but that did not seem to help. I also attempted to set the Apache SSLProxyMachineCertificateFile directive, but that had no effect either.

My specific configuration is such that both Apache and CAS (Tomcat) run on the same server, with Apache proxying requests to CAS via AJP/mod_proxy. Therefore, in this specific instance, when mod_auth_cas attempts to validate the service ticket, it is sending a request back to the Apache web server, which then proxies it to CAS. This works great until I configure Apache to require a client certificate, at which point I see the above log output and receive a 401 error in the browser.

I have a website which is protected by mod_auth_cas.

When I open an URL like
https://host.example.org/test.php?t=other&other=testing I get correctly redirected to the SSO application. The target-URL looks like this: https://sso.example.org/login?service=https%3a%2f%2fhost.example.org%2ftest.php%3ft%3dother%26other%3dtesting.

When I login and get redirected back, the SSO-Application redirects me to https://host.example.org/test.php?t=other&other=testing&ticket=ST-12345.

Now the error happens: mod_auth_cas redirects me to
https://host.example.org/test.php?t%3dother%26other%3dtesting instead of https://host.example.org/test.php?t=other&other=testing.

It appears this bug was introduced with version 1.0.8: http://www.mail-archive.com/[email protected]/msg00480.html

It would be nice to implement a redirectAfterValidation boolean like the java cas client has to disable sending the 302 on successful ticket validation.

See PR #89

README states:

We welcome your feedback, suggestions and contributions. Contact us
via email if you have questions, feedback, code submissions,
and bug reports.  To reach the development team, send an e-mail to:

cas-user [at] apereo [dot] org

However, sending an email returns:

We're writing to let you know that the group you tried to contact (cas-user) may not exist, or you may not have permission to post messages to the group

Providing Google's Group link instead would be great.

Regards

I have httpd 2.2 application servers behind a reverse proxy. My virtualhost configuration looks something like this:

<VirtualHost *:80>
    ServerName https://example.com:443

    ...

    UseCanonicalName On
</VirtualHost>

Based on the UseCanonicalName setting, all self-referential URLs generated by mod_auth_cas should respect my configuration settings. However, because mod_auth_cas bypasses ap_construct_url for URL construction in favor of its own algorithm, it gets the URL wrong.

mod_auth_cas will construct https://example.com:80 with the above configuration, when it should construct https://example.com or https://example.com:443.

I'm fairly new to httpd and mod_auth_cas internals, so let me know if I'm missing something key here.

The docu does say that libpcre-7.8 is specifically required. I installed libpcre using Yum:

yum install pcre

and ended up with 8.21-5.3.amzn1.

Now, I'm getting the following when running ./configure:

checking for pcre_compile in -lpcre... no
configure: error: libpcre required

Can I get some more info on what specific it's looking for? Is this a problem with my version of libpcre or maybe it's expecting it at a different location?

Hello,
With colleagues in my company, we are currently trying to fix issues with an application relying on mod_auth_cas for authentication. Problems are related to certificates.
For some reasons, the application is running on a Windows platform (not the best choice from my point of view).
In order to verify various possibilities, we have to stop Apache service, modify certificate files, restart Apache service, do some testing, try to understand traces in log files and failing behavior from the end user point of view.

After doing some testing, we are puzzled. The behaviour is not as expected, which means: sometime we expect the ticket validation to NOT work, but it works ; sometime we expect it to work, and it doesn't.

Considering debug information in the Apache error.log, we wonder whether there could be some caching issue disturbing our tests. Traces show messages like:

entering createCASCookie()
entering CASCleanCache()
Beginning cache clean
Processing cache file '003804ec667d42f309de1adb6348fc14'
entering readCASCacheFile()
entering deleteCASCacheFile()
entering readCASCacheFile()
Removing expired cache entry '003804ec667d42f309de1adb6348fc14'
entering writeCASCacheEntry()
entering readCASCacheFile()
Processing cache file 'd95bf315dea2af9eea8a4d45c488cd1e'
entering readCASCacheFile()
entering writeCASCacheEntry()
Cookie '6101dcbbc1a1162f29baf424b467d950' created for user 'username'
entering setCASCookie()
...

We wonder if this CASCache feature is not the culprit for strange, unexpected behaviour. Some user sessions' information previously validated would remain, then the user would be authenticated though certificate file has been changed?
A clue to confirm this is that, if we wait long enough before doing some new tests, possibly overcoming timeouts (CASTimeout, CASIdleTimeout, CASCacheCleanInterval), behaviour seems more logical.

Question: Is there a simple way to force the CASCache to be totally wiped out, when needed after some important configuration change (here, certificate file replacement)?

Thanks for any answer or feedback,

I ran into a small issue during installation and I'm listing here FYI and for anyone that might be having problems with this.

After I start the installation:

$ ./configure && make && sudo make install

I receive this during the installation process:

/home/myuser/source/mod_auth_cas/mod_auth_cas/missing: line 81: aclocal-1.15: command not found
WARNING: 'aclocal-1.15' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [aclocal.m4] Error 127

Then I need to run autoconf:

$ autoreconf -f -i

Then run the install one more time:

$ ./configure && make && sudo make install

And now it installed.

I have what I would consider a strange issue. First the specs:
CentOS 7
Apache 2.4
mod_auth_cas 1.0.9.1 from https://github.com/djjudas21/mod_auth_cas to build RPM with SSL-CA-chains.patch from https://github.com/klausdieterkrannich/mod_auth_cas

Using the above configuration, I can authenticate to a directory with .htaccess setting "AuthType Cas" using AllowOverride All in the <directory ...> configuration section for that path. However, trying to put the AuthType Cas directive into the Apache config itself fails, it doesn't even attempt to redirect to our CAS service.

auth_cas.conf

LoadModule auth_cas_module modules/mod_auth_cas.so

CASDebug on

# Cookie path must be given as an absolute path with a trailing slash
CASCookiePath /var/run/mod_auth_cas/

# Certificate path may be a file or a directory of certificates symlinked by
# their hashed names
CASCertificatePath /etc/pki/tls/certs/ca-bundle.crt

# The URL to the CAS server - Production
CASLoginURL https://cas.domain.com/cas/login
CASValidateURL https://cas.domain.com/cas/serviceValidate
CASProxyValidateURL https://cas.domain.com/cas/proxyValidate

#CASValidateServer Off

test.conf

<Directory /var/www/html/testdir>
  AllowOverride All
  Require all granted
</directory>

If I put "AuthType Cas" in the test.conf file it gets ignored, though it works in .htaccess, with all other settings the same.

<Directory /var/www/html/testdir>
  AllowOverride All
  Require all granted
  AuthType Cas
</directory>

Hi,

I've been using the mod_auth_cas, and tried to execute a redirect by user.
In order to do so, I'm trying to use the Apache RewriteRule with the cas headers.

I've been trying unsuccessfully to locate the exact headers name.

I would really appreciate if you could help me with,

Thanks in advance,
Tal

CONTACT INFORMATION AND WEBSITE

We welcome your feedback, suggestions and contributions. Contact us
via email if you have questions, feedback, code submissions,
and bug reports. To reach the development team, send an e-mail to:

cas-user [at] apereo [dot] org

Emails to [email protected] as noted at the bottom of the README are returned with:

"the group you tried to contact (cas-user) may not exist"

In getCASService() and cas_authenticate(), among other places, the TCP port is determined using r->connection->local_addr->port.

While this gives us the port of the server side of the TCP connection, it is not necessarily the port that the user agent connected to. The difference is that if the Apache server is behind a reverse proxy (such as a load balancer), then r->connection->local_addr->port gives the port of the last hop (labelled "backend connection" in the diagram below), which is irrelevant to the CAS authentication process. What matters is the URL of the resource that the user agent wants to access.

                             Reverse proxy                     Apache with mod_auth_cas
┌────────────┐ Primary ┌───────────────────────┐            ┌────────────────────────────┐
│ User agent │────────→│443                    │            │                            │
└────────────┘ request │  https://example.com  │  Backend   │ http://farm1.internal:3141 │
                       │                       │───────────→│3141                        │
                       └───────────────────────┘ connection └────────────────────────────┘

By using r->connection->local_addr->port, getCASService() will construct https://example.com:3141 as the service URL, which the CAS server will likely not recognize. Then, even if the authentication succeeds, cas_authenticate() will redirect the user agent to https://example.com:3141, where there is no web server running.

The more appropriate replacement for r->connection->local_addr->port is ap_get_server_port(r): the Apache function to "get the current server port". That function consults server_rec->port, which is the same way that CGI establishes the SERVER_PORT environment variable and mod_php establishes $_SERVER['SERVER_PORT'], and how URLs are constructed in various places within Apache (such as in mod_auth_digest.c. Then, if there is a reverse proxy, a module such as mod_rpaf would likely override server_rec->port to do the right thing.

Side note: It should be possible to take advantage of ap_is_default_port() instead of hard-coding 80 and 443 here and here.

Hello.

In my use case my apache is proxyfied and i can't get the redirect set the external address of my server in the service field. The external adress of the server can be found in the header of the original request, inside "host". So i've tried to set a value from my request header into CASRootProxiedAs ... In my httpd.conf i've set something like :

 SetEnvIf Host ".*" HeaderHost=$0
 CASRootProxiedAs http://%{HeaderHost}e

... but when i was trying to make unauthenticated requests to my protected app i was redirected to:

  https://mycasserver.com/cas/login?service=http%3a%2f%2f%25%7bHeaderHost%7de%2ftoto%2ftiti

... in the service field the variable was not solved.

David Hawes from the google group have made a little fix in the code to help me move forward (without CASRootProxiedAs, by setting in the service field the value from host (from the request header) instead of the value inside ServerName from httpd.conf). It's working fine until now.

But has "CASRootProxiedAs" exists is it possible to be able to set a variable/calculable expression to this configuration field ?

I'm having a tough time building mod_auth_cas on httpd:2.4.23-alpine (Alpine Linux), as opposed to httpd:2.4.23 (Debian). mod_auth_cas.c imports <error.h>, which isn't provided by musl/libc-dev on Alpine.

Is error.h strictly needed? I scanned through mod_auth_cas.c, but couldn't find an obvious use of it.

Whilst reading the code, I noticed a problem with the configuration merging logic.

Consider the case of setting something to a non-default value in the main server configuration and then wanting to override it to the value that happens to be the default for that setting in a .

Since for non-pointer types the current code does not track the difference between "explicitly set to default value" and "not set so using default value", the merging logic cannot take account of this and will incorrectly ignore the inner scope's setting.

The README.md file references 1.0.10 but the last release tag (three years ago) was for 1.0.9.1.

Please either remove the reference from the README.md (in which case, why are you not 'releasing'?) or create a 1.0.10 release (in which case, will you resume regular releases?).

Thanks.

Hi,

I am trying to configure mod_auth_cas in front of Alfresco.

My Apache configuration is:

`CASCookiePath /tmp/
CASLoginURL https://cas-server-url:9043/cas/login
CASValidateURL https://cas-server-url:9043/cas/serviceValidate

<Location /share>
    AuthType CAS   
    require valid-user
    CASScope /share
</Location>

<Location /alfresco>
    AuthType CAS   
    require valid-user
    CASScope /alfresco
</Location>

    SSLProxyEngine On

#For tge example
SSLProxyVerify none 
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
CASCertificatePath /usr/local/apache2/conf/ssl-socle/cert.crt

SSLVerifyClient optional
SSLOptions +StdEnvVars +ExportCertData  

ProxyPass /alfresco https://localhost:8443/alfresco
ProxyPassReverse /alfresco https://localhost:8443/alfresco

ProxyPass /share https://localhost:8443/share
ProxyPassReverse /share https://localhost:8443/share

`

When I trying to access to https://localhost:9043/share I am redirected to:

https://cas-server-url:9043/cas/login?service=**http**%3a%2f%2flocalhost%3a9043%2fshare

Instead of

https://cas-server-url:9043/cas/login?service=**https**%3a%2f%2flocalhost%3a9043%2fshare

Is there a problem in my configuration or is it a bug ?

Sincerely

Not sure if this is a bug or a feature request (apologies in advance if this is the wrong place), but I have a use case where we want to take the REMOTE_USER (as set by CAS) and set a specific environment value (AJP_REMOTE_USER, so that mod_proxy_ajp will pass REMOTE_USER to the backend server) to this value and am running into issues. Looking online, I tried some mod_rewrite tricks like below:

RewriteCond %{LA-U:REMOTE_USER} (.+)
RewriteRule .* - [E=AJP_REMOTE_USER:%1]

(or just using %{REMOTE_USER}) but it doesn't seem to work and debugging mod_rewrite shows it thinking that the value of REMOTE_USER is null. This seems to be related to he issue talked about briefly here: https://github.com/aimxhaisse/mod-proxy-add-user which suggests that some auth modules set REMOTE_USER in a way that makes it unavailable to mod_rewrite but I confess to not knowing much about Apache module internals.

Environment where I've seen the behavior is RHEL6.5, httpd-2.2.15-30.0.1.el6_5.x86_64, and mod_auth_cas-1.0.9-1 from the EPEL repositories and a fresh build of mod_auth_cas from the git repository.

I worked around the issue a little bit by patching a local copy of mod_auth_cas to implement a feature called CASAuthNEnv that is basically similar to CASAuthNHeader except populating a given environment variable instead of a header The idea being that you can just set something like:
CASAuthNEnv AJP_REMOTE_USER in your Apache conf.

It seems to work in a test environment but I admit to not knowing C or APR so I have no idea if I am doing something horrifyingly wrong - it amounts to setting up the config option and calling:

apr_table_add(r->subprocess_env,d->CASAuthNEnv,remoteUser);
when appropriate.

I have no idea if my use case is extreme edge or if I'm running into a configuration issue, but it'd be a valuable option for my environment at least! (vendor I'm working with doesn't want the header passed via headers, only environment variables).

I have an application protected by CAS behind an f5 BigIP load balancer (their LTM module). The Apache 2.2 host is running in NameVirtualHos mode on port 4000. With CASRootProxiedAs, basic authentication is working, however, CAS is messing up the URL rewrite after serviceValidate. This prevents any deep bookmarks from resolving.

So, if I start with an URL such as https://examplehost-qa.nlm.nih.gov/admin/patron/list?username=b&barcode=&filter=Apply&orderby=-username, then the response comes back as expected with the additional ticket parameter. serviceValidate works, but the final URL is https://examplehost-qa.nlm.nih.gov/admin/patron/list?username%3db%26barcode%3d%26filter%3dApply%26orderby%3d-username

I stumbled upon this because another copy of the application is running on the same host, but on port 80 rather than port 4000. In this case, CASRootProxiedAs is not present, and the parameters come across fine.

Also - running CentOS 6.x with mod_auth_cas 1.0.9.1-1 from EPEL rpm. I may try to run a more recent release before creating a pull request/looking at code.

Hi

Although there is a workaround (http://httpd.apache.org/docs/current/env.html#fixheader), default header prefix shouldn't use underscore to be Apache 2.4 friendly.
Of course, backward compatibility could be an issue here.

PS: Should CASAttributePrefix work on Location Context/Section?
Documentation states its a "Valid Directory/.htaccess Directives", although seems it doesn't work within Location. Probably I'm wrong, but perhaps it's an error...

Regards

Using mod_auth_cas v1.0.10.
Apache/2.2.15, CentOS release 6.6 (Final)

These responses are from an Apereo/Jasig CAS Server v4.0.4:

The following is fine and attributes are available:

<?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-08-11T08:54:51.652Z" MajorVersion="1" MinorVersion="1" Recipient="https://caar.mydomain/test/mod_auth_cas/" ResponseID="_fc8a871036b92ef3b169d4e3839bacc5">
      <saml1p:Status><saml1p:StatusCode Value="saml1p:Success"/></saml1p:Status>
      <saml1:Assertion xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_a59a12b17d04a034d5c7735c207b5f1d" IssueInstant="2015-08-11T08:54:51.652Z" Issuer="localhost" MajorVersion="1" MinorVersion="1">
        <saml1:Conditions NotBefore="2015-08-11T08:54:51.652Z" NotOnOrAfter="2015-08-11T08:55:21.652Z"><saml1:AudienceRestrictionCondition><saml1:Audience>https://caar.mydomain/test/mod_auth_cas/</saml1:Audience></saml1:AudienceRestrictionCondition></saml1:Conditions>

        <saml1:AuthenticationStatement AuthenticationInstant="2015-08-11T08:54:51.482Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified">
          <saml1:Subject><saml1:NameIdentifier>testuser</saml1:NameIdentifier><saml1:SubjectConfirmation><saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact</saml1:ConfirmationMethod></saml1:SubjectConfirmation></saml1:Subject>
        </saml1:AuthenticationStatement>

        <saml1:AttributeStatement>
          <saml1:Subject><saml1:NameIdentifier>testuser</saml1:NameIdentifier><saml1:SubjectConfirmation><saml1:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:artifact</saml1:ConfirmationMethod></saml1:SubjectConfirmation></saml1:Subject>
          <saml1:Attribute AttributeName="sAMAccountName" AttributeNamespace="http://www.ja-sig.org/products/cas/"><saml1:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">testuser</saml1:AttributeValue></saml1:Attribute>
          <saml1:Attribute AttributeName="mail" AttributeNamespace="http://www.ja-sig.org/products/cas/"><saml1:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">testuser@myotherdomain</saml1:AttributeValue></saml1:Attribute>
          <saml1:Attribute AttributeName="displayName" AttributeNamespace="http://www.ja-sig.org/products/cas/"><saml1:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Test User</saml1:AttributeValue></saml1:Attribute>
        </saml1:AttributeStatement>

      </saml1:Assertion>
    </saml1p:Response>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The following causes a crash:

<?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-08-11T08:58:30.839Z" MajorVersion="1" MinorVersion="1" Recipient="https://caar.mydomain/test/mod_auth_cas/" ResponseID="_c730d5e39b23d9478a074c716681cd59">
      <saml1p:Status><saml1p:StatusCode Value="saml1p:Success"/></saml1p:Status>
      <saml1:Assertion xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_7d586d54ba1373d9c029054968357ad5" IssueInstant="2015-08-11T08:58:30.839Z" Issuer="localhost" MajorVersion="1" MinorVersion="1">
        <saml1:Conditions NotBefore="2015-08-11T08:58:30.839Z" NotOnOrAfter="2015-08-11T08:59:00.839Z"><saml1:AudienceRestrictionCondition><saml1:Audience>https://caar.mydomain/test/mod_auth_cas/</saml1:Audience></saml1:AudienceRestrictionCondition></saml1:Conditions>

        <saml1:AuthenticationStatement AuthenticationInstant="2015-08-11T08:58:30.573Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified">
          <saml1:Subject><saml1:NameIdentifier>testuser</saml1:NameIdentifier><saml1:SubjectConfirmation><saml1:ConfirmationMethod>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>

In error_log:

[Tue Aug 11 14:59:19 2015] [notice] child pid 6184 exit signal Segmentation fault (11)

The last few entries in ssl_error_log was:

[Tue Aug 11 14:59:18 2015] [debug] mod_auth_cas.c(1440): [client 193.63.135.175] MOD_AUTH_CAS: 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-08-11T13:59:18.596Z" MajorVersion="1" MinorVersion="1" Recipient="https://caar.mydomain/test/mod_auth_cas/" ResponseID="_58381ca25b0175ff9cbe3b6b63702835"><saml1p:Status><saml1p:StatusCode Value="saml1p:Success"/></saml1p:Status><saml1:Assertion xmlns:saml1="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="_7787ab197c67f1751461465076450ade" IssueInstant="2015-08-11T13:59:18.596Z" Issuer="localhost" MajorVersion="1" MinorVersion="1"><saml1:Conditions NotBefore="2015-08-11T13:59:18.596Z" NotOnOrAfter="2015-08-11T13:59:48.596Z"><saml1:AudienceRestrictionCondition><saml1:Audience>https://caar.mydomain/test/mod_auth_cas/</saml1:Audience></saml1:AudienceRestrictionCondition></saml1:Conditions><saml1:AuthenticationStatement AuthenticationInstant="2015-08-11T13:59:18.027Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><saml1:Subject><saml1:NameIdentifier>testuser</saml1:NameIdentifier><saml1:SubjectConfirmation><saml1:ConfirmationMethod>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>, referer: https://login.myotherdomain/cas/login?service=https%3a%2f%2fcaar.mydomain%2ftest%2fmod_auth_cas%2f
[Tue Aug 11 14:59:18 2015] [debug] mod_auth_cas.c(1266): [client 193.63.135.175] entering createCASCookie(), referer: https://login.myotherdomain/cas/login?service=https%3a%2f%2fcaar.mydomain%2ftest%2fmod_auth_cas%2f
[Tue Aug 11 14:59:18 2015] [debug] mod_auth_cas.c(1061): [client 193.63.135.175] entering CASCleanCache(), referer: https://login.myotherdomain/cas/login?service=https%3a%2f%2fcaar.mydomain%2ftest%2fmod_auth_cas%2f
[Tue Aug 11 14:59:18 2015] [debug] mod_auth_cas.c(1108): [client 193.63.135.175] Insufficient time elapsed since last cache clean, referer: https://login.myotherdomain/cas/login?service=https%3a%2f%2fcaar.mydomain%2ftest%2fmod_auth_cas%2f
[Tue Aug 11 14:59:18 2015] [debug] mod_auth_cas.c(1178): [client 193.63.135.175] entering writeCASCacheEntry(), referer: https://login.myotherdomain/cas/login?service=https%3a%2f%2fcaar.mydomain%2ftest%2fmod_auth_cas%2f

We keep getting the error:
'Require cas-attribute' missing specification(s) in configuration. Declining.

We are using mod_auth_cas from a commit after Require cas-attribute was added.

Our .htaccess file:
AuthType CAS
AuthName "CAS"
require cas-attribute "xyz:groupMembership"~uid=xyz_emp,ou=tuv,ou=Group,dc=XYZ,dc=edu

The response from CAS:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas' xmlns:xyz='http://login.xyz.edu/cas'>
  <cas:authenticationSuccess>
    <cas:user>theuser</cas:user>
    <xyz:attributes>
            <xyz:uid>theuser</xyz:uid>
            <xyz:mail>[email protected]</xyz:mail>
            <xyz:sn>Qpublic</xyz:sn>
              <xyz:groupMembership>uid=xyz_emp,ou=tuv,ou=Group,dc=XYZ,dc=edu</xyz:groupMembership>
              <xyz:groupMembership>uid=IT_Pro,ou=Group,dc=XYZ,dc=edu</xyz:groupMembership>
            <xyz:givenName>John</xyz:givenName>
            <xyz:displayName>John Qpublic</xyz:displayName>
    </xyz:attributes>
  </cas:authenticationSuccess>
</cas:serviceResponse>

We've tried several variations of the .htaccess file.
Everything from
require cas-attribute
"xyz:groupMembership"~uid=xyz_emp,ou=tuv,ou=Group,dc=XYZ,dc=edu
to
require cas-attribute
groupMembership:uid=xyz_emp,ou=tuv,ou=Group,dc=XYZ,dc=edu
and several other variations.

We always seem to get that error. Looking at the code, makes me think
the error means there were no attributes received yet we the debug log
clearly shows we're getting the above XML.

mod_auth_cas seems to be working fine if we "require user"

What are we doing wrong and how do we fix it?

Thanks in advance.

Hi,

I have a working config with Apache 2.2 but was trying to move to 2.4 as all my other servers are using 2.4.

I'm getting the following error:

Starting httpd: httpd: Syntax error on line 353 of /etc/httpd/conf/httpd.conf: Syntax error on line 1 of /etc/httpd/conf.d/auth_cas.conf: Cannot load /etc/httpd/modules/mod_auth_cas.so into server: /etc/httpd/modules/mod_auth_cas.so: undefined symbol: ap_requires

This is on a freshly installed AWS Linux, Apache 2.4.23, mod_auth_cas-1.1-3.el6.x86_64 using EPEL 6.

My understanding was that Apache 2.4 was added in #86 (1.1 release according to #49).
However ap_requires was removed in 2.4 .

Am I missing something??

Thanks for your help

Apache input filters are not guaranteed to be called with a complete request but instead should assume the request may be fed in piece-meal, in multiple calls. However, the CAS input filter for single signout (cas_in_filter) logic presumes that the first call will have a complete request as it just examines the current bucket brigade, possibly incomplete, for evidence of SAML signout request, calling the CAS signout if found.

We have seen cases where the single sign-out request is split into two pieces.

https://mail-archives.apache.org/mod_mbox/httpd-users/201510.mbox/%3C39A0AA41C90BDA42BEB03EF9F45DC3F80A058AD2@UCDEDC1PWXMR003.de.db.com%3E

The fix involves a request-scope persistent data structure to build up a copy of the request suitable across multiple calls for passing to CASSAMLLogout

Requests with trailing ?& fail silently without logging and returning any response, when handled by mod_auth_cas.

If loglevel is on debug the last logentry (error_log) is :

[Fri Aug 17 10:05:54 2012] [info] Initial (No.1) HTTPS request received for child 51 (server www.domain.tld:443)
[Fri Aug 17 10:05:54 2012] [debug] mod_auth_cas.c(1903): [client 192.168.0.55] Entering cas_authenticate()

Example with curl

$>curl -kv 'https://www.domain.tld/wiki/?&'
* About to connect() to www.domain.tld port 443 (#0)
*   Trying 192.168.0.10... connected
* Connected to www.domain.tld (192.168.0.10) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs/
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
*        subject: <some DN>
*        start date: 2012-01-26 16:09:57 GMT
*        expire date: 2015-01-26 16:09:57 GMT
*        subjectAltName: www.domain.tld matched
*        issuer:  <some issuer> 
*        SSL certificate verify ok.
> GET /wiki/?& HTTP/1.1
> User-Agent: curl/7.19.7 libcurl/7.19.7 OpenSSL/0.9.8j zlib/1.2.3 libidn/1.10
> Host: www.domain.tld
> Accept: */*
>
* Empty reply from server
* Connection #0 to host www.domain.tld left intact
curl: (52) Empty reply from server
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
$>

I'm using 1.0.9.1 and notice that there is no support for a "Require cas-attribute" directive, but it's there in the master and attz branches. Can these branches be considered ok for production? I guess I'm hoping someone forgot to tag 1.0.10.

There is an HTTP response splitting vulnerability in the login redirection. When formatting the service parameter any control characters should be removed.

See https://www.owasp.org/index.php/HTTP_Response_Splitting

A common configuration where I am employed is something like the following:

<Location /login.action>
AuthType CAS
CASScope /
AuthName "CAS"
Require valid-user
Order allow,deny
Allow from env=no_cas_use
Satisfy Any

(where no_cas_use is set usually by mod_rewrite for specific special cases - generally things like API calls or the like that can't cope with gateway mode).

This has worked fine historically, but mod_auth_cas 1.1 with Apache 2.4 throws a 500 internal error which logs (debug on)

[authz_core:debug] [pid 5664] mod_authz_core.c(809): AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[authz_core:debug] [pid 5664] mod_authz_core.c(809): AH01626: authorization result of : denied (no authenticated user yet)
[authn_core:error] [pid 5664] AH01796: AuthType CAS configured without corresponding module

Removing the Satisfy Any bit (i.e. just going to
Rolling back to mod_auth_cas 1.0.9 (which works fine in Apache 2.4 without any patching), everything seems fine. mod_auth_cas 1.0.10 (w/ Apache 2.4 patch; won't work otherwise) shows the same error so I assume it's related to a change made from 1.0.9->1.0.10 (controlling access via CAS attributes, it looks like). I suspect it's related to switching from chaging the hook from:

ap_hook_check_user_id(cas_authenticate, NULL, NULL, APR_HOOK_MIDDLE);

to

ap_hook_check_access(
cas_authenticate,
NULL,
NULL,
APR_HOOK_MIDDLE,
AP_AUTH_INTERNAL_PER_URI);

but admittedly don't know Apache modules that well.

I'm going to try and dig into it, but it's a major blocker for upgrades in our environment. I'll keep poking at it, but thought I would report it.

Hello,
With colleagues in my company, we are currently trying to fix issues with an application relying on mod_auth_cas for authentication. Problems are related to certificates.
In order to understand what happens, we used the directive

CASDebug on

and added the directive

LogLevel debug

since the README states:

Directive: CASDebug
Default: Off
Description: Enable or disable debugging mode for troubleshooting. Please
note that LogLevel must be set to Debug for the VirtualHost in
order for these logs to be visible.

However, since we turned on LogLevel, EVERY module in Apache configuration traces to the standard error.log Apache log file, which becomes quickly huge and unmanageable.

Unfortunately, the application relies on Apache 2.2, so the new syntax

LogLevel auth_cas:debug

available in Apache 2.4 is not working (we tried: Apache refuses to start! Oh, by the way, we are on a Windows platform).

So my questions:

1. If we have the capability to update to Apache 2.4.x (not likely in project context, but could happen), would the above syntax work? Any feedback on this?
2. Does anyone know a workaround in Apache 2.2.x to restrict debug trace to mod_auth_cas only?
3. Is there a directive to tell mod_auth_cas to trace in a separate, custom log file, instead of messying the standard Apache error.log?
   (if not, it would be a nice-to-have feature, provided Apache module development rules allow for that)

Thanks for any reply,

Using version from trunk (this one) i`m getting MOD_AUTH_CAS: INVALID_TICKET in logs while trying to access page secured by CAS.

My setup:

CASCookiePath /tmp/cas/
CASLoginURL https://login.foobar.pl/cas/login
CASValidateURL https://login.foobar.pl/cas/serviceValidate
CASValidateServer Off
CASDebug On

AuthType CAS
AuthName "CAS"
require valid-user

MOD_AUTH_CAS: CASCookiePath '/dev/null' is not a directory or does not end in a trailing '/'!\n", 149) = 149

I am currently working on securing a PHP application with Apache mod_auth_cas. I managed to authenticate users, get the cookie and generate the cookie file with user information. However, I am facing the following issue:

The module is not writing the HTTP Headers with the user info. I do not know why the user info is not displayed when the login is successful. The validation in place is SAML.

This is my mod_auth_config:

<IfModule !ssl_module>
    LoadModule ssl_module modules/mod_ssl.so
</IfModule>
LoadModule auth_cas_module modules/mod_auth_cas.so

CASVersion 2
CASDebug On

CASLoginURL http://********/index.html
CASValidateURL https://**********/cas/samlValidate
CASValidateSAML On


<VirtualHost *:8010>
	DocumentRoot *********
	ErrorLog logs/cas_error_log
	CustomLog logs/cas_access_log combined
	LogLevel debug
	
	<Location /secured.php>
		Authtype CAS
		require valid-user
		
		CASScope /
		
		CASAuthNHeader CAS_firstname
		CASAuthNHeader CAS_userType
		
	</Location>

</VirtualHost>

This is my secure page with the headers:

Response Headers:
Age:0
Connection:Keep-Alive
Content-Length:842
Content-Type:text/html; charset=UTF-8
Date:Fri, 20 Jan 2017 10:02:22 GMT
Proxy-Connection:Keep-Alive
Server:Apache/2.2.15 (Oracle)
X-Powered-By:PHP/5.3.3
Request Headers:
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Cookie:_ga=GA1.1.2137298612.1484900359; # MOD_AUTH_CAS=1efb0b1dd5ad5a3a8d1337ddf0948115; BCSI-CS-92a12fdef0366f25=2
Host:***:8010
Proxy-Connection:keep-alive
Referer:http://:8010/index.php?service=http%3a%2f%2f**********%3a8010%2fsecured.php
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

SAML Cache Cookie:

<attribute name="firstname">
        <value>Marcos</value>
  </attribute>

 <attribute name="userType">
        <value>PS</value>
  </attribute>

PD: I tried changing prefix, and put one without underscore and nothing.

Would it be possible to provide an option which disables the cleaning of the 'ticket' param from the query string?

The rationale behind this is that we have some demo apps which are protected by CAS on Apache, and then also have CAS authentication within the app which will be used when the system goes live. This currently means that the internal CAS authentication doesn't work because the ticket attribute is scrubbed by Apache.

Hi

As discussed in https://groups.google.com/a/apereo.org/d/msg/cas-user/_UASHFvNYi4/vduQUbmmAQAJ and according to documentation:

Directive: CASAuthNHeader
Default: None
Description: If enabled, this will store the user returned by CAS in an HTTP header
accessible to your web applications.

Although this is true, seems incomplete because SAML attributes (those specified with Require cas-attribute/returned by CAS) aren't stored as headers if CASAuthNHeader is not set.

Please, update documentation to something like:
"If enabled, this will store the CAS returned attributes, including the logged user in a header named by CASAuthNHeader directive, as HTTP headers accessible to your web applications."

Also, have in mind that CASScrubRequestHeaders strips headers, including CASAuthNHeader. In order to store cas-attributes as headers, something like this will do the trick:

CASAuthNHeader foo will add a foo header naming logged user
CASAttributePrefix foo will prefix cas-attributes with foo
CASScrubRequestHeaders On will strip all cas-attributes from headers

Hence, we need something like CASAttributesAsHeaders On by default, having backward compatibility.

Regards