prefix_from_href_and_nodename() did not know about the ECP and PAOS
XML prefixes so add them.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
Add function lasso_node_export_to_soap_with_headers()
Utility function to build a full SOAP envelope message with arbitrary
headers. The LassoNode becomes the body of the SOAP envelope. The
headers are passed as a GList of LassoNode's and are added as header
elements to the SOAP envelope header. This is a flexible way to build
a SOAP envelope that contains headers without constraints on the
headers.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
LassoSamlp2IDPList is supposed to handle a list of LassoSamlp2IDPEntry
but in fact it had no list support. Change the snippet flag
SNIPPET_NODE to SNIPPET_LIST_NODES and add the special list comment on
the struct member so that the binding generator knows what type of
GList it is.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
The SAMLv2 protocol defines 5 XML types which we need to map to
LassoNode objectes so thay can be serialized from XML and back into
XML.
ecp:RelayState
ecp:Request
ecp:Response
paos:Request
paso:Response
This patch addes these 5 new LassoNode's and updates the build
configuration to include them.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
The existing lasso_saml20_profile_process_soap_response() assumed
there were no SOAP headers (prior to ECP none of the SOAP messages
contained headers). A new function
lasso_saml20_profile_process_soap_response_with_headers() was
implemented that serializes from the XML SOAP headers into a
LassoSoapHeader node and optionally will return the LassoSoapHeader
node.
The functionality in lasso_saml20_profile_process_soap_response() was
moved into the new
lasso_saml20_profile_process_soap_response_with_headers() and now
lasso_saml20_profile_process_soap_response() simply calls
lasso_saml20_profile_process_soap_response_with_headers() passing NULL
for the header return.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
The existing LassoSoapEnvelope constructors did not populate the node
with it's constituent members, namely a SOAP header (LassoSoapHeader)
and a SOAP body (LassoSoapBody). lasso_soap_envelope_new_full() allows
one to create a SOAP envelope and immediately begin to add header and
body elements.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
The existing Lasso code never made use of SOAP headers because up
until now nothing used them. LassoSoapHeader was unable to serialize
from XML into a GList of LassoNode objects because it was missing one
of the necessary snippet flags. This corrects this omission and now
parsing a SOAP header will yield a sequence of LassoNode's.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
The public utils.h header includes the private xml/private.h file
which is not installed. Therefore anyone trying to build against lasso
and include utils.h will fail because xml/private.h cannot be
found. There doesn't seem to be any need to include this file.
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
Because all warnings are treated as errors and this warning is emitted:
warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
the build fails.
The fix is to define _DEFAULT_SOURCE in lasso/xml/tools.c
The effect of defining the _DEFAULT_SOURCE macro is equivalent to
the effect of explicitly defining three macros in earlier glibc
versions: -D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809C
Signed-off-by: John Dennis <jdennis@redhat.com>
License: MIT
The goal of those two methods is to allow IdP and SP to load metadata
dynamically without processing completely the incoming. Currently it's
impossible as message parsing and signature checking is done in the same
function.
When the same URL was used for many bindings, the current code did not
work. Now we use
lasso_saml20_provider_check_assertion_consumer_service_url() to validate
url and binding are matching, if no binding is suggested we take the
first one defined for this URL.
Using AssertionConsumerServiceIndex and any of the other assertion
consumer designator attributes is still forbidden.
Fix a mistake in the documentation markup that prevented the
doc from building, needed to reverse the order of two tags.
Remove the $(PYTHON) from TESTS_ENVIRONMENT, it was causing
python to be invoked passing /bin/sh to it as a script.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
The Destination attribute on SAML Response element was not being set
when handling an ECP response. It is a requirement of SAML 2.0 that
signed values contain a Destination attribute on the root element
otherwise the client will reject the response. This is documented in
the SAML Bindings Specification, Section 3.4.5.2 "Security
Considerations":
If the message is signed, the Destination XML attribute in the
root SAML element of the protocol message MUST contain the URL to
which the sender has instructed the user agent to deliver the
message. The recipient MUST then verify that the value matches the
location at which the message has been received.
Normally on login one calls
lasso_saml20_login_build_authn_response_msg() which then calls
lasso_saml20_profile_build_response_msg() which sets the Destination
attribute on the SAML Response. But when doing ECP you do not call
lasso_saml20_login_build_authn_response_msg(), instead you call call
lasso_saml20_login_build_response_msg() and if it's ECP it then calls
lasso_node_export_to_ecp_soap_response(). Thus the ECP
response never gets the Destination attribute set because of the
different code path, plus for ECP the destination is different, it's
the assertion consumer service.
FWIW this line of code was copied almost verbatim from
lasso_saml20_profile_build_response_msg which also sets the
Destination attribute.
License: MIT
Signed-off-by: John Dennis <jdennis@redhat.com>
John Dennis
Benjamin Dauvergne
Jérôme Schneider
EO builder bot
Houzéfa Abbasbhay