Compilation on reports warning:
"auth_mellon_diagnostics.c", line 188: warning: implicit function declaration: rindex
"auth_mellon_diagnostics.c", line 188: warning: improper pointer/integer combination: op "="
And binary dumps core, because rindex() is assumed to be integer type, so
compiler sign extends its return value and then uses the number as pointer:
am_diag_cond_str+0x154: call -0x1e119 <PLT=libc.so.1`rindex>
am_diag_cond_str+0x159: movslq %eax,%rax
am_diag_cond_str+0x15c: testq %rax,%rax
am_diag_cond_str+0x15f: je +0x7 <am_diag_cond_str+0x168>
am_diag_cond_str+0x161: movb $0x5d,(%rax) <- SIGSEGV
Fixes issue #207.
mellon passes on every attribute received in a SAML assertion as an
Apache variable. By default, the variable is prefixed with "MELLON_".
In some cases, for example when migrating from a different SP to mellon
it might be beneficial to change the prefix. And while using
MellonSetEnvNoPrefix is an option as well, the MellonSetEnvNoPrefix has
to be specified for each variable independently.
It turns out that browsers silently convert backslash characters into
forward slashes, while apr_uri_parse() does not.
This mismatch allows an attacker to bypass the redirect URL validation
by using an URL like:
https://sp.example.org/mellon/logout?ReturnTo=https:%5c%5cmalicious.example.org/
mod_auth_mellon will assume that it is a relative URL and allow the
request to pass through, while the browsers will use it as an absolute
url and redirect to https://malicious.example.org/ .
This patch fixes this issue by rejecting all redirect URLs with
backslashes.
The way the ECP flow works is that when a client initiates the flow, the
SP's response is HTTP 200, but not the requested content, but a signed XML
document that contains the "samlp:AuthnRequest" element. The idea is that
the ECP client would then determine the IDP and send the document to the
IDP, get a samlp:Response and convey that to the SP to get access to the
protected resource.
Internally, the auth check which is normally done with am_check_uid() set to
apache's ap_hook_check_user_id() hook, just responds with OK, so it pretends
to authenticate the user. Then in the usual flow, the request reaches the
ap_hook_handler which handles the request. There in the pipeline, mellon
registers functions am_handler() which should run first (APR_HOOK_FIRST),
determine that this request is an ECP one and return the ECP AuthnRequest
document. But in case the proxy module is also in the picture, the proxy
module "races" for who gets to be the first to handle the request in the
pipeline and wins. Therefore, the request reaches the protected resource
via mod_proxy and returns it.
This fix modifies the ap_hook_handler() call to explicitly run before
handlers from mod_proxy.c
To reproduce the bug:
0) Have a SP with mellon connected to a Keycloak IDP (or any other IDP I
guess). In the example below, my SAML SP is saml.federation.test
1) Set a Location protected by mellon that proxies requests to another
URL. For example:
ProxyPass /sp-proxy http://app.federation.test/example_app/
<Location /sp-proxy>
AuthType Mellon
MellonEnable auth
Require valid-user
</Location>
2) call:
curl -L -H "Accept: application/vnd.paos+xml" \
-H 'PAOS: ver="urn:liberty:paos:2003-08";"urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"' \
http://saml.federation.test/sp-proxy
Before the patch, you would see whatever is served from the proxied
page. With the patch, you should get back a XML document with a
samlp:AuthnRequest.
A trailing semi-colon in the Set-Cookie header confuses the AWS
Elastic Load Balancer. This patch fixes the code that generates the
Set-Cookie header so that it no longer ends with a semi-colon.
Fixes issue #190
The code was looking for "X-Request-With", but the header is actually
"X-Requested-With". As far as I can tell, it has always been the
latter, at least in the jQuery source code.
Fixes issue #174.
Using Apache environment variables in MellonCond expressions didn't
work for various reasons:
* The substitution was never executed if no backrefs were present.
* Only the OS environment was queried without checking the Apache
internal variable stores.
* The output string after substitution was set to an empty string.
Fixing these issues makes %{ENV:...} work properly.
Add documentation in the User Guide on how to determine if a SAML
transaction succeeded or failed and how to determine the cause of the
failure.
Add documentation in the User Guide on known quirks with ADFS
integration.
Signed-off-by: John Dennis <jdennis@redhat.com>
Previously there was no way to control the signature algorithm used
when Mellon signed it's SAML messages. It simply defaulted to whatever
the default was in the LassoServer server object. Currently the lasso
default is LASSO_SIGNATURE_METHOD_RSA_SHA1. Some IdP's require a
different or more secure method (e.g. ADFS). This patch allows
controlling the signature method on a per directory basis via the
MellonSignatureMethod configuration directive.
It currently supports the following configuration values which map to
these Lasso enumerated constants (provided these definition exist in
Lasso):
rsa-sha1: LASSO_SIGNATURE_METHOD_RSA_SHA1
rsa-sha256: LASSO_SIGNATURE_METHOD_RSA_SHA256
rsa-sha384: LASSO_SIGNATURE_METHOD_RSA_SHA384
rsa-sha512: LASSO_SIGNATURE_METHOD_RSA_SHA512
configure.ac was modified to test for the existence of the above
Lasso definitions, support is only compiled into Mellon if they
are defined at build time.
Important: This patch also changes the default used by Mellon from
rsa-sha1 to rsa-sha256. This was done because SHA1 is no longer
considered safe, SHA256 is now the current recommendation.
The patch also includes a few corrections in the diagnostics code
where it failed to use CFG_VALUE. Also fixed the diagnostics code when
an unknown value was encounted to print what that unknown value was.
Signed-off-by: John Dennis <jdennis@redhat.com>
Knowing if a SAML operation failed and the reason why is essential to
diagnose problems. The SAML Status Response is always included in all
SAML responses. In addition to the major reason why a transaction
failed it may also include extra expository information giving
additional details. Unfortunately we never logged any of the status
response information when a failure occurred. This patch adds code to
log the status response information.
In addition the patch adds diagnostic logging of received POST data.
Signed-off-by: John Dennis <jdennis@redhat.com>
The `mi` parameter to `ap_log_rerror()` was added in Apache 2.4. This
makes the macro expansion in `AM_LOG_RERROR()` incorrect on Apache
2.2.
This patch works around this issue by forwarding the `AM_LOG_RERROR()`
macro directly to `ap_log_rerror()`.
Fixes issue 151.
Olav Morken
Roger Meier
Vita Batrla
Jakub Hrozek
Olav Morken
Pat Riehecky
John Dennis
Dick Visser
Manabu Ori
Thijs Kinkhorst
Markus Hosch
Timo Lotterbach
David Kretch
Andrew Schulman
Nathan Neulinger