apereo / mod_auth_cas Goto Github PK
View Code? Open in Web Editor NEWAn Apache httpd module for integrating with Apereo CAS Server project.
Home Page: https://www.apereo.org/projects/cas
An Apache httpd module for integrating with Apereo CAS Server project.
Home Page: https://www.apereo.org/projects/cas
======================================================================== MOD_AUTH_CAS 1.2 README ======================================================================== Apache CAS Authentication Module for the JASIG/Apereo CAS Server. ======================================================================== LICENSE ======================================================================== Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. ======================================================================== INTRODUCTION ======================================================================== The purpose of this module is to allow an Apache web server to interact with an authentication server that conforms to the CAS version 1 or 2 protocol or SAML protocol as used by the JASIG/Apereo CAS Server. At the time of this writing, the CAS protocol specification is here: http://apereo.github.io/cas/development/protocol/CAS-Protocol-Specification.html ======================================================================== Getting Started ======================================================================== -------------------------------------------------------------------- Linux Distribution Packaging -------------------------------------------------------------------- mod_auth_cas is available in most major Linux distributions, including Debian, Ubuntu, Fedora, and is available from EPEL for CentOS and RHEL. -------------------------------------------------------------------- Building from Source -------------------------------------------------------------------- The following development libraries and utilities must be installed: * OpenSSL - 0.9.8c or higher * Apache Portable Runtime - 1.5.0 or higher * Apache Portable Runtime Utilities - 1.3.0 or higher * Apache Web Server - 2.4 or higher * libcurl - 7.18.2 or higher * libpcre2 - 10 or higher Download the distribution via git or tarball. Because git does not preserve timestamps, autoconf may determine it is necessary to bootstrap the project. If building from source, please start with: autoreconf -ivf Build is performed with the standard Autoconf incantation: ./configure && make && sudo make install Edit your Apache configuration to load the mod_auth_cas module: LoadModule auth_cas_module /path/to/mod_auth_cas.so Set a few required parameters in your Apache configuration: CASCookiePath /var/cache/apache2/mod_auth_cas/ CASLoginURL https://login.example.org/cas/login CASValidateURL https://login.example.org/cas/serviceValidate Protect a "Location" or "Directory" block in your Apache configuration: <Location /secured> Authtype CAS Require valid-user </Location> If attribute-based authorization is also desired, specify cas-attribute name:value in your Require rule (please note: both attribute name and value are case-sensitive): CASCookiePath /var/cache/apache2/mod_auth_cas/ CASLoginURL https://login.example.org/cas/login CASValidateURL https://login.example.org/cas/samlValidate CASValidateSAML On <Location /secured> Authtype CAS Require cas-attribute edupersonaffiliation:staff </Location> Both the CAS 2.0 and SAML 1.1 protocols support including additional attributes in the CAS validation response, which may also be added as HTTP headers (see CASAttributePrefix and CASAttributeDelimiter). This example uses the SAML protocol and requires that the 'edupersonaffiliation' attribute is set to 'staff'. ======================================================================== NEW FEATURES AND FUNCTIONS IN THIS RELEASE ======================================================================== * OpenSSL 1.1 support. * CASv2 attributes. * CASPreserveTicket, which allows tickets to pass through when a valid session exists. * CASGatewayCookieDomain, to set the gateway cookie domain. * Use a dynamic buffer to store the CAS validation response. * Various bug and documentation fixes. https://github.com/apereo/mod_auth_cas/milestone/6?closed=1 ======================================================================== KNOWN ISSUES ======================================================================== * Autoconf does not work well on code freshly checked out of git. Autoconf artifacts must be rebuilt using `autoreconf -ivf` . ======================================================================== KNOWN LIMITATIONS ======================================================================== These limitations are known to exists in this release of the software: * CAS Proxy Validation is not implemented in this version. * CAS Ticket Validation can only be performed over an SSL connection. The CAS protocol does not explicitly require this, but to not do so leaves this system open to a man-in-the-middle attack. * CAS single sign out is currently not functional and disabled. It is only safe to use in the case where all requests are GET and not POST (the module inadvertently 'eats' some content of the POST request while determining if it should process it as a SAML logout request). * Reports of slow performance on some systems (particularly virtual machines) have been reported. This is related to the entropy that is gathered when creating a session cookie for the end user. To combat this, there are 3 solutions. The first is to upgrade the version of the Apache Portable Runtime on your system to >= 1.3.0. In that version, entropy is gathered from a nonblocking source. The second method would be to install a package such as rng-tools and feed random data from /dev/urandom to /dev/random("-r /dev/urandom"). The last way is to reduce the size of the CASCookieEntropy setting, reducing the demand on the pool. * Win32 support has been dropped (but not removed) due to lack of development resources, and seemingly minimal community usage. You are welcome to try it, but YMMV for success. ======================================================================== Configuration ======================================================================== First, you must tell Apache to load the module. In your httpd.conf, add: LoadModule auth_cas_module /path/to/mod_auth_cas.so Then, in the location(s) you want to protect, use the following directive: AuthType CAS Be sure to set authorization parameters in the locations you are protecting(e.g. 'require valid-user', 'require group foo') The following are valid configuration options and their default: Valid Server/VirtualHost Directives ----------------------------------- Directive: CASVersion Default: 2 Description: The version of the CAS protocol to adhere to (1 or 2). This affects whether Gateway mode is available and how the CAS validation response is parsed. 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. Directive: CASValidateDepth Default: 9 Description: This directive will set the maximum depth for chained certificate validation. The default (according to OpenSSL documentation) is 9. Directive: CASCertificatePath Default: /etc/ssl/certs/ Description: The path to the X509 certificate of the Certificate Authority for the server in CASLoginURL and CASValidateURL. This may be either a file, or a directory containing the certificate files linked to by their hashed names. Directive: CASLoginURL Default: NULL Description: The URL to redirect users to when they attempt to access a CAS protected resource and do not have an existing session. The 'service', 'renew', and 'gateway' parameters will be appended to this by mod_auth_cas if necessary. Include 'http[s]://...' Directive: CASValidateURL Default: NULL Description: The URL to use when validating a ticket presented by a client in the HTTP query string (ticket=...). Must include 'https://' and must be an HTTPS URL. Directive: CASProxyValidateURL Default: NULL Description: The URL to use when performing a proxy validation. This is currently an unimplemented feature, so setting this will have no effect. Directive: CASRootProxiedAs Default: NULL Description: This URL represents the URL that end users may see in the event that access to this Apache server is proxied. This will override the automatic generation of service URLs and construct them using this prefix. As an example: If the site being protected is http://example.com/ and the Apache instance of this server is http://internal.example.com:8080, setting CASRootProxiedAs to http://example.com would result in proper service parameter generation. Directive: CASCookiePath Default: /dev/null Description: When users first authenticate to mod_auth_cas with a valid service ticket, a local session is established. Information about this session (the username, time of creation, last activity time, the resource initially requested, and whether or not the credentials were renewed) is stored in this directory. This location should be writable by the web server ONLY. Any user that can write to this location can falsify authentication information by creating a fake data file. NOTE : Some distributions purge the contents of /tmp/ on a reboot, including user created directories. This will prevent mod_auth_cas from storing cookie information until that directory is created. To avoid this, try using a different location, such as /var/cache/apache2/mod_auth_cas/ Directive: CASCookieEntropy Default: 32 Description: When creating a local session, this many random bytes are used to create a unique session identifier. Using large values for this field may result in delays when generating session IDs if not enough entropy is available. Directive: CASTimeout Default: 7200 (2 hours) Description: This is the hard limit, in seconds, for a mod_auth_cas session (whether it is idle or not). When a session has reached this age and a new request is made, the user is redirected to the CASLoginURL to obtain a new service ticket. When this new ticket is validated, they will be assigned a new mod_auth_cas session. Set this value to '0' in order to allow a non-idle session to not expire. Directive: CASIdleTimeout Default: 3600 (1 hour) Description: This is a limit, in seconds, of how long a mod_auth_cas session can be idle. When a request comes in, if it has been inactive for CASIdleTimeout seconds, the user is redirected to the CASLoginURL to obtain a new service ticket. Directive: CASCacheCleanInterval Default: 1800 (30 minutes) Description: This is the minimum amount of time that must pass inbetween cache cleanings. When a new ticket is issued, or when an expired session is presented, the time of the last cache clean is compared against this value. If CASCacheCleanInterval seconds have passed since the last cleaning, then all files in CASCookiePath are examined and if they have expired, they are removed. This is merely to prevent the file system from becoming excessively cluttered. Directive: CASCookieDomain Default: NULL Description: Specify the value for the 'Domain=' parameter in the Set-Cookie header. Directive: CASCookieSameSite Default: NULL Description: Specify the value for the 'SameSite=' parameter in the Set-Cookie header. Allowed values are 'None', 'Lax', and 'Strict'. Directive: CASCookieHttpOnly Default: On Description: Set the optional 'HttpOnly' flag for cookies issues by mod_auth_cas. Set the HttpOnly flag as described in in RFC 6265. This flag prevents the mod_auth_cas cookies from being accessed by client side Javascript. Directive: CASCookieSecure Default: Auto Description: Set the optional 'Secure' attribute for cookies issued by mod_auth_cas. Set the Secure attribute as described in in RFC 6265. This flag prevents the mod_auth_cas cookies from being sent over an unencrypted HTTP connection. By default, mod_auth_cas sets the 'Secure' attribute depending on information about the connection (the 'Auto' option). The options 'On' and 'Off' can be used to override the automatic behaviour. Directive: CASAuthoritative Default: Off Description: This directive determines whether an optional authorization directive (see 'Require cas-attribute') is authoritative and thus binding or if other authorization modules will also be applied. 'On' means authoritative, 'Off' means not authoritative. NOTE: This directive is unavailable with Apache 2.4. See the RequireAny, RequireNone, and RequireAll directives instead. Directive: CASValidateSAML Default: Off Description: If enabled, the response from the CAS Server will be parsed for SAML attributes which will be associated with the user. Requires setting CASValidateURL appropriately; typical URLs are of the form https://login.example.org/cas/samlValidate. Directive: CASAttributePrefix Default: CAS_ (Apache < 2.4) CAS- (Apache 2.4) Description: The prefix to use when adding CAS or SAML attributes to the HTTP headers, which will be named <CASAttributePrefix><attr_name>. CASAuthNHeader must be set for this directive to be used. NOTE: In Apache 2.4 and newer, headers containing "invalid" characters (including underscores) are silently dropped, so you must set this to a "valid" name containing only alphabetic characters and hyphens. Directive: CASAttributeDelimiter Default: , Description: mod_auth_cas will set the value of the attribute header (as described in CASAttributePrefix) to <attrvalue><CASAttributeDelimiter><attrvalue> in the case of multiple attribute values. Directive: CASPreserveTicket Default: Off Description: This directive leaves CAS ticket parameters intact when a valid session cookie exists. This helps prevent infinite redirect loops when CAS protection is being used at multiple levels. Directive: CASGatewayCookieDomain Default: NULL Description: Specify the value for the 'Domain=' parameter in the Set-Cookie header when setting the CASGatewayCookie. Valid Directory/.htaccess Directives ------------------------------------ Directive: CASScope Default: Off Description: Use this directive with an argument as a relative path (e.g. /application/) to specify the scope for which a mod_auth_cas cookie is valid. This is beneficial to prevent additional round trips to the CAS server. Assume someone authenticates to /application/subdir/ and then browses to /application/ - without CASScope set, each request would result in a round trip to the CAS server and a new cookie being created (one for each directory). CASScope would set one cookie, which will be presented on access to both directories. Note that if someone accessed /application/ and then /application/subdir/ this would not be an issue, but that order of access can not be guaranteed. To disable this feature, the special argument 'Off' will return to per-directory cookie paths for this directory and subdirectories. Directive: CASRenew Default: Off Description: Use this directive with an argument as a relative path (e.g. /application/secure/ for http://www.example.com/application/secure/*) to force a user to renew their credentials when accessing that directory. The argument MUST be a relative path. To disable this requirement, the special argument 'Off' will disable this requirement for this directory and subdirectories. Directive: CASGateway Default: Off Description: Use this directive with an argument as a relative path (e.g. /application/insecure/ for http://www.example.com/application/insecure/*) to allow anonymous access to that directory. The argument MUST be a relative path. To disable this feature, the special argument 'Off' will reinstate the requirement for authentication. Directive: CASCookie Default: MOD_AUTH_CAS Description: The name of the cookie used to store the session ID over HTTP connections. It should be changed if it will interfere with the application protected by mod_auth_cas. Directive: CASSecureCookie Default: MOD_AUTH_CAS_S Description: The name of the cookie used to store the session ID over HTTPS connections. It should be changed if it will interfere with the application protected by mod_auth_cas. Directive: CASGatewayCookie Default: MOD_AUTH_CAS_G Description: The name of the cookie used to store whether or not the user has attempted to access this resource before. It should be changed if it will interfere with the application protected by mod_auth_cas. Directive: CASAuthNHeader Default: None Description: If enabled, this will store the user returned by CAS in the specified HTTP header accessible to your web applications, and any additional attributes received in headers named according to CASAttributePrefix. This is in addition to the REMOTE_USER environment variable, which is always set to the CAS user. Directive: CASSSOEnabled Default: Off Description: If enabled, this activates support for Single Sign Out within the CAS protocol. Please note that this feature is currently experimental and may mangle POST data. Directive: CASScrubRequestHeaders Default: Off Description: mod_auth_cas will strip request inbound request headers that may have special meaning, such as those set with the CASAttributePrefix or the CASAuthNHeader value. Directive: Require cas-attribute <attribute>:<value> Default: NULL Description: Use this directive to authorize based on CAS or SAML attributes returned via the session validation call. Multiple directives are OR-ed. If directive is present with no attributes defined, the request is declined. If value has spaces, wrap the pair in quotes. See also CASAuthoritative. Directive: Require cas-attribute <attribute>~<value> Default: NULL Description: Use this form of the directive to authorize based on CAS or SAML attributes returned via the session validation call. Multiple directives are OR-ed. If directive is present with no attributes defined, the request is declined. The value is interpreted as a Perl-Compatible Regular Expression (PCRE) using case-sensitive matching. See also CASAuthoritative. ======================================================================== 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 Google Group link: https://groups.google.com/a/apereo.org/forum/#!forum/cas-user ========================================================================
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:
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:
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:
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:
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:
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.
CASLoginURL http://xxxxxxx CASVersion 2 CASDebug On CASValidateURL http://xxxxxxx CASCookiePath /xx/xxx CASTimeout 43200 CASIdleTimeout 3600 AuthType CAS Require valid-userI 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
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.
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.
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:
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.