2015-04-08 11:06:47 +02:00
|
|
|
AC_INIT([mod_auth_mellon],m4_esyscmd([tools/git-version-gen .tarball-version]),[olav.morken@uninett.no])
|
2017-09-28 22:28:55 +02:00
|
|
|
AC_CONFIG_HEADERS([config.h])
|
2007-09-24 11:56:34 +02:00
|
|
|
|
2014-06-20 13:24:33 +02:00
|
|
|
# We require support for C99.
|
|
|
|
|
AC_PROG_CC_C99
|
|
|
|
|
|
2007-09-24 11:56:34 +02:00
|
|
|
AC_SUBST(NAMEVER, AC_PACKAGE_TARNAME()-AC_PACKAGE_VERSION())
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# This section defines the --with-apxs2 option.
|
|
|
|
|
AC_ARG_WITH(
|
|
|
|
|
[apxs2],
|
|
|
|
|
[ --with-apxs2=PATH Full path to the apxs2 executable.],
|
|
|
|
|
[
|
|
|
|
|
APXS2=${withval}
|
2010-07-02 13:51:00 +02:00
|
|
|
],)
|
2007-09-24 11:56:34 +02:00
|
|
|
|
|
|
|
|
|
2010-07-02 13:51:00 +02:00
|
|
|
if test "x$APXS2" = "x"; then
|
2007-09-24 11:56:34 +02:00
|
|
|
# The user didn't specify the --with-apxs2-option.
|
|
|
|
|
|
|
|
|
|
# Search for apxs2 in the specified directories
|
2010-07-02 13:51:00 +02:00
|
|
|
AC_PATH_PROG(APXS2, apxs2,,
|
2007-09-24 11:56:34 +02:00
|
|
|
/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin)
|
|
|
|
|
|
2010-07-02 13:51:00 +02:00
|
|
|
if test "x$APXS2" = "x"; then
|
2007-09-24 11:56:34 +02:00
|
|
|
# Didn't find apxs2 in any of the specified directories.
|
|
|
|
|
# Search for apxs instead.
|
2010-07-02 13:51:00 +02:00
|
|
|
AC_PATH_PROG(APXS2, apxs,,
|
2007-09-24 11:56:34 +02:00
|
|
|
/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin)
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
# Test if $APXS2 exists and is an executable.
|
|
|
|
|
if test ! -x "$APXS2"; then
|
|
|
|
|
# $APXS2 isn't a executable file.
|
|
|
|
|
AC_MSG_ERROR([
|
|
|
|
|
Could not find apxs2. Please spesify the path to apxs2
|
|
|
|
|
using the --with-apxs2=/full/path/to/apxs2 option.
|
|
|
|
|
The executable may also be named 'apxs'.
|
|
|
|
|
])
|
|
|
|
|
fi
|
|
|
|
|
|
Add diagnostic logging
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>
2017-06-14 19:56:18 +02:00
|
|
|
AC_ARG_ENABLE(
|
|
|
|
|
[diagnostics],
|
|
|
|
|
[AS_HELP_STRING([--enable-diagnostics],
|
|
|
|
|
[Build with diagnostic support])],
|
|
|
|
|
[],
|
|
|
|
|
[enable_diagnostics=no])
|
|
|
|
|
|
|
|
|
|
AS_IF([test "x$enable_diagnostics" != xno],
|
2017-09-28 22:28:55 +02:00
|
|
|
[AC_DEFINE([ENABLE_DIAGNOSTICS],[],[build with diagnostics])])
|
Add diagnostic logging
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>
2017-06-14 19:56:18 +02:00
|
|
|
|
2007-09-24 11:56:34 +02:00
|
|
|
# Replace any occurances of @APXS2@ with the value of $APXS2 in the Makefile.
|
|
|
|
|
AC_SUBST(APXS2)
|
|
|
|
|
|
|
|
|
|
# We need the lasso library for SAML2 communication.
|
|
|
|
|
PKG_CHECK_MODULES(LASSO, lasso)
|
2008-11-10 19:33:55 +01:00
|
|
|
saved_LIBS=$LIBS; LIBS="$LIBS $LASSO_LIBS";
|
|
|
|
|
AC_CHECK_LIB(lasso, lasso_server_new_from_buffers,
|
2017-09-28 22:28:55 +02:00
|
|
|
[AC_DEFINE([HAVE_lasso_server_new_from_buffers],[],
|
|
|
|
|
[lasso library exports lasso_server_new_from_buffers])])
|
2011-05-18 12:49:25 +02:00
|
|
|
AC_CHECK_LIB(lasso, lasso_server_load_metadata,
|
2017-09-28 22:28:55 +02:00
|
|
|
[AC_DEFINE([HAVE_lasso_server_load_metadata],[],
|
|
|
|
|
[lasso library exports lasso_server_load_metadata])])
|
2012-10-09 10:41:45 +02:00
|
|
|
AC_CHECK_LIB(lasso, lasso_profile_set_signature_verify_hint,
|
2017-09-28 22:28:55 +02:00
|
|
|
[AC_DEFINE([HAVE_lasso_profile_set_signature_verify_hint],[],
|
|
|
|
|
[lasso library exports lasso_profile_set_signature_verify_hint])])
|
Add support for SAML ECP.
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>
2015-07-06 22:04:55 +02:00
|
|
|
AC_CHECK_LIB(lasso, lasso_ecp_request_new,
|
2017-09-28 22:28:55 +02:00
|
|
|
[AC_DEFINE([HAVE_ECP],[],
|
|
|
|
|
[lasso library supports ECP profile])])
|
2008-11-10 19:33:55 +01:00
|
|
|
LIBS=$saved_LIBS;
|
2007-09-24 11:56:34 +02:00
|
|
|
AC_SUBST(LASSO_CFLAGS)
|
|
|
|
|
AC_SUBST(LASSO_LIBS)
|
|
|
|
|
|
|
|
|
|
# We need the curl library for HTTP-Artifact downloads.
|
|
|
|
|
PKG_CHECK_MODULES(CURL, libcurl)
|
|
|
|
|
AC_SUBST(CURL_CFLAGS)
|
|
|
|
|
AC_SUBST(CURL_LIBS)
|
|
|
|
|
|
|
|
|
|
# We also need openssl for its random number generator.
|
|
|
|
|
PKG_CHECK_MODULES(OPENSSL, openssl)
|
|
|
|
|
AC_SUBST(OPENSSL_CFLAGS)
|
|
|
|
|
AC_SUBST(OPENSSL_LIBS)
|
|
|
|
|
|
2012-10-10 12:35:15 +02:00
|
|
|
# We need at least version 2.12 of GLib.
|
|
|
|
|
PKG_CHECK_MODULES([GLIB], [glib-2.0 >= 2.12])
|
2013-03-15 09:50:23 +01:00
|
|
|
AC_SUBST(GLIB_CFLAGS)
|
|
|
|
|
AC_SUBST(GLIB_LIBS)
|
2011-09-23 13:27:49 +02:00
|
|
|
|
Add diagnostic logging
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>
2017-06-14 19:56:18 +02:00
|
|
|
AC_SUBST(MELLON_CFLAGS)
|
|
|
|
|
|
Add support for SAML ECP.
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>
2015-07-06 22:04:55 +02:00
|
|
|
# Test to see if we can include lasso/utils.h
|
|
|
|
|
# AC_CHECK_HEADER won't work correctly unless we specifiy the include directories
|
|
|
|
|
# found in the LASSO_CFLAGS. Save and restore CFLAGS and CPPFLAGS.
|
|
|
|
|
saved_CFLAGS=$CFLAGS
|
|
|
|
|
saved_CPPFLAGS=$CPPFLAGS
|
|
|
|
|
CFLAGS="$CFLAGS $pkg_cv_LASSO_CFLAGS"
|
|
|
|
|
CPPFLAGS="$CPPFLAGS $pkg_cv_LASSO_CFLAGS"
|
|
|
|
|
AC_CHECK_HEADER([lasso/utils.h], LASSO_CFLAGS="$LASSO_CFLAGS -DHAVE_LASSO_UTILS_H")
|
|
|
|
|
CFLAGS=$saved_CFLAGS
|
|
|
|
|
CPPFLAGS=$saved_CPPFLAGS
|
|
|
|
|
|
2018-01-11 19:05:26 +01:00
|
|
|
# Determine what definitions exist in Lasso
|
|
|
|
|
saved_CFLAGS=$CFLAGS
|
|
|
|
|
CFLAGS="$CFLAGS $pkg_cv_LASSO_CFLAGS"
|
|
|
|
|
AC_CHECK_DECLS([LASSO_SIGNATURE_METHOD_RSA_SHA256,
|
|
|
|
|
LASSO_SIGNATURE_METHOD_RSA_SHA384,
|
|
|
|
|
LASSO_SIGNATURE_METHOD_RSA_SHA512,
|
|
|
|
|
], [], [], [#include <lasso/xml/xml.h>])
|
|
|
|
|
CFLAGS=$saved_CFLAGS
|
2007-09-24 11:56:34 +02:00
|
|
|
|
|
|
|
|
# Create Makefile from Makefile.in
|
|
|
|
|
AC_CONFIG_FILES([Makefile])
|
|
|
|
|
AC_OUTPUT
|
