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.
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>
If diagnostics is enabled we want error messages written to the
diagnostics log as well as the Apache error_log. AM_LOG_RERROR
replaces the use of ap_log_rerror, it invokes ap_log_rerror as
previously but then also logs the same message to the diagnostics
log. If diagnostics is not enabled it reverts to ap_log_rerror.
Signed-off-by: John Dennis <jdennis@redhat.com>
Field experience with Mellon has demonstrated there are many
opportunities for deployment problems. Although there are tools such
as browser plugins which can capture SAML messages it's onerous for
site personnel to install and capture the relevant information. The
problem with this approach is further compounded by the fact the
external SAML messages are not correlated to Mellon's
requests/responses. Mellon currently can dump the Lasso session and
SAML Response messages and place them in Apache environment variables,
however these do not appear in the log file. To get them into the log
you have to add custom logging to the Apache config. Another issue is
the dumps are not human readable, they are base64 encoded, anyone
looking at the logs after setting up the custom logging will have to
find the base64 text and then manually copy the text into an external
base64 decoder. At that point you'll discover the XML is not pretty
printed making human interpretation difficult.
The Mellon debug messages written to the Apache error are often
insufficient to diagnose problems. And since the Mellon log messages
are written to the Apache error log they are interspersed with a lot
of non-Mellon message.
Compounding the problem of writing Mellon debug messages to the Apache
error log is the fact Apache log messages have a fixed maximum length
(currently 8192) which is insufficient to completely write out such
things as SAML Assertions, metadata, etc. Apache logging also escapes
all control characters with the consequence line breaks are not
preserved and what was a nicely formatted human readable piece of text
becomes a single line with escape characters and may be truncated.
It would be really nice if we could capture diagnostic information
with these properties:
* All relevant data is collected in exactly one file.
* Only information relevant to Mellon appears in the file.
* All information is human readable (pretty printed, decrypted) with
no need to rely on other tools.
* The diagnostic information is grouped by requests.
* The requests can be cross correlated with other Apache logs because
they utilize the same unique request identifier.
This patch adds diagnostic logging to a independent Mellon diagnostics
log file. Every piece of relevant information is captured, including:
* Request information which includes:
- Request method
- Request URL (raw and processed)
- Scheme
- Port
- Request query parameters
- Server name
- Unique request ID
- process ID, thread ID
- Request headers
* Mellon per directory configuration
A complete dump of the entire am_dir_cfg_rec structure keyed using
both the Mellon directive it is associated with and it's internal
name. This is emitted once on first use for a given URL.
The per directory dump includes the pathname of each file read as
well as the file contents. This includes:
- IdP metadata
- SP metadata
- SP cert
- SP key
- IdP public key file
- IdP CA file
* All session management operations
- cookie
- session lookup
- session creation
- session deletion
- cache management
- cache entry information
* All SAML messages
Each SAML message is decrypted, decoded and XML pretty printed in
human readable form.
* Request pipeline operations
What operations Mellon performs, what decisions it makes and what
data is being used to make those decisions.
* Response
- response status
- response headers
- Apache user name
- auth_type
- all Apache environment variables
Diagnostics can be enabled/disabled both at compile time and run
time. Compile time inclusion of diagnostics is managed with the
ENABLE_DIAGNOSTICS preprocssor symbol. The configure script now accepts
the
--enable-diagnostics and --disable-diagnostics
option. Building with diagnostics is disabled by default, you must
specify --enable-diagnostics to enable the run time option of generating
diagnostics.
The following server config directives have been added (e.g. may be
specified in the main server config area or within a <VirtualHost>
directive). If Mellon was not built with diagnostics enabled then
these config directives are no-ops and their use will generated a
warning in the log file indicating they have been ignored and to be
effective you must builld Mellon with diagnostics enabled.
MellonDiagnosticsFile:
The name of the diagnostics file or pipe,
(default is logs/mellon_diagnostics)
MellonDiagnosticsEnable:
Currently either On or Off but it is designed so it can take other
flags in the future to control what type of information is
reported.
Signed-off-by: John Dennis <jdennis@redhat.com>
File information was handled inconsistently. Some configuration
directives which specified a file path replaced the file path with the
contents of the file. This made it impossible to report where the data
was read from. Other file configuration simply recorded the path. The
directives which immediately read the file contents would generate a
configuration error if the file wasn't readable, but those directives
which simply recorded the file path didn't check on the validity of
the path and relied on Lasso to report an error, however these errors
come significantly after configuration parsing because they are
evaluated in a lazy fashion on first use. The Lasso error reporting
can sometimes be cryptic making it difficult to realize the problem is
due to a improperly specified path in a configuration directive.
We want to be able to log the file pathnames where various files are
read from for diagnostic logging purposes.
This patch introduces a new struct am_file_data_t that encapsulates
all information concerning a file including it's pathname, it's stat
information, optionally it's content, when it was read, etc. as well
as maintaing error codes and an error description.
All file specifications and operations now use this mechanism for
consistency.
Signed-off-by: John Dennis <jdennis@redhat.com>
Sometimes configuration errors are made and a location does have any
IdP's defined for it. Previosly the error message in this case was:
"Error adding IdP to lasso server object. Please verify the following
configuration directives: MellonIdPMetadataFile and
MellonIdPPublicKeyFile."
But this message is misleading, it suggests an attempt was made to add
the IdP but somehow it failed, this will often cause folks to try to
determine what is wrong with the IdP metadata file, which may in fact
be defined in the mellon config but because of location inheritance is
not being included in the per directory config.
It would be much more helpful to indicate no IdP's were defined for
this config location which is clearly a different problem than
suggesting an attempt was made to add an IdP but it failed.
Signed-off-by: John Dennis <jdennis@redhat.com>
The entire point of the cache is to persist state between requests so
conceptually it makes sense the cache functions would receive a
server_rec pointer because the cache is a server level data
structure. However most cache operations occur in the context of a
request. Passing a request_rec to a cache function has the following
advantages:
1) Any logging during a cache operation should be tied to the request.
2) Any need for temporary memory allocation is much easier to handle
with access to the request's memory pool which is cleaned up at the
end of the request as opposed to trying manage memory allocations at
the server level.
3) Any need for access to the server_rec is trivially easy to obtain
from the request_rec via r->server. In fact the caller of cache
functions inside requests simplyy provided the server_rec parameter
via r->server, so why not just pass the request_rec?
These changes are in anticipation of adding enhanced logging and
diagnostics into the cache functions, they will need access to the
request_rec and it's memory pool.
Signed-off-by: John Dennis <jdennis@redhat.com>
Several places in the code we assumed that Lasso error codes were
negative, however some of them are positive integers. This patch
ensures that we do direct check for a zero return code in all cases.
Fixes issue #128.
This patch fixes a segmentation fault that can occur after the user
has logged in if the server is configured to replay POST data from
before login. If the POST data contained a field without a value we
would attempt to pass a constant string to the
am_urldecode()-function, which would crash with a segmentation fault.
This patch fixes that by using an empty string allocated on the stack
instead of a constant string.
Fixes #115.
Formerly we were setting the response header "Content-Type" in
r->headers_out directly via the apr_table_setn() call. Although using
apr_table_setn() is appropriate for many HTTP headers Apache actively
manages a small set of headers in
http_filters.c:ap_http_header_filter(). These managed headers are
derived from values maintained in the request_rec. "Content-Type" is
one of the managed headers.
Because we didn't set r->content_type field via the
ap_set_content_type() call and instead directly updated the
r->headers_out table our value for "Content-Type" was overwriten when
the ap_http_header_filter() was run just prior to emitting the
response with the result the "Content-Type" header returned to the
client was incorrect.
Signed-off-by: John Dennis <jdennis@redhat.com>
The SAML 2.0 specification requires the name to be present, but we still
should not crash when it is missing. This patch fixes the crash by skipping
over attributes without a name.
Fixes issue #101.
When MellonEnable is "auth" and we get an unauthenticated AJAX
request (identified by the X-Request-With: XMLHttpRequest HTTP
header), fail with HTTP code 403 Forbidden instead of redirecting
to the IdP. This saves resources, as the client has no opportunity
to interract with the user to complete authentification.
https://github.com/UNINETT/mod_auth_mellon/issues/2 raises the issue
of the Cache-Control header always being set, but with some users
needing to turn it off.
This update adds the MellonSendCacheControlHeader configuration
directive which can be set to Off, resulting in the cache-control
header not being set.
All other log messages containing lasso errors already use the idiom
Some message. Lasso error: [%i] %s", ..., rc, lasso_strerror(rc)
The different log format here leads e.g. to a double "." at the
end of the log message. Example:
Error adding metadata "/path/to/idp-metadata.xml" to lasso
server objects: Parsed XML is invalid..
Use APLOG_USE_MODULE if available.
This will also add the module name to its error log messages,
e.g. "[auth_mellon:error]" instead of just "[:error]".
No change for Apache 2.2.
If the logout message is badly formed, we won't get the entityID in
`logout->parent.remote_providerID`. If we call `apr_hash_get()` with a
null pointer, it will cause a segmentation fault.
Add a check to validate that the entityID is correctly set.
In am_check_uid() if am_check_permissions() denies access then the
proper HTTP return code is FORBIDDEN (which is what
am_check_permissions() returns on failure). Returning the result of
am_check_permissions() is what is already done in
am_auth_mellon_user(), this just makes the behavior
consistent. Returning UNAUTHORIZED is clearly wrong, that is meant to
indicate authentication needs to be performed.
Signed-off-by: John Dennis <jdennis@redhat.com>
mod_auth_mellon was interferring with other Apache authentication
modules (e.g. mod_auth_kerb) because when the Apache check_user_id
hook ran the logic in am_check_uid would execute even if mellon was
not enabled for the location. This short circuited the hook execution
and never allowed the authentication enabled for the location to
execute. It resulted in HTTP_UNAUTHORIZED being returned with the
client then expecting a WWW-Authenticate header field causing the
client to attempt to authenticate again.
Signed-off-by: John Dennis <jdennis@redhat.com>
If we don't, we can end up sending an authentication request to an IdP
that is not in the MellonProbeDiscoveryIdP list, which is probably not
what the user wants.
Patch by Emmanuel Dreyfus.
Limit the domains that we will redirect to after login / logout to a
set of trusted domains. By default we only allow redirects to the
current domain.
This change breaks backwards compatibility with any site that relies on
redirects to separate domains.
Fixes #35
The OASIS specification "SAML V2.0 Enhanced Client or Proxy Profile
Version 2.0" added ECP service options into the HTTP PAOS header. We
previously were not looking for these optional flags. The function
am_validate_paos_header() was rewritten to correctly parse the service
value and the optional URN flags and return a bitmask of the ECP
service flags.
The following flags were added:
* ECP_SERVICE_OPTION_CHANNEL_BINDING
* ECP_SERVICE_OPTION_HOLDER_OF_KEY
* ECP_SERVICE_OPTION_WANT_AUTHN_SIGNED
* ECP_SERVICE_OPTION_DELEGATION
The flags are stored in the am_req_cfg_rec.ecp_service_options member.
Currently only the want_authn_signed option is acted upon, it sets the
lasso signature hint when generating a AuthnRequest.
Lasso as of 2.5.0 is missing 3 of the URN flag identifier constants, a
patch was submitted to upstream Lasso to include them and was
accepted. As a fallback they are conditionally added to lasso_compat.h
in case the version of lasso this is compiled against does not yet
have the new constants.
The function am_is_paos_request() was modified to return an error.
New error codes were added to auth_mellon.h.
New utility code to tokenize a string was added. This is used to
parse the PAOS header, primarily to handle quoted strings.
A new utility routine, *am_ecp_service_options_str() was added so log
messages could include the ECP service option flags in their output.
Signed-off-by: John Dennis <jdennis@redhat.com>
The modifications in this commit address the changes necessary to
support the SP component of SAML ECP. The Lasso library needs
additional modifications before SAML ECP will be fully functional,
those fixes have been submitted to upstream Lasso, mod_auth_mellon
will continue to operate correctly without the Lasso upgrade, it just
won't properly support ECP without the Lasso fixes.
Below are the major logical changes in the commit and the rationale
behind them.
* Allow compilation against older versions of Lasso by conditionally
compiling.
Add the following CPP symbols set by configure:
* HAVE_ECP
* HAVE_LASSO_UTILS_H
* Add lasso_compat.h
If we can't include lasso utils.h than pull in our own
local definitions so we can use some of the valuable
utilities.
* Add ECP specific documentation file
Documentation specific to ECP is now contained in ECP.rst
(using reStructuredText formatting). Information on general ECP
concepts, mod_auth_mellon user information, and internal
mod_auth_mellon coding issues are covered.
* Add am_get_boolean_query_parameter() utility
* Add am_validate_paos_header() utility
This utility routine validates the PAOS HTTP header. It is used
in conjunction with am_header_has_media_type() to determine if a
client is ECP capable.
* Add am_is_paos_request() utility
This utility checks to see if the request is PAOS based on the
required HTTP header content.
* Add utility function am_header_has_media_type() to check if an HTTP
Accept header includes a specific media type. This is necessary
because the SP detects an ECP client by the presence of a
application/vnd.paos+xml media type in the Accept
header. Unfortunately neither Apache nor mod_auth_mellon already had
a function to check Accept media types so this was custom written
and added to mod_auth_mellon.
* Add utility function am_get_assertion_consumer_service_by_binding()
because Lasso does not expose that in it's public API. It's
necessary to get the URL of the PAOS AssertionConsumerService.
* Add MellonECPSendIDPList config option
This option controls whether to include a list of IDP's when
sending an ECP PAOS <AuthnRequest> message to an ECP client.
* We need to do some bookkeeping during the processing of a
request. Some Apache modules call this "adding a
note". mod_auth_mellon was already doing this but because it only
needed to track one value (the cookie value) took a shortcut and
stuffed the cookie value into the per module request slot rather
than defining a struct that could hold a variety of per-request
values. To accommodate multiple per request bookkeeping values we
define a new struct, am_req_cfg_rec, that holds the previously used
cookie value and adds a new ECP specific value. This struct is now
the bookkeeping data item attached to each request. To support the
new am_req_cfg_rec struct the am_get_req_cfg macro was added (mirrors
the existing am_get_srv_cfg, am_get_mod_cfg and am_get_dir_cfg
macros). The am_create_request() Apache hook was added to
initialize the am_req_cfg_rec at the beginning of the request
pipeline.
* A new endpoint was added to handle PAOS responses from the ECP
client. The endpoint is called "paosResponse" and lives along side
of the existing endpoints (e.g. postResponse, artifactResponse,
metadata, auth, logout, etc.). The new endpoint is handled by
am_handle_paos_reply(). The metadata generation implemented in
am_generate_metadata() was augmented to add the paosResponse
endpoint and bind it to the SAML2 PAOS binding.
* am_handle_reply_common() was being called by am_handle_post_reply()
and am_handle_artifact_reply() because replies share a fair amount
of common logic. The new am_handle_paos_reply() also needs to
utilize the same common logic in am_handle_reply_common() but ECP
has slightly different behavior that has to be accounted for. With
ECP there is no SP generated cookie because the SP did not initiate
the process and has no state to track. Also the RelayState is
optional with ECP and is carried in the PAOS header as opposed to an
HTTP query/post parameter. The boolean flag is_paos was added as a
parameter to am_handle_reply_common() so as to be able to
distinguish between the PAOS and non-PAOS logic.
* Add PAOS AssertionConsumerService to automatically generated metadata.
Note, am_get_assertion_consumer_service_by_binding() should be able
to locate this endpoint.
* Refactor code to send <AuthnRequest>, now also supports PAOS
The creation and initialization of a LassoLogin object is different
for the ECP case. We want to share as much common code as possible,
the following refactoring was done to achieve that goal.
The function am_send_authn_request() was removed and it's logic
moved to am_init_authn_request_common(),
am_send_login_authn_request() and
am_set_authn_request_content(). This allows the logic used to create
and initialize a LassoLogin object to be shared between the PAOS and
non-PAOS cases. am_send_paos_authn_request() also calls
am_init_authn_request_common() and
am_set_authn_request_content(). The function
am_set_authn_request_content() replaces the logic at the end of
am_send_authn_request(), it is responsible for setting the HTTP
headers and body content based on the LassoLogin.
Signed-off-by: John Dennis <jdennis@redhat.com>
This patch makes the username of the main request available in the
subrequests, such as those used by DirectoryIndex to find the
actual page to display when you access a folder.
The error messages would look like this:
> No authentication done but request not allowed without authentication
> for /index.html. Authentication not configured?
This patch fixes issue 38.
The only supported options were 'none' and 'feide', where there is
no usecase anymore for 'feide', leaving only 'none'. This changes
the function into a no-op, it will still accept the MellonDecoder
directive for backwards compatibility.
Apperently some IdPs like PicketLink insist they reaaaally want to see
AssertionConsumerServiceURL as part of the Authentication Request.
Provide it if allowed by the SP metadata.
Signed-off-by: Simo Sorce <simo@redhat.com>
We free the first element of a linked list, but not the data nor the
subsequent elements. Fix that by first iterating through the list
freeing the elements and then freeing the list using g_list_free().
We could have used g_list_free_full, but that requires version 2.28
of GLib, which is still slightly too recent.
git-svn-id: https://modmellon.googlecode.com/svn/trunk@237 a716ebb1-153a-0410-b759-cfb97c6a1b53
In case we are going to return a HTTP_UNAUTHORIZED
error we can also redirect the client to an admin chosen
page to let the application handle the error on its own.
Signed-off-by: Simo Sorce <simo@redhat.com>
git-svn-id: https://modmellon.googlecode.com/svn/trunk@227 a716ebb1-153a-0410-b759-cfb97c6a1b53
Idps may decide to deny authentication for a variety of reasons.
In such a case they will post to the application with an unsuccessful
status error code.
Handle the case by returning a more appropriate 401 Unauthorized
HTTP error code.
iDo this using an extensible mechanism to map arbitrary lasso errors
to HTTP errors.
Signed-off-by: Simo Sorce <simo@redhat.com>
git-svn-id: https://modmellon.googlecode.com/svn/trunk@226 a716ebb1-153a-0410-b759-cfb97c6a1b53
The -Wunused-but-set-variable option will cause a warning that
idp_public_key_file is set but never used when
HAVE_lasso_server_load_metadata is defined.
Signed-off-by: Simo Sorce <simo@redhat.com>
git-svn-id: https://modmellon.googlecode.com/svn/trunk@225 a716ebb1-153a-0410-b759-cfb97c6a1b53
This patch changes the headers sent to prevent errornous caching of the
responses sent to only use a single header:
Cache-Control: private, must-revalidate
This single header should ensure that the data isn't shared between
multiple users, and that the browser checks that the content is still
valid for each request (enabling logout to work as expected).
This drops the Exires-header, which should be unnecessary since all
modern browsers support the Cache-Control-header.
Thanks to Arthur Müller for providing this patch.
git-svn-id: https://modmellon.googlecode.com/svn/trunk@223 a716ebb1-153a-0410-b759-cfb97c6a1b53
In the case where the error "LASSO_PROFILE_ERROR_SESSION_NOT_FOUND"
occurs during lasso_logout_validate_request(), we weren't releasing
the session mutex, which will lead to a deadlock in the next request
that needs to access a session. This patch makes sure we properly
release session in that case.
git-svn-id: https://modmellon.googlecode.com/svn/trunk@221 a716ebb1-153a-0410-b759-cfb97c6a1b53
The HTTP-Artifact response is also allowed to be sent as a POST request.
This patch adds support for loading those responses.
Thanks to Nikola Ivačič for implementing this!
git-svn-id: https://modmellon.googlecode.com/svn/trunk@217 a716ebb1-153a-0410-b759-cfb97c6a1b53
In the case where we are missing the repost data, we currently
display a 400 Bad Request error. This patch changes the code to
redirect to the end URL instead, which at least has a chance to
work.
git-svn-id: https://modmellon.googlecode.com/svn/trunk@202 a716ebb1-153a-0410-b759-cfb97c6a1b53
Accessing the "login"-endpoint with multiple IdPs configured would
bypass the discovery service. This patch changes the behaviour so
that we send a discovery service request instead.
This breaks backwardscompatibility slightly, but hopefully it should
not be a problem.
This fixes issue 13: https://code.google.com/p/modmellon/issues/detail?id=13
git-svn-id: https://modmellon.googlecode.com/svn/trunk@186 a716ebb1-153a-0410-b759-cfb97c6a1b53
If we mark the session as logged in before all processing is completed,
a failure during login processing (e.g. too big attribute values) can
cause a user to receive a "half-authenticated" session.
This patch changes the code so that the last task before releaseing the
session is to mark it as logged in.
git-svn-id: https://modmellon.googlecode.com/svn/trunk@184 a716ebb1-153a-0410-b759-cfb97c6a1b53
We currently release the session lock only to grab it again a few
instructions later. This patch changes this so that we initialize
the session in one operation.
git-svn-id: https://modmellon.googlecode.com/svn/trunk@183 a716ebb1-153a-0410-b759-cfb97c6a1b53
Roger Meier
Olav Morken
Olav Morken
John Dennis
nneul at neulinger.org
Emmanuel Dreyfus
Vittal Aithal
Rainer Jung
Thijs Kinkhorst
Benjamin Dauvergne
Simo Sorce
olavmrk
manu@netbsd.org