The logic is now simpler:
- first lasso_saml20_profile_process_any_response check the signature
on the message
- then lasso_saml20_login_process_response_status_and_assertion
traverse all the assertions:
- if the message is signed all assertion from the same issuer are
automatically accepted,
- if the message is not signed, or the signature validation failed,
or the assertion has a different issuer than the message, we check
the signature directly on the assertion. If any of the assertions
fails the signature check, the result will be
LASSO_PROFILE_ERROR_CANNOT_VERIFY_SIGNATURE.
The public field profile->signature_status will contain only the message
level signature status, each assertion signature status is not
accessible. That will change when signature and key handling is
reworked.
If the message is signed, the assertion is also covered, but if only the
assertion is signed, there is no error to report. If the caller ask for
forcing the validation of message signature, then we report an error.
This commit also add checking for the binding used, if it is not
HTTP-Post lasso_login_process_authn_response_msg will now report an
error.
* support private key with new internal API in signature setting
methods
Plug lasso_node_set_signature into
lasso_profile_saml20_setup_message_signature and
lasso_server_saml2_assertion_setup_signature.
* also use lasso_node_get_signature in has_signature
* add forgottent LASSO_PROFILE_SIGNATURE_VERIFY_HINT_FORCE in switch
cases
For AuthnResponse checking the semantic is now that if HINT_FORCE is
used we verify message signature *and* assertion signature. If
HINT_MAYBE is used we check the assertion signature if its issuer
differs from the message issuer.
The node containing signature do not handle the private keys passwords.
As the fields for signature parameters are part of the public ABI we
cannot add the password field to the public structure for those nodes.
Instead we use the new quark annotation accessed through
lasso_node_get/set_signature, and if the sign_type parameter is non-NULL
we use it instead of the parameters stored in the public structure.
This is a gross hack :( but at least it is documented.
The signature parameters are serialized as global attributes from the
http://lasso.entrouvert.org/lasso/namespaces/0.0 named:
SignatureType
SignatureMethod
PrivateKey
PrivateKeyPassword
Certificate
Those two methods allows to associate signature parameters to any node.
They keep it inside the CustomElement quark. Using a private structure
may be more performant.
In order to permit subclass to modify the base xmlNode created by
lasso_node_impl_get_xmlNode we must defer the concrete to the virtual
method wrapper, lasso_node_get_xmlNode.
To do that it whas needed to make id_attribute another virtual field of
LassoNode subclasses (it can be accessed through an offset registered in
the class object).
This commit solves signature validation error since the patch for
managing more than one SessionIndex element in samlp2:LogoutRequest.
It also factorize the creation of signatures in one place.
The standard mandate to provide a SessionIndex to service provider
advertaising their support of the logout profile. We follow the
convention of using the assertion ID as a SessionIndex.
Some use case ask for passing simple libxml content node (i.e just an
UTF-8 string) when a method argument or a field of the xmlNode* type.
This commit add a static method in bindings/utils.c named
lasso_string_fragment_to_xmlnode which does this transform by trying to
parse an XML document then by trying to parse a well balanced XML
fragment of only one node (if there is more than one node such as in the
string " xxx <tag/> yyy ", we free the node list and return NULL).
We only looked to the keep_xmlnode flag in the node data of the top
level class, but any parent class can set this flag and in this case we
must honor it too.
We currently do not store the encryption private key, instead on reload
of a dump, we try to use the signing private key as the encryption
private key. But we forgot to use the stored private key password.
That's now fixed.
Next step would be to keep the encryption private key around also.
Benjamin Dauvergne