In case VERIFY_HINT was set to IGNORE and the login signature was
incorrect, lasso_saml20_login_process_response_status_and_assertion
would have jumped straight to the cleanup label which just returns the
return code.
Related: https://dev.entrouvert.org/issues/54689
License: MIT
OpenSSL API is used to sign query-string values in the SAML 2.0 Redirect binding.
Other binding only need the libxmlsec API as signature are XML DSIG signatures.
The following functions where part of the experimental ID-WSF support
recently removed but where incorrectly included in the official ABI, so we
restore dummy versions of them (they do nothing or return NULL):
- lasso_get_prefix_for_dst_service_href
- lasso_get_prefix_for_idwsf2_dst_service_href
- lasso_register_dst_service
- lasso_register_idwsf2_dst_service
The key encryption padding algorithm is now configurable, the default
being changed to OAEP. It's possible to set the default through
./configure with:
--with-default-key-encryption-method=[rsa-pkcs1|rsa-oaep]
at initialization time with an environment variable:
LASSO_DEFAULT_KEY_ENCRYPTION_METHOD=[rsa-pkcs1|rsa-oaep]
or at runtime for a service provider:
lasso_provider_set_key_encryption_method(LassoProvider *provider,
LassoKeyEncryptionMethod key_encryption_method)
The setting is global for all encrypted nodes (Assertion or NameID).
Adds a new utility function lasso_allowed_signature_method() that checks
if the signature method is allowed. Previously, the code would only
check if the method was valid.
This new function is used whenever lasso_validate_signature_method was
previously used through lasso_ok_signature_method() which wraps both
validate and allowed.
lasso_allowed_signature_method() is also used on a couple of places,
notably lasso_query_verify_helper().
Related:
https://dev.entrouvert.org/issues/54037
Adds two new configure options:
--with-default-sign-algo
--min-hash-algo
--with-default-sign-algo sets the default signing algorithm and defaults
to rsa-sha1. At the moment, two algorithms are supported: rsa-sha1 and
rsa-sha256.
--min-hash-algo sets the minimum hash algorithm to be accepted. The
default is sha1 for backwards compatibility as well.
Related:
https://dev.entrouvert.org/issues/54037
The switch clause was using SHA1 digests for all digest types when
signing. This obviously breaks verifying the signatures if HMAC-SHAXXX
is used and XXX is something else than 1.
CVE-2021-28091 : when AuthnResponse messages are not signed (which is
permitted by the specifiation), all assertion's signatures should be
checked, but currently after the first signed assertion is checked all
following assertions are accepted without checking their signature, and
the last one is considered the main assertion.
This patch :
* check signatures from all assertions if the message is not signed,
* refuse messages with assertion from different issuers than the one on
the message, to prevent assertion bundling event if they are signed.
so that lasso.py, lasso/types.c and liblasso.so.3.13.0
build reproducibly
in spite of indeterministic filesystem readdir order.
For some reason, lasso/extract_sections.py lasso/extract_symbols.py
do not need such patches to get a reproducible openSUSE package.
See https://reproducible-builds.org/ for why this is good.
This patch was done while working on reproducible builds for openSUSE.
License: MIT
Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
As implemented lasso_server_add_provider2 could not be used as a publik
API as it dit not increase the reference count of the LassoProvider
object before adding it to the providers hashtable.
lasso_server_add_provider_helper had to be modified to decrement the
reference count of the new LassoProvider object after using
lasso_server_add_provider2.
When ECP profile (saml-ecp-v2.0-cs01) is used with PAOS binding Lasso
populates an AuthnRequest with the "Destination" attribute set to
AssertionConsumerURL of an SP - this leads to IdP-side errors because
the destination attribute in the request does not match the IdP URL.
The "Destination" attribute is mandatory only for HTTP Redirect and HTTP
Post bindings when AuthRequests are signed per saml-bindings-2.0-os
(sections 3.4.5.2 and 3.5.5.2). Specifically for PAOS it makes sense to
avoid setting that optional attribute because an ECP decides which IdP
to use, not the SP.
Fixes Bug: 34409
License: MIT
Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>
saml2:AuthnContext XML schema indicate that AuthenticatingAuthority is
an optional unbounded list of nodes, but the current Lasso schema only
handle an unique element. To prevent Lasso from refusing perfectly legal
messages, we add a rule to the Lasso ignoring other nodes after the
first one.
With a SAML Authn Response either the message or the assertion
contained in the response message or both can be signed. Most IdP's
sign the message. This fixes a bug when processing an ECP authn
response when only the assertion is signed.
lasso_saml20_profile_process_soap_response_with_headers() performs a
signature check on the SAML message. A signature can also appear on
the assertion which is checked by
lasso_saml20_login_process_response_status_and_assertion() The problem
occurred when the message was not signed and
lasso_saml20_profile_process_soap_response_with_headers() returned
LASSO_DS_ERROR_SIGNATURE_NOT_FOUND as an error code which is not
actually an error because we haven't checked the signature on the
assertion yet. We were returning the first
LASSO_DS_ERROR_SIGNATURE_NOT_FOUND error when in fact the subsequent
signature check in
lasso_saml20_login_process_response_status_and_assertion() succeeded.
The ECP unit tests were enhanced to cover these cases.
The enhanced unit test revealed a problem in two switch statements
operating on the return value of
lasso_profile_get_signature_verify_hint() which were missing a case
statement for LASSO_PROFILE_SIGNATURE_VERIFY_HINT_FORCE which caused
an abort due to an unknown enumeration value.
Fixes Bug: 26828
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
While porting other Python code in the repo to run under Py3 (as well
as Py2) it was discovered there were a number of other Python scripts
which also needed porting. However these scripts are never invoked
during a build so there was no easy way to test the porting work. I
assume these scripts are for developers only and/or are
historical. Because there was no way for me to test the porting
changes on these scripts I did not want to include the changes in the
patch for the Py3 porting which fixed scripts that are invoked during
the build (the former patch is mandatory, this patch is optional at
the moment). I did verify the scripts compile cleanly under both Py2
and Py3, however it's possible I missed porting something or the error
does not show up until run-time.
Examples of the required changes are:
* Replace use of the built-in function file() with open(). file()
does not exist in Py3, open works in both Py2 and Py3. The code was
also modified to use a file context manager (e.g. with open(xxx) as
f:). This assures open files are properly closed when the code block
using the file goes out of scope. This is a standard modern Python
idiom.
* Replace all use of the print keyword with the six.print_()
function, which itself is an emulation of Py3's print function. Py3
no longer has a print keyword, only a print() function.
* The dict methods .keys(), .values(), .items() no longer return a
list in Py3, instead they return a "view" object which is an
iterator whose result is an unordered set. The most notable
consequence is you cannot index the result of these functions like
your could in Py2 (e.g. dict.keys()[0] will raise a run time
exception).
* Replace use of StringIO.StringIO and cStringIO with
six.StringIO. Py3 no longer has cStringIO and the six variant
handles the correct import.
* Py3 no longer allows the "except xxx, variable" syntax, where
variable appering after the comma is assigned the exception object,
you must use the "as" keyword to perform the variable assignment
(e.g. execpt xxx as variable)
* Python PEP 3113 removed tuple parameter unpacking. Therefore you can
no longer define a formal parameter list that contains tuple
notation representing a single parameter that is unpacked into
multiple arguments.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
During the build if the Python3 interpreter is used a number of
scripts will fail because they were never ported from Py2 to Py3. In
general we want Python code to be compatible with both Py2 and
Py3. This patch brings the scripts up to date with Py3 but retains
backwards compatibility with Py2 (specifically Py 2.7, the last Py2
release).
Examples of the required changes are:
* Replace use of the built-in function file() with open(). file()
does not exist in Py3, open works in both Py2 and Py3. The code was
also modified to use a file context manager (e.g. with open(xxx) as
f:). This assures open files are properly closed when the code block
using the file goes out of scope. This is a standard modern Python
idiom.
* Replace all use of the print keyword with the six.print_()
function, which itself is an emulation of Py3's print function. Py3
no longer has a print keyword, only a print() function.
* The dict methods .keys(), .values(), .items() no longer return a
list in Py3, instead they return a "view" object which is an
iterator whose result is an unordered set. The most notable
consequence is you cannot index the result of these functions like
your could in Py2 (e.g. dict.keys()[0] will raise a run time
exception).
* Replace use of StringIO.StringIO and cStringIO with
six.StringIO. Py3 no longer has cStringIO and the six variant
handles the correct import.
* Py3 no longer allows the "except xxx, variable" syntax, where
variable appering after the comma is assigned the exception object,
you must use the "as" keyword to perform the variable assignment
(e.g. execpt xxx as variable)
Note: the modifications in this patch are the minimum necessary to get
the build to run with the Py3 interpreter. There are numerous other
Python scripts in the repo which need Py3 porting as well but because
they are not invoked during a build they will be updated in a
subsequent patch.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
The configure script allows you to specify the python interpreter to
use via the --with-python option. There were several places where the
python interpreter was implicity invoked without using the specified
version. This can create a number of problems in an environment with
multiple python versions as is the case during the transition from
Python 2 to Python 3. Python 2 is not compatible with Python
3. Lasso's Python code is supposed to be compatible with both
versions. But during the build and when running the unit tests it is
essential the same interpreter be used consistently otherwise you can
have problems.
This patch assures whenever python is invoked it does so via the
$(PYTHON) configuration variable.
What about shebang lines (e.g #/usr/bin/python) at the top of scripts?
Python PEP 394 (https://www.python.org/dev/peps/pep-0394/) covers
this. Basically it says if a script is compatible only with Py2 the
shebang should be #/usr/bin/python2, if only compatible with Py3 the
shebang should be #/usr/bin/python3. However, if the script is
compatible with both versions it can continue to use the
compatible with both Py2 and Py3.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
We reuse the "message" local variable but we should not.
Also fix a segfault in lasso_xmltextreader_from_message() when getting
the length of "message" before checking if it is NULL or not.
We want to deprecate support for loading PEM formatted key
from ds:KeyValue nodes, before final removal it will have to be activated
through a runtime flag (using LASSO_FLAG environment variable).
xmlsec has removed support for SOAP. The missing xmlSecSoap* functions
and their dependent utiliity functions were added to Lasso following
the model of the existing xmlSec implmentations.
Note: Lasso tried to accommodate both SOAP 1.1 and SOAP 1.2 but SAML2
*only* uses SOAP 1.1 thus the SOAP 1.2 support was superfluous and
confused matters. Therefire the SOAP 1.2 support was removed.
The following new functions were added to Lasso to support SOAP:
* lasso_xml_next_element_node
* lasso_xml_get_node_ns_href
* lasso_xml_is_element_node
* lasso_xml_soap11_get_header
* lasso_xml_soap11_get_body
The following is the mapping from the deprecated xmlSecSoap symbols
to the new Lasso symbols:
xmlSecSoap11Ns -> LASSO_SOAP_ENV_HREF
xmlSecGetNextElementNode -> lasso_xml_next_element_node
xmlSecGetNodeNsHref -> lasso_xml_get_node_ns_href
xmlSecCheckNodeName -> lasso_xml_is_element_node
xmlSecSoap11GetHeader -> lasso_xml_soap11_get_header
xmlSecSoap11GetBody -> lasso_xml_soap11_get_body
This patch also extends the automake version support in autogen.sh to the
current 1.16 version.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
Benjamin Dauvergne
Jakub Hrozek
Bernhard M. Wiedemann
Dmitrii Shcherbakov
John Dennis